From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Michael Walle <michael@walle.cc>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Robert Marko <robert.marko@sartura.hr>,
Luka Perkov <luka.perkov@sartura.hr>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v6 3/3] nvmem: core: Expose cells through sysfs
Date: Mon, 17 Jul 2023 18:41:17 +0200 [thread overview]
Message-ID: <20230717184117.065e9585@xps-13> (raw)
In-Reply-To: <f85f117a59586dc2e5df33e11b39c69f@walle.cc>
Hi Michael,
michael@walle.cc wrote on Mon, 17 Jul 2023 14:24:45 +0200:
> Hi,
>
> > There is one limitation though: if a layout is built as a module but is
> > not properly installed in the system and loaded manually with insmod
> > while the nvmem device driver was built-in, the cells won't appear in
> > sysfs. But if done like that, the cells won't be usable by the built-in
> > kernel drivers anyway.
>
> What is the difference between manual loading with insmod and automatic
> module loading? Or is the limitation, layout as M and device driver as Y
> doesn't work?
The nvmem core uses usermodehelper to load the relevant layout
module, but that only works if the module was installed correctly (make
modules_install).
The limitation is:
* Any storage device driver that registers an nvmem interface =y (or =m
but loaded before the nvmem layout)
* The relevant nvmem layout =m *and* not installed with make
modules_install
If you see a way to workaround this, let me know, but there is no way
we can enforce Kconfig dependencies between storage drivers and nvmem
layouts IMHO.
Thanks,
Miquèl
next prev parent reply other threads:[~2023-07-17 16:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 7:51 [PATCH v6 0/3] NVMEM cells in sysfs Miquel Raynal
2023-07-17 7:51 ` [PATCH v6 1/3] ABI: sysfs-nvmem-cells: Expose cells through sysfs Miquel Raynal
2023-07-23 19:39 ` John Thomson
2023-07-31 15:51 ` Miquel Raynal
2023-08-01 9:06 ` Srinivas Kandagatla
2023-08-01 16:50 ` Miquel Raynal
2023-07-17 7:51 ` [PATCH v6 2/3] nvmem: core: Create all cells before adding the nvmem device Miquel Raynal
2023-07-17 7:51 ` [PATCH v6 3/3] nvmem: core: Expose cells through sysfs Miquel Raynal
2023-07-17 12:24 ` Michael Walle
2023-07-17 16:41 ` Miquel Raynal [this message]
2023-07-17 14:32 ` Greg Kroah-Hartman
2023-07-17 16:33 ` Miquel Raynal
2023-07-17 16:59 ` Greg Kroah-Hartman
2023-07-31 15:33 ` Miquel Raynal
2023-08-01 9:56 ` Greg Kroah-Hartman
2023-08-01 16:54 ` Miquel Raynal
2023-07-18 10:26 ` Chen-Yu Tsai
2023-07-31 16:05 ` Miquel Raynal
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=20230717184117.065e9585@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=michael@walle.cc \
--cc=rdunlap@infradead.org \
--cc=robert.marko@sartura.hr \
--cc=srinivas.kandagatla@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.