From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Michael Walle" <michael@walle.cc>,
"Rafał Miłecki" <rafal@milecki.pl>,
"Rob Herring" <robh+dt@kernel.org>,
"Frank Rowand" <frowand.list@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Robert Marko" <robert.marko@sartura.hr>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Luka Perkov" <luka.perkov@sartura.hr>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Chen-Yu Tsai" <wenst@chromium.org>,
"Daniel Golle" <daniel@makrotopia.org>
Subject: Re: [PATCH v12 7/7] nvmem: core: Expose cells through sysfs
Date: Wed, 11 Oct 2023 16:02:43 +0200 [thread overview]
Message-ID: <20231011160243.4893729d@xps-13> (raw)
In-Reply-To: <a67f5fd1-6b5c-662d-5ab3-b528c2080efc@linaro.org>
Hi Srinivas,
srinivas.kandagatla@linaro.org wrote on Wed, 11 Oct 2023 14:56:02 +0100:
> On 11/10/2023 12:09, Miquel Raynal wrote:
> > Hi Srinivas,
> >
> > srinivas.kandagatla@linaro.org wrote on Wed, 11 Oct 2023 11:02:16 +0100:
> >
> >> Hi Miquel,
> >>
> >> On 11/10/2023 10:44, Miquel Raynal wrote:
> >>> Hi Srinivas,
> >>>
> >>> srinivas.kandagatla@linaro.org wrote on Wed, 11 Oct 2023 10:26:43 +0100:
> >>> >>>> On 11/10/2023 09:58, Miquel Raynal wrote:
> >>>>> Hi Srinivas,
> >>>>>
> >>>>> srinivas.kandagatla@linaro.org wrote on Wed, 11 Oct 2023 09:45:11 +0100:
> >>>>> >>>> On 11/10/2023 09:33, Miquel Raynal wrote:
> >>>>>>> Hi Srinivas,
> >>>>>>>
> >>>>>>> srinivas.kandagatla@linaro.org wrote on Wed, 11 Oct 2023 09:27:20 +0100:
> >>>>>>> >>>> On 11/10/2023 08:15, Miquel Raynal wrote:
> >>>>>>>>>>> +
> >>>>>>>>>>> + nvmem_cells_group.bin_attrs = cells_attrs;
> >>>>>>>>>>> +
> >>>>>>>>>>> + ret = devm_device_add_groups(&nvmem->dev, nvmem_cells_groups);
> >>>>>>>>>>> + if (ret)
> >>>>>>>>>>> + goto unlock_mutex;
> >>>>>>>>>> This is going to create groups after the nvmem device is added, isn't this going to be problem with user space notifications?
> >>>>>>>>> Greg said it was not. I hope I understood correctly 😄
> >>>>>>>>>
> >>>>>>>>> And anyway, cells have never been available to userspace, so there is
> >>>>>>>>> nothing userspace might expect yet?
> >>>>>>>> I agree, but once we add sysfs uapi then this is going to change.
> >>>>>>>
> >>>>>>> Can you elaborate? I'm not sure I follow you here. Is there still a
> >>>>>>> problem you fear or you think it's okay?
> >>>>>>> >> Now that we add cells to sysfs.
> >>>>>> AFAIU, By the time the userspace sees the udev event from this device we might not have cells populated.
> >>>>>
> >>>>> Yes, but why would this be a problem?
> >>>>> >> It will be problem if the userspace is using things like libudev to act on these events. There seems to be some caching of attributes in udev during event more info http://www.kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
> >>>
> >>> I am already using these attributes, right? The problem here is that we
> >>> always attach cells sysfs attributes to the nvmem device, but in some
> >>> cases (when using layout devices/drivers) the probe of these devices
> >>> will happen after the main nvmem device has been announced to userspace
> >>> and thus these attributes might not be populated yet (but Greg said it
> >>> was "supported" and I assumed it was fine).
> >>> > So what is your idea here to overcome this?
> >>
> >> Ideally we should have all the cells definitions ready by the time nvmem is registered.
> >
> > I no longer think what you describe can happen because even though the
> > rootfs might be mounted, the daemons will only be 'started' once the
> > kernel is done starting and starts the init process, which means all
> > the devices have probed and all the cells have been registered as well.
> I think you forgot about modules in the above flow.
We request module insertion when the layout gets populated. By the time
userspace starts the kernel is done initializing, meaning that any
available nvmem layout module has already been loaded and the devices
probed -> the cells are there already.
Thanks,
Miquèl
prev parent reply other threads:[~2023-10-11 14:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 15:59 [PATCH v12 0/7] NVMEM cells in sysfs Miquel Raynal
2023-10-05 15:59 ` [PATCH v12 1/7] of: device: Export of_device_make_bus_id() Miquel Raynal
2023-10-06 17:02 ` Rob Herring
2023-10-05 15:59 ` [PATCH v12 2/7] nvmem: Clarify the situation when there is no DT node available Miquel Raynal
2023-10-06 11:41 ` Rafał Miłecki
2023-10-06 16:32 ` Miquel Raynal
2023-10-07 16:09 ` Rafał Miłecki
2023-10-08 13:39 ` Miquel Raynal
2023-10-09 9:44 ` Srinivas Kandagatla
2023-10-05 15:59 ` [PATCH v12 3/7] nvmem: Move of_nvmem_layout_get_container() in another header Miquel Raynal
2023-10-05 15:59 ` [PATCH v12 4/7] nvmem: Create a header for internal sharing Miquel Raynal
2023-10-05 15:59 ` [PATCH v12 5/7] nvmem: core: Rework layouts to become regular devices Miquel Raynal
2023-10-06 11:49 ` Rafał Miłecki
2023-10-06 16:33 ` Miquel Raynal
2023-10-07 16:31 ` Greg Kroah-Hartman
2023-10-11 10:33 ` Miquel Raynal
2023-10-08 13:42 ` kernel test robot
2023-10-09 9:44 ` Srinivas Kandagatla
2023-10-11 7:38 ` Miquel Raynal
2023-10-11 10:02 ` Srinivas Kandagatla
2023-10-11 10:58 ` Miquel Raynal
2023-10-05 15:59 ` [PATCH v12 6/7] ABI: sysfs-nvmem-cells: Expose cells through sysfs Miquel Raynal
2023-10-05 15:59 ` [PATCH v12 7/7] nvmem: core: " Miquel Raynal
2023-10-09 9:48 ` Srinivas Kandagatla
2023-10-11 7:15 ` Miquel Raynal
2023-10-11 8:27 ` Srinivas Kandagatla
2023-10-11 8:33 ` Miquel Raynal
2023-10-11 8:45 ` Srinivas Kandagatla
2023-10-11 8:58 ` Miquel Raynal
2023-10-11 9:26 ` Srinivas Kandagatla
2023-10-11 9:44 ` Miquel Raynal
2023-10-11 10:02 ` Srinivas Kandagatla
2023-10-11 11:09 ` Miquel Raynal
2023-10-11 13:56 ` Srinivas Kandagatla
2023-10-11 14:02 ` Miquel Raynal [this message]
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=20231011160243.4893729d@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=daniel@makrotopia.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=michael@walle.cc \
--cc=rafal@milecki.pl \
--cc=rdunlap@infradead.org \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wenst@chromium.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;
as well as URLs for NNTP newsgroup(s).