Message-ID: <ZvqfbNDfI2QWZEBg@smile.fi.intel.com>
Date: Mon, 30 Sep 2024 15:54:04 +0300
From: Andy Shevchenko <andy@...nel.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Jens Axboe <axboe@...nel.dk>, Jonathan Corbet <corbet@....net>,
	Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Kees Cook <kees@...nel.org>,
	Daniel Golle <daniel@...rotopia.org>,
	INAGAKI Hiroshi <musashino.open@...il.com>,
	Christian Brauner <brauner@...nel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Li Lingfeng <lilingfeng3@...wei.com>,
	Ming Lei <ming.lei@...hat.com>,
	Christian Heusel <christian@...sel.eu>, linux-block@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Lorenzo Bianconi <lorenzo@...nel.org>, upstream@...oha.com
Subject: Re: [PATCH v4 0/5] block: partition table OF support

On Mon, Sep 30, 2024 at 01:30:07PM +0200, Christian Marangi wrote:
> Hi,
> this is an initial proposal to complete support for manually defining
> partition table.
> 
> Some background on this. Many OEM on embedded device (modem, router...)
> are starting to migrate from NOR/NAND flash to eMMC. The reason for this
> is that OEM are starting to require more and more space for the firmware
> and price difference is becoming so little that using eMMC is only benefits
> and no cons.
> 
> Given these reason, OEM are also using very custom way to provide a
> partition table and doesn't relay on common method like writing a table
> on the eMMC.
> 
> One way that is commonly used is to hardcode the partition table and
> pass it to the system via various way (cmdline, special glue driver,
> block2mtd...)
> This way is also used on Android where the partition table
> is passed from the bootloader via cmdline.
> 
> One reason to use this method is to save space on the device and to
> permit more flexibility on partition handling.
> 
> What this series does is complete support for this feature.
> It's possible to use the cmdline to define a partition table similar
> to how it's done for MTD but this is problematic for a number of device
> where tweaking the cmdline is not possible. This series adds OF support
> to make it possible to define a partition table in the Device Tree.
> 
> We implement a similar schema to the MTD fixed-partition, where we define
> a "label" and a "reg" with "offset" and "size".
> 
> A new block partition parser is introduced that check if the block device
> have an OF node attached and check if a fixed-partition table is defined.
> 
> If a correct node is found, then partition table is filled. cmdline will
> still have priority to this new parser.
> 
> Some block device also implement boot1 and boot2 additional disk. Similar
> to the cmdline parser, these disk can have OF support using the
> "partitions-boot0" and "partitions-boot1" additional node.
> 
> It's also completed support for declaring partition as read-only as this
> feature was introduced but never finished in the cmdline parser.


I'm not sure I fully understood the problem you are trying to solve.
I have a device at hand that uses eMMC (and was produced almost ten years ago).
This device has a regular GPT on eMMC and no kernel needs to be patched for that.
So, why is it a problem for the mentioned OEMs to use standard GPT approach?

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists