Re: [PATCH v4 4/8] block: implement NVMEM provider

On Tue, 9 Jun 2026 12:13:08 +0200, Loic Poulain
<[email protected]> said:
> Hi bartosz,
>

...

>>
>> On the other hand, we don't want to not provide the block device just because
>> someone added a DT property on one that's too big. I'd say: warn, but return 0.
>> Does it make sense?
>
> It’s still technically an error in the sense that we cannot provide
> the required nvmem feature. However, it only becomes a real issue if a
> consumer actually attempts to use it.
> Also, the block device should still be added, since the return code
> from add_dev is not checked. In any case, I’m fine with either
> approach, as long as we emit a warning message.
>

We don't check the return value now (why?) but if we ever do, the safer option
is to return 0 IMO.

>>
>> > +     }
>> > +
>> > +     config.id = NVMEM_DEVID_NONE;
>> > +     config.dev = dev;
>> > +     config.name = dev_name(dev);
>> > +     config.owner = THIS_MODULE;
>> > +     config.priv = (void *)(uintptr_t)dev->devt;
>> > +     config.reg_read = blk_nvmem_reg_read;
>> > +     config.size = bdev_nr_bytes(bdev);
>> > +     config.word_size = 1;
>> > +     config.stride = 1;
>> > +     config.read_only = true;
>> > +     config.root_only = true;
>> > +     config.ignore_wp = true;
>> > +     config.of_node = to_of_node(dev->fwnode);
>> > +
>> > +     return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
>>
>> And that was a wrong suggestion on my part too because I was under the
>> impression that we're in the probe() path, not device_add(). You can't use
>> devres here as the device at this point is not yet bound and may never be.
>
> So I understand The bd_device is purely a class device with no bus, no driver.
> For driverless devices, devres_release_all() is called explicitly
> within device_del() .
>

Right.

>>
>> Which leads me to the second point: this is not the moment to add the nvmem
>> provider. This should happen at or after probe(). Once nvmem_register()
>> returns, you have a visible nvmem resource but nothing backing it in the block
>> layer.
>
> There is a short window during which a read attempt will 'properly'
> fail, but this does seem somewhat fragile indeed.
>
>> Either do this in block core when registering a new device or schedule
>> a notifier here for the BUS_NOTIFY_BOUND_DRIVER event and do it in the notifier
>> callback.
>
> So in the end, it seems that the simpler and more robust approach is
> probably to move away from the class_interface driver and instead
> register/unregister the nvmem directly in add_disk/del_gendisk.
> If that's ok I will move to this approach in the next version.
>

Yes, I think it's the right approach.

Bart