From: Daniel Golle <daniel@makrotopia.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
"Jens Axboe" <axboe@kernel.dk>,
"Dave Chinner" <dchinner@redhat.com>, "Jan Kara" <jack@suse.cz>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Li Lingfeng" <lilingfeng3@huawei.com>,
"Christian Brauner" <brauner@kernel.org>,
"Christian Heusel" <christian@heusel.eu>,
"Min Li" <min15.li@samsung.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Avri Altman" <avri.altman@wdc.com>,
"Hannes Reinecke" <hare@suse.de>,
"Christian Loehle" <CLoehle@hyperstone.com>,
"Bean Huo" <beanhuo@micron.com>, "Yeqi Fu" <asuk4.q@gmail.com>,
"Victor Shih" <victor.shih@genesyslogic.com.tw>,
"Christophe JAILLET" <christophe.jaillet@wanadoo.fr>,
"Dominique Martinet" <dominique.martinet@atmark-techno.com>,
"Ricardo B. Marliere" <ricardo@marliere.net>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 3/8] block: add new genhd flag GENHD_FL_NVMEM
Date: Thu, 18 Apr 2024 23:51:49 +0100 [thread overview]
Message-ID: <ZiGkBXIXfFP0pv_N@makrotopia.org> (raw)
In-Reply-To: <192acb8f-47b8-426c-bcc9-ef214a797f26@acm.org>
On Fri, Mar 22, 2024 at 12:22:32PM -0700, Bart Van Assche wrote:
> On 3/22/24 11:07, Daniel Golle wrote:
> > On Fri, Mar 22, 2024 at 10:49:48AM -0700, Bart Van Assche wrote:
> > > On 3/21/24 12:33, Daniel Golle wrote:
> > > > enum {
> > > > GENHD_FL_REMOVABLE = 1 << 0,
> > > > GENHD_FL_HIDDEN = 1 << 1,
> > > > GENHD_FL_NO_PART = 1 << 2,
> > > > + GENHD_FL_NVMEM = 1 << 3,
> > > > };
> > >
> > > What would break if this flag wouldn't exist?
> >
> > As both, MTD and UBI already act as NVMEM providers themselves, once
> > the user creates a ubiblock device or got CONFIG_MTD_BLOCK=y set in their
> > kernel configuration, we would run into problems because both, the block
> > layer as well as MTD or UBI would try to be an NVMEM provider for the same
> > device tree node.
>
> Why would both MTD and UBI try to be an NVMEM provider for the same
> device tree node?
I didn't mean that both MTD and UBI would **simultanously** try to act
as NVMEM providers for the same device tree node. What I meant was
that either of them can act as an NVMEM provider while at the same time
also providing an emulated block device (mtdblock xor ubiblock).
Hence those emulated block devices will have to be excluded from acting
as NVMEM providers. In this patch I suggest to do this by opt-in of
block drivers which should potentially provide NVMEM (typically mmcblk).
I apologize for the confusion and assume that wasn't clear from the
wording I've used. I hope it's more clear now.
Alternatively it could also be solved via opt-out of ubiblock and
mtdblock devices using the inverted flag (GENHD_FL_NO_NVMEM) --
however, this has previously been criticized and I was asked to rather
make it opt-in.[1]
> Why can't this patch series be implemented such that
> a partition UUID occurs in the device tree and such that other code
> scans for that partition UUID?
This is actually one way this very series allows one to handle this:
by identifying a partition using its partuuid.
However, it's also quite common that the MMC boot **hardware**
partitions are used to store MAC addresses and/or Wi-Fi calibration
data. In this case there is no partition table and the NVMEM provider
has to act directly on the whole disk device (which is only a few
megabytes in size in case of those mmcblkXbootY devices and never has
a partition table).
[1]: https://patchwork.kernel.org/comment/25432948/
next prev parent reply other threads:[~2024-04-18 22:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 19:31 [PATCH 0/8] block: implement NVMEM provider Daniel Golle
2024-03-21 19:32 ` [PATCH 1/8] dt-bindings: block: add basic bindings for block devices Daniel Golle
2024-03-21 19:39 ` Bart Van Assche
2024-03-21 20:26 ` Daniel Golle
2024-03-21 19:33 ` [PATCH 2/8] block: partitions: populate fwnode Daniel Golle
2024-03-21 19:33 ` [PATCH 3/8] block: add new genhd flag GENHD_FL_NVMEM Daniel Golle
2024-03-22 17:49 ` Bart Van Assche
2024-03-22 18:07 ` Daniel Golle
2024-03-22 19:22 ` Bart Van Assche
2024-04-18 22:51 ` Daniel Golle [this message]
2024-03-21 19:34 ` [PATCH 4/8] block: implement NVMEM provider Daniel Golle
2024-03-21 19:44 ` Bart Van Assche
2024-03-21 20:22 ` Daniel Golle
2024-03-22 17:52 ` Bart Van Assche
2024-03-22 18:11 ` Daniel Golle
2024-03-21 19:34 ` [PATCH 5/8] dt-bindings: mmc: mmc-card: add block device nodes Daniel Golle
2024-03-21 19:35 ` [PATCH 6/8] mmc: core: set card fwnode_handle Daniel Golle
2024-03-21 19:35 ` [PATCH 7/8] mmc: block: set fwnode of disk devices Daniel Golle
2024-03-21 19:36 ` [PATCH 8/8] mmc: block: set GENHD_FL_NVMEM Daniel Golle
2024-03-22 17:52 ` [PATCH 0/8] block: implement NVMEM provider Bart Van Assche
2024-03-22 18:02 ` Daniel Golle
2024-03-22 19:19 ` Bart Van Assche
2024-03-25 15:10 ` Rob Herring
2024-03-25 15:38 ` Daniel Golle
2024-03-26 20:24 ` Rob Herring
2024-03-26 21:28 ` Daniel Golle
2024-03-27 12:33 ` Rob Herring
2024-03-25 15:12 ` Rob Herring
2024-03-25 15:46 ` Daniel Golle
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=ZiGkBXIXfFP0pv_N@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=CLoehle@hyperstone.com \
--cc=adrian.hunter@intel.com \
--cc=asuk4.q@gmail.com \
--cc=avri.altman@wdc.com \
--cc=axboe@kernel.dk \
--cc=beanhuo@micron.com \
--cc=brauner@kernel.org \
--cc=bvanassche@acm.org \
--cc=christian@heusel.eu \
--cc=christophe.jaillet@wanadoo.fr \
--cc=conor+dt@kernel.org \
--cc=dchinner@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=dominique.martinet@atmark-techno.com \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lilingfeng3@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=min15.li@samsung.com \
--cc=ricardo@marliere.net \
--cc=robh@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=victor.shih@genesyslogic.com.tw \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).