[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <192acb8f-47b8-426c-bcc9-ef214a797f26@acm.org>
Date: Fri, 22 Mar 2024 12:22:32 -0700
From: Bart Van Assche <bvanassche@....org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
Jens Axboe <axboe@...nel.dk>, Dave Chinner <dchinner@...hat.com>,
Jan Kara <jack@...e.cz>, Thomas Weißschuh
<linux@...ssschuh.net>, Damien Le Moal <dlemoal@...nel.org>,
Li Lingfeng <lilingfeng3@...wei.com>, Christian Brauner
<brauner@...nel.org>, Christian Heusel <christian@...sel.eu>,
Min Li <min15.li@...sung.com>, Adrian Hunter <adrian.hunter@...el.com>,
Avri Altman <avri.altman@....com>, Hannes Reinecke <hare@...e.de>,
Christian Loehle <CLoehle@...erstone.com>, Bean Huo <beanhuo@...ron.com>,
Yeqi Fu <asuk4.q@...il.com>, Victor Shih <victor.shih@...esyslogic.com.tw>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Dominique Martinet <dominique.martinet@...ark-techno.com>,
"Ricardo B. Marliere" <ricardo@...liere.net>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
linux-block@...r.kernel.org
Subject: Re: [PATCH 3/8] block: add new genhd flag GENHD_FL_NVMEM
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? 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?
Thanks,
Bart.
Powered by blists - more mailing lists