Re: [PATCH v2 6/7] nvmem: split struct nvmem_device into refcounted and provider-owned data

[Bartosz Golaszewski]

On Tue, Mar 17, 2026 at 11:44 AM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
> On Mon, Feb 23, 2026 at 11:57:07AM +0100, Bartosz Golaszewski wrote:
> > Data owned by the nvmem provider must not be part of the
> > reference-counted struct nvmem_device.
>
> It can be as long as it's not referenced after deregistration so this
> claim is too strong.
>
> It can be handled the way you are doing it here, but you could also just
> use a boolean flag to indicate that no further callbacks should be made.
>
> > Ahead of protecting that data
> > with SRCU, move it into a separate structure the address of which is
> > stored in nvmem_device.
>
> > +/*
> > + * Holds data owned by the provider of the nvmem implementation. This goes
> > + * away immediately the moment nvmem_unregister() is called.
> > + */
> > +struct nvmem_impl {
> > +     nvmem_reg_read_t        reg_read;
> > +     nvmem_reg_write_t       reg_write;
> > +     void                    *priv;
>
> And priv is just a pointer that is never used by nvmem core directly.
>
> > +};
>
> How about just wrapping the callbacks and calling the struct nvmem_ops
> to make it more clear how this is used?
>
> That is, that nvmem core guarantees that there will be no further
> callbacks after deregistration.
>

Yeah, having an ops struct makes sense. Do you have any objections to
patches 1-5? Maybe Srini could pick them up for v7.1 because I'm not
sure when I'll be able to rework the last two.

Bartosz