From: Johan Hovold <johan@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/7] nvmem: split struct nvmem_device into refcounted and provider-owned data
Date: Mon, 23 Mar 2026 17:45:54 +0100 [thread overview]
Message-ID: <acFuQiVZchfQp4uu@hovoldconsulting.com> (raw)
In-Reply-To: <CAMRc=MfBYvAw5MvEBSUiswA6hBGMnKK2CKBczOFdENEfqUbYjw@mail.gmail.com>
On Tue, Mar 17, 2026 at 01:52:13PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 17, 2026 at 11:44 AM Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Feb 23, 2026 at 11:57:07AM +0100, Bartosz Golaszewski wrote:
> > > +/*
> > > + * 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.
This one fell between the cracks, sorry. I've taken a closer look at 1-5
now as well.
Johan
next prev parent reply other threads:[~2026-03-23 16:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 10:57 [PATCH v2 0/7] nvmem: survive unbind with active consumers Bartosz Golaszewski
2026-02-23 10:57 ` [PATCH v2 1/7] nvmem: remove unused field from struct nvmem_device Bartosz Golaszewski
2026-03-23 16:00 ` Johan Hovold
2026-02-23 10:57 ` [PATCH v2 2/7] nvmem: return -EOPNOTSUPP to in-kernel users on missing callbacks Bartosz Golaszewski
2026-03-23 16:21 ` Johan Hovold
2026-02-23 10:57 ` [PATCH v2 3/7] nvmem: check the return value of gpiod_set_value_cansleep() Bartosz Golaszewski
2026-03-23 16:28 ` Johan Hovold
2026-02-23 10:57 ` [PATCH v2 4/7] nvmem: simplify locking with guard() Bartosz Golaszewski
2026-03-23 16:35 ` Johan Hovold
2026-02-23 10:57 ` [PATCH v2 5/7] nvmem: remove unneeded __nvmem_device_put() Bartosz Golaszewski
2026-03-23 16:44 ` Johan Hovold
2026-02-23 10:57 ` [PATCH v2 6/7] nvmem: split struct nvmem_device into refcounted and provider-owned data Bartosz Golaszewski
2026-03-17 10:44 ` Johan Hovold
2026-03-17 12:52 ` Bartosz Golaszewski
2026-03-23 16:45 ` Johan Hovold [this message]
2026-02-23 10:57 ` [PATCH v2 7/7] nvmem: synchronize nvmem device unregistering with SRCU Bartosz Golaszewski
2026-03-17 11:31 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acFuQiVZchfQp4uu@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox