[PATCH v6 0/6] block: partition table OF support

[PATCH v6 0/6] block: partition table OF support

[Christian Marangi]

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 disk device
have an OF node attached and check if a fixed-partition table is defined.

block driver can use the device_add_of_disk() function to register a new
disk and attach a fwnode to it for usage with the OF parser.

This permits flexibility from the driver side to implement the partitions
node in different nodes across different block devices.

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-boot1" and "partitions-boot2" additional node. Also eMMC
gp 1/2/3/4 disk are supported.

It's also completed support for declaring partition as read-only as this
feature was introduced but never finished in the cmdline parser.

I hope this solution is better accepted as downstream this is becoming
a real problem with a growing number of strange solution for the simple
task of providing a fixed partition table.

Changes v6:
- Rename device_add_of_disk() to add_disk_fwnode()
- Add kdocs for add_disk_fwnode()
- Improve variables order in OF block partition code
- Add Reviewed-by tag
Changes v5:
- Introduce device_add_of_disk() function
- Detach eMMC special disk from OF block partition code and move
  parsing to eMMC block driver (as requested by Christoph)
- Rework OF block partition to use the device disk device_node
- Extend support for eMMC GP1/2/3/4
- Rename boot0/1 to boot1/2
- Drop strends patch (unused now)
Changes v4:
- Fix wrong description and title in Kconfig
- Validate reg len with addr and size cells
- Drop offset 0 constraint (not needed)
- Rework bytes to sector conversion
- Follow common logic with ignore partitions after state->limit
- Better handle device_node put
- Add suggested strends string helper
Changes v3:
- Out of RFC
- Drop partition schema generalization and simplify it
- Require fixed-partitions compatible to adapt to MTD schema
- Make label property optional and fallback to node name
Changes v2:
- Reference bytes in DT instead of Sector Size
- Validate offset and size after Sector Size conversion
- Limit boot0 and boot1 to eMMC and add comments about JEDEC spec
- Generalize MTD partition schema and introduce block partitions schema
- Add missing code to actually attach the OF parser to block partition core
- Add reviewed by tag for read-only patch

Christian Marangi (6):
  block: add support for defining read-only partitions
  docs: block: Document support for read-only partition in cmdline part
  block: introduce add_disk_fwnode()
  mmc: block: attach partitions fwnode if found in mmc-card
  block: add support for partition table defined in OF
  dt-bindings: mmc: Document support for partition table in mmc-card

 Documentation/block/cmdline-partition.rst     |   5 +-
 .../devicetree/bindings/mmc/mmc-card.yaml     |  52 +++++++++
 block/blk.h                                   |   1 +
 block/genhd.c                                 |  28 ++++-
 block/partitions/Kconfig                      |   9 ++
 block/partitions/Makefile                     |   1 +
 block/partitions/check.h                      |   1 +
 block/partitions/cmdline.c                    |   3 +
 block/partitions/core.c                       |   6 +
 block/partitions/of.c                         | 110 ++++++++++++++++++
 drivers/mmc/core/block.c                      |  55 ++++++++-
 include/linux/blkdev.h                        |   3 +
 12 files changed, 268 insertions(+), 6 deletions(-)
 create mode 100644 block/partitions/of.c

-- 
2.45.2

[PATCH v6 1/6] block: add support for defining read-only partitions

[Christian Marangi]

Add support for defining read-only partitions and complete support for
it in the cmdline partition parser as the additional "ro" after a
partition is scanned but never actually applied.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 block/blk.h                | 1 +
 block/partitions/cmdline.c | 3 +++
 block/partitions/core.c    | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/block/blk.h b/block/blk.h
index c718e4291db0..f300212d3e98 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -558,6 +558,7 @@ void blk_free_ext_minor(unsigned int minor);
 #define ADDPART_FLAG_NONE	0
 #define ADDPART_FLAG_RAID	1
 #define ADDPART_FLAG_WHOLEDISK	2
+#define ADDPART_FLAG_READONLY	4
 int bdev_add_partition(struct gendisk *disk, int partno, sector_t start,
 		sector_t length);
 int bdev_del_partition(struct gendisk *disk, int partno);
diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index 152c85df92b2..da3e719d8e51 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -237,6 +237,9 @@ static int add_part(int slot, struct cmdline_subpart *subpart,
 	put_partition(state, slot, subpart->from >> 9,
 		      subpart->size >> 9);
 
+	if (subpart->flags & PF_RDONLY)
+		state->parts[slot].flags |= ADDPART_FLAG_READONLY;
+
 	info = &state->parts[slot].info;
 
 	strscpy(info->volname, subpart->name, sizeof(info->volname));
diff --git a/block/partitions/core.c b/block/partitions/core.c
index ab76e64f0f6c..abad6c83db8f 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -373,6 +373,9 @@ static struct block_device *add_partition(struct gendisk *disk, int partno,
 			goto out_del;
 	}
 
+	if (flags & ADDPART_FLAG_READONLY)
+		bdev_set_flag(bdev, BD_READ_ONLY);
+
 	/* everything is up and running, commence */
 	err = xa_insert(&disk->part_tbl, partno, bdev, GFP_KERNEL);
 	if (err)
-- 
2.45.2

[PATCH v6 2/6] docs: block: Document support for read-only partition in cmdline part

[Christian Marangi]

Document support for read-only partition in cmdline partition for block
devices by appending "ro" after the (partition name).

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 Documentation/block/cmdline-partition.rst | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/block/cmdline-partition.rst b/Documentation/block/cmdline-partition.rst
index 530bedff548a..526ba201dddc 100644
--- a/Documentation/block/cmdline-partition.rst
+++ b/Documentation/block/cmdline-partition.rst
@@ -39,13 +39,16 @@ blkdevparts=<blkdev-def>[;<blkdev-def>]
     create a link to block device partition with the name "PARTNAME".
     User space application can access partition by partition name.
 
+ro
+    read-only. Flag the partition as read-only.
+
 Example:
 
     eMMC disk names are "mmcblk0" and "mmcblk0boot0".
 
   bootargs::
 
-    'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
+    'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot)ro,-(kernel)'
 
   dmesg::
 
-- 
2.45.2

[PATCH v6 3/6] block: introduce add_disk_fwnode()

[Christian Marangi]

Introduce add_disk_fwnode() as a replacement of device_add_disk() that
permits to pass and attach a fwnode to disk dev.

This variant can be useful for eMMC that might have the partition table
for the disk defined in DT. A parser can later make use of the attached
fwnode to parse the related table and init the hardcoded partition for
the disk.

device_add_disk() is converted to a simple wrapper of add_disk_fwnode()
with the fwnode entry set as NULL.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 block/genhd.c          | 28 ++++++++++++++++++++++++----
 include/linux/blkdev.h |  3 +++
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 1c05dd4c6980..bc30eee7ab16 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -383,16 +383,18 @@ int disk_scan_partitions(struct gendisk *disk, blk_mode_t mode)
 }
 
 /**
- * device_add_disk - add disk information to kernel list
+ * add_disk_fwnode - add disk information to kernel list with fwnode
  * @parent: parent device for the disk
  * @disk: per-device partitioning information
  * @groups: Additional per-device sysfs groups
+ * @fwnode: attached disk fwnode
  *
  * This function registers the partitioning information in @disk
- * with the kernel.
+ * with the kernel. Also attach a fwnode to the disk device.
  */
-int __must_check device_add_disk(struct device *parent, struct gendisk *disk,
-				 const struct attribute_group **groups)
+int __must_check add_disk_fwnode(struct device *parent, struct gendisk *disk,
+				 const struct attribute_group **groups,
+				 struct fwnode_handle *fwnode)
 
 {
 	struct device *ddev = disk_to_dev(disk);
@@ -452,6 +454,8 @@ int __must_check device_add_disk(struct device *parent, struct gendisk *disk,
 	ddev->parent = parent;
 	ddev->groups = groups;
 	dev_set_name(ddev, "%s", disk->disk_name);
+	if (fwnode)
+		device_set_node(ddev, fwnode);
 	if (!(disk->flags & GENHD_FL_HIDDEN))
 		ddev->devt = MKDEV(disk->major, disk->first_minor);
 	ret = device_add(ddev);
@@ -553,6 +557,22 @@ int __must_check device_add_disk(struct device *parent, struct gendisk *disk,
 		elevator_exit(disk->queue);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(add_disk_fwnode);
+
+/**
+ * device_add_disk - add disk information to kernel list
+ * @parent: parent device for the disk
+ * @disk: per-device partitioning information
+ * @groups: Additional per-device sysfs groups
+ *
+ * This function registers the partitioning information in @disk
+ * with the kernel.
+ */
+int __must_check device_add_disk(struct device *parent, struct gendisk *disk,
+				 const struct attribute_group **groups)
+{
+	return add_disk_fwnode(parent, disk, groups, NULL);
+}
 EXPORT_SYMBOL(device_add_disk);
 
 static void blk_report_disk_dead(struct gendisk *disk, bool surprise)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index bf1aa951fda2..c0f50f977f5e 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -725,6 +725,9 @@ static inline unsigned int blk_queue_depth(struct request_queue *q)
 #define for_each_bio(_bio)		\
 	for (; _bio; _bio = _bio->bi_next)
 
+int __must_check add_disk_fwnode(struct device *parent, struct gendisk *disk,
+				 const struct attribute_group **groups,
+				 struct fwnode_handle *fwnode);
 int __must_check device_add_disk(struct device *parent, struct gendisk *disk,
 				 const struct attribute_group **groups);
 static inline int __must_check add_disk(struct gendisk *disk)
-- 
2.45.2

[PATCH v6 4/6] mmc: block: attach partitions fwnode if found in mmc-card

[Christian Marangi]

Attach partitions fwnode if found in mmc-card and register disk with it.

This permits block partition to reference the node and register a
partition table defined in DT for the special case for embedded device
that doesn't have a partition table flashed but have an hardcoded
partition table passed from the system.

JEDEC BOOT partition boot0/boot1 are supported but in DT we refer with
the JEDEC name of boot1 and boot2 to better adhere to documentation.

Also JEDEC GP partition gp0/1/2/3 are supported but in DT we refer with
the JEDEC name of gp1/2/3/4 to better adhere to documentration.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/mmc/core/block.c | 55 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index f58bea534004..d7eadf2b407f 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2501,6 +2501,56 @@ static inline int mmc_blk_readonly(struct mmc_card *card)
 	       !(card->csd.cmdclass & CCC_BLOCK_WRITE);
 }
 
+/*
+ * Search for a declared partitions node for the disk in mmc-card related node.
+ *
+ * This is to permit support for partition table defined in DT in special case
+ * where a partition table is not written in the disk and is expected to be
+ * passed from the running system.
+ *
+ * For the user disk, "partitions" node is searched.
+ * For the special HW disk, "partitions-" node with the appended name is used
+ * following this conversion table (to adhere to JEDEC naming)
+ * - boot0 -> partitions-boot1
+ * - boot1 -> partitions-boot2
+ * - gp0 -> partitions-gp1
+ * - gp1 -> partitions-gp2
+ * - gp2 -> partitions-gp3
+ * - gp3 -> partitions-gp4
+ */
+static struct fwnode_handle *mmc_blk_get_partitions_node(struct device *mmc_dev,
+							 const char *subname)
+{
+	const char *node_name = "partitions";
+
+	if (subname) {
+		mmc_dev = mmc_dev->parent;
+
+		/*
+		 * Check if we are allocating a BOOT disk boot0/1 disk.
+		 * In DT we use the JEDEC naming boot1/2.
+		 */
+		if (!strcmp(subname, "boot0"))
+			node_name = "partitions-boot1";
+		if (!strcmp(subname, "boot1"))
+			node_name = "partitions-boot2";
+		/*
+		 * Check if we are allocating a GP disk gp0/1/2/3 disk.
+		 * In DT we use the JEDEC naming gp1/2/3/4.
+		 */
+		if (!strcmp(subname, "gp0"))
+			node_name = "partitions-gp1";
+		if (!strcmp(subname, "gp1"))
+			node_name = "partitions-gp2";
+		if (!strcmp(subname, "gp2"))
+			node_name = "partitions-gp3";
+		if (!strcmp(subname, "gp3"))
+			node_name = "partitions-gp4";
+	}
+
+	return device_get_named_child_node(mmc_dev, node_name);
+}
+
 static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 					      struct device *parent,
 					      sector_t size,
@@ -2509,6 +2559,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 					      int area_type,
 					      unsigned int part_type)
 {
+	struct fwnode_handle *disk_fwnode;
 	struct mmc_blk_data *md;
 	int devidx, ret;
 	char cap_str[10];
@@ -2610,7 +2661,9 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 	/* used in ->open, must be set before add_disk: */
 	if (area_type == MMC_BLK_DATA_AREA_MAIN)
 		dev_set_drvdata(&card->dev, md);
-	ret = device_add_disk(md->parent, md->disk, mmc_disk_attr_groups);
+	disk_fwnode = mmc_blk_get_partitions_node(parent, subname);
+	ret = add_disk_fwnode(md->parent, md->disk, mmc_disk_attr_groups,
+			      disk_fwnode);
 	if (ret)
 		goto err_put_disk;
 	return md;
-- 
2.45.2

[PATCH v6 5/6] block: add support for partition table defined in OF

[Christian Marangi]

Add support for partition table defined in Device Tree. Similar to how
it's done with MTD, add support for defining a fixed partition table in
device tree.

A common scenario for this is fixed block (eMMC) embedded devices that
have no MBR or GPT partition table to save storage space. Bootloader
access the block device with absolute address of data.

This is to complete the functionality with an equivalent implementation
with providing partition table with bootargs, for case where the booargs
can't be modified and tweaking the Device Tree is the only solution to
have an usabe partition table.

The implementation follow the fixed-partitions parser used on MTD
devices where a "partitions" node is expected to be declared with
"fixed-partitions" compatible in the OF node of the disk device
(mmc-card for eMMC for example) and each child node declare a label
and a reg with offset and size. If label is not declared, the node name
is used as fallback. Eventually is also possible to declare the read-only
property to flag the partition as read-only.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 block/partitions/Kconfig  |   9 ++++
 block/partitions/Makefile |   1 +
 block/partitions/check.h  |   1 +
 block/partitions/core.c   |   3 ++
 block/partitions/of.c     | 110 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 124 insertions(+)
 create mode 100644 block/partitions/of.c

diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig
index 7aff4eb81c60..ce17e41451af 100644
--- a/block/partitions/Kconfig
+++ b/block/partitions/Kconfig
@@ -270,4 +270,13 @@ config CMDLINE_PARTITION
 	  Say Y here if you want to read the partition table from bootargs.
 	  The format for the command line is just like mtdparts.
 
+config OF_PARTITION
+	bool "Device Tree partition support" if PARTITION_ADVANCED
+	depends on OF
+	help
+	  Say Y here if you want to enable support for partition table
+	  defined in Device Tree. (mainly for eMMC)
+	  The format for the device tree node is just like MTD fixed-partition
+	  schema.
+
 endmenu
diff --git a/block/partitions/Makefile b/block/partitions/Makefile
index a7f05cdb02a8..25d424922c6e 100644
--- a/block/partitions/Makefile
+++ b/block/partitions/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_CMDLINE_PARTITION) += cmdline.o
 obj-$(CONFIG_MAC_PARTITION) += mac.o
 obj-$(CONFIG_LDM_PARTITION) += ldm.o
 obj-$(CONFIG_MSDOS_PARTITION) += msdos.o
+obj-$(CONFIG_OF_PARTITION) += of.o
 obj-$(CONFIG_OSF_PARTITION) += osf.o
 obj-$(CONFIG_SGI_PARTITION) += sgi.o
 obj-$(CONFIG_SUN_PARTITION) += sun.o
diff --git a/block/partitions/check.h b/block/partitions/check.h
index 8d70a880c372..e5c1c61eb353 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -62,6 +62,7 @@ int karma_partition(struct parsed_partitions *state);
 int ldm_partition(struct parsed_partitions *state);
 int mac_partition(struct parsed_partitions *state);
 int msdos_partition(struct parsed_partitions *state);
+int of_partition(struct parsed_partitions *state);
 int osf_partition(struct parsed_partitions *state);
 int sgi_partition(struct parsed_partitions *state);
 int sun_partition(struct parsed_partitions *state);
diff --git a/block/partitions/core.c b/block/partitions/core.c
index abad6c83db8f..dc21734b00ec 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -43,6 +43,9 @@ static int (*const check_part[])(struct parsed_partitions *) = {
 #ifdef CONFIG_CMDLINE_PARTITION
 	cmdline_partition,
 #endif
+#ifdef CONFIG_OF_PARTITION
+	of_partition,		/* cmdline have priority to OF */
+#endif
 #ifdef CONFIG_EFI_PARTITION
 	efi_partition,		/* this must come before msdos */
 #endif
diff --git a/block/partitions/of.c b/block/partitions/of.c
new file mode 100644
index 000000000000..4e760fdffb3f
--- /dev/null
+++ b/block/partitions/of.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/blkdev.h>
+#include <linux/major.h>
+#include <linux/of.h>
+#include <linux/string.h>
+#include "check.h"
+
+static int validate_of_partition(struct device_node *np, int slot)
+{
+	u64 offset, size;
+	int len;
+
+	const __be32 *reg = of_get_property(np, "reg", &len);
+	int a_cells = of_n_addr_cells(np);
+	int s_cells = of_n_size_cells(np);
+
+	/* Make sure reg len match the expected addr and size cells */
+	if (len / sizeof(*reg) != a_cells + s_cells)
+		return -EINVAL;
+
+	/* Validate offset conversion from bytes to sectors */
+	offset = of_read_number(reg, a_cells);
+	if (offset % SECTOR_SIZE)
+		return -EINVAL;
+
+	/* Validate size conversion from bytes to sectors */
+	size = of_read_number(reg + a_cells, s_cells);
+	if (!size || size % SECTOR_SIZE)
+		return -EINVAL;
+
+	return 0;
+}
+
+static void add_of_partition(struct parsed_partitions *state, int slot,
+			     struct device_node *np)
+{
+	struct partition_meta_info *info;
+	char tmp[sizeof(info->volname) + 4];
+	const char *partname;
+	int len;
+
+	const __be32 *reg = of_get_property(np, "reg", &len);
+	int a_cells = of_n_addr_cells(np);
+	int s_cells = of_n_size_cells(np);
+
+	/* Convert bytes to sector size */
+	u64 offset = of_read_number(reg, a_cells) / SECTOR_SIZE;
+	u64 size = of_read_number(reg + a_cells, s_cells) / SECTOR_SIZE;
+
+	put_partition(state, slot, offset, size);
+
+	if (of_property_read_bool(np, "read-only"))
+		state->parts[slot].flags |= ADDPART_FLAG_READONLY;
+
+	/*
+	 * Follow MTD label logic, search for label property,
+	 * fallback to node name if not found.
+	 */
+	info = &state->parts[slot].info;
+	partname = of_get_property(np, "label", &len);
+	if (!partname)
+		partname = of_get_property(np, "name", &len);
+	strscpy(info->volname, partname, sizeof(info->volname));
+
+	snprintf(tmp, sizeof(tmp), "(%s)", info->volname);
+	strlcat(state->pp_buf, tmp, PAGE_SIZE);
+}
+
+int of_partition(struct parsed_partitions *state)
+{
+	struct device *ddev = disk_to_dev(state->disk);
+	struct device_node *np;
+	int slot;
+
+	struct device_node *partitions_np = of_node_get(ddev->of_node);
+
+	if (!partitions_np ||
+	    !of_device_is_compatible(partitions_np, "fixed-partitions"))
+		return 0;
+
+	slot = 1;
+	/* Validate parition offset and size */
+	for_each_child_of_node(partitions_np, np) {
+		if (validate_of_partition(np, slot)) {
+			of_node_put(np);
+			of_node_put(partitions_np);
+
+			return -1;
+		}
+
+		slot++;
+	}
+
+	slot = 1;
+	for_each_child_of_node(partitions_np, np) {
+		if (slot >= state->limit) {
+			of_node_put(np);
+			break;
+		}
+
+		add_of_partition(state, slot, np);
+
+		slot++;
+	}
+
+	strlcat(state->pp_buf, "\n", PAGE_SIZE);
+
+	return 1;
+}
-- 
2.45.2

[PATCH v6 6/6] dt-bindings: mmc: Document support for partition table in mmc-card

[Christian Marangi]

Document support for defining a partition table in the mmc-card node.

This is needed if the eMMC doesn't have a partition table written and
the bootloader of the device load data by using absolute offset of the
block device. This is common on embedded device that have eMMC installed
to save space and have non removable block devices.

If an OF partition table is detected, any partition table written in the
eMMC will be ignored and won't be parsed.

eMMC provide a generic disk for user data and if supported (JEDEC 4.4+)
also provide two additional disk ("boot1" and "boot2") for special usage
of boot operation where normally is stored the bootloader or boot info.
New JEDEC version also supports up to 4 GP partition for other usage
called "gp1", "gp2", "gp3", "gp4".

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
 .../devicetree/bindings/mmc/mmc-card.yaml     | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index fd347126449a..1d91d4272de0 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -13,6 +13,10 @@ description: |
   This documents describes the devicetree bindings for a mmc-host controller
   child node describing a mmc-card / an eMMC.
 
+  It's possible to define a fixed partition table for an eMMC for the user
+  partition, the 2 BOOT partition (boot1/2) and the 4 GP (gp1/2/3/4) if supported
+  by the eMMC.
+
 properties:
   compatible:
     const: mmc-card
@@ -26,6 +30,24 @@ properties:
       Use this to indicate that the mmc-card has a broken hpi
       implementation, and that hpi should not be used.
 
+patternProperties:
+  "^partitions(-boot[12]|-gp[14])?$":
+    $ref: /schemas/mtd/partitions/partitions.yaml
+
+    patternProperties:
+      "^partition@[0-9a-f]+$":
+        $ref: /schemas/mtd/partitions/partition.yaml
+
+        properties:
+          reg:
+            description: Must be multiple of 512 as it's converted
+              internally from bytes to SECTOR_SIZE (512 bytes)
+
+        required:
+          - reg
+
+        unevaluatedProperties: false
+
 required:
   - compatible
   - reg
@@ -42,6 +64,36 @@ examples:
             compatible = "mmc-card";
             reg = <0>;
             broken-hpi;
+
+            partitions {
+                compatible = "fixed-partitions";
+
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+                partition@0 {
+                    label = "kernel"; /* Kernel */
+                    reg = <0x0 0x2000000>; /* 32 MB */
+                };
+
+                partition@2000000 {
+                    label = "rootfs";
+                    reg = <0x2000000 0x40000000>; /* 1GB */
+                };
+            };
+
+            partitions-boot1 {
+                compatible = "fixed-partitions";
+
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+                partition@0 {
+                    label = "bl";
+                    reg = <0x0 0x2000000>; /* 32MB */
+                    read-only;
+                };
+            };
         };
     };
 
-- 
2.45.2

Re: [PATCH v6 3/6] block: introduce add_disk_fwnode()

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH v6 0/6] block: partition table OF support

[Jens Axboe]

On Thu, 03 Oct 2024 00:11:40 +0200, Christian Marangi wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/6] block: add support for defining read-only partitions
      commit: 03cb793b26834ddca170ba87057c8f883772dd45
[2/6] docs: block: Document support for read-only partition in cmdline part
      commit: 62adb971e515d1bb0e9e555f3dd1d5dc948cf6a1
[3/6] block: introduce add_disk_fwnode()
      commit: e5f587242b6072ffab4f4a084a459a59f3035873
[4/6] mmc: block: attach partitions fwnode if found in mmc-card
      commit: 45ff6c340ddfc2dade74d5b7a8962c778ab7042c
[5/6] block: add support for partition table defined in OF
      commit: 884555b557e5e6d41c866e2cd8d7b32f50ec974b
[6/6] dt-bindings: mmc: Document support for partition table in mmc-card
      commit: 06f39701d0666d89dd3c86ff0b163c7139b7ba2d

Best regards,
-- 
Jens Axboe

Re: [PATCH v6 0/6] block: partition table OF support

[Ulf Hansson]

On Mon, 7 Oct 2024 at 22:22, Jens Axboe <axboe@kernel.dk> wrote:
>
>
> On Thu, 03 Oct 2024 00:11:40 +0200, Christian Marangi wrote:
> > 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.
> >
> > [...]
>
> Applied, thanks!
>
> [1/6] block: add support for defining read-only partitions
>       commit: 03cb793b26834ddca170ba87057c8f883772dd45
> [2/6] docs: block: Document support for read-only partition in cmdline part
>       commit: 62adb971e515d1bb0e9e555f3dd1d5dc948cf6a1
> [3/6] block: introduce add_disk_fwnode()
>       commit: e5f587242b6072ffab4f4a084a459a59f3035873
> [4/6] mmc: block: attach partitions fwnode if found in mmc-card
>       commit: 45ff6c340ddfc2dade74d5b7a8962c778ab7042c
> [5/6] block: add support for partition table defined in OF
>       commit: 884555b557e5e6d41c866e2cd8d7b32f50ec974b
> [6/6] dt-bindings: mmc: Document support for partition table in mmc-card
>       commit: 06f39701d0666d89dd3c86ff0b163c7139b7ba2d
>

I think we may need another merging strategy for this as I quite big
changes in the pipe for the mmc block device this cycle.

Would it be possible for you to drop the mmc patches and instead share
an immutable branch with the block changes that I can pull in, so I
can take the mmc changes?

Kind regards
Uffe

Re: [PATCH v6 0/6] block: partition table OF support

[Jens Axboe]

On 10/8/24 3:10 AM, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 22:22, Jens Axboe <axboe@kernel.dk> wrote:
>>
>>
>> On Thu, 03 Oct 2024 00:11:40 +0200, Christian Marangi wrote:
>>> 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.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/6] block: add support for defining read-only partitions
>>       commit: 03cb793b26834ddca170ba87057c8f883772dd45
>> [2/6] docs: block: Document support for read-only partition in cmdline part
>>       commit: 62adb971e515d1bb0e9e555f3dd1d5dc948cf6a1
>> [3/6] block: introduce add_disk_fwnode()
>>       commit: e5f587242b6072ffab4f4a084a459a59f3035873
>> [4/6] mmc: block: attach partitions fwnode if found in mmc-card
>>       commit: 45ff6c340ddfc2dade74d5b7a8962c778ab7042c
>> [5/6] block: add support for partition table defined in OF
>>       commit: 884555b557e5e6d41c866e2cd8d7b32f50ec974b
>> [6/6] dt-bindings: mmc: Document support for partition table in mmc-card
>>       commit: 06f39701d0666d89dd3c86ff0b163c7139b7ba2d
>>
> 
> I think we may need another merging strategy for this as I quite big
> changes in the pipe for the mmc block device this cycle.
> 
> Would it be possible for you to drop the mmc patches and instead share
> an immutable branch with the block changes that I can pull in, so I
> can take the mmc changes?

I mean we can, but the mmc changes in here are pretty self contained.
I'd rather avoid rebasing the block tree for that, given how small the
changes are. If it conflicts, should be easy enough to resolve.

You an also just pull in the block tree now and resolve the conflict.
There's not a whole lot in there yet outside of this series.

-- 
Jens Axboe

Re: [PATCH v6 0/6] block: partition table OF support

[Ulf Hansson]

On Tue, 8 Oct 2024 at 15:24, Jens Axboe <axboe@kernel.dk> wrote:
>
> On 10/8/24 3:10 AM, Ulf Hansson wrote:
> > On Mon, 7 Oct 2024 at 22:22, Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >>
> >> On Thu, 03 Oct 2024 00:11:40 +0200, Christian Marangi wrote:
> >>> 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.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [1/6] block: add support for defining read-only partitions
> >>       commit: 03cb793b26834ddca170ba87057c8f883772dd45
> >> [2/6] docs: block: Document support for read-only partition in cmdline part
> >>       commit: 62adb971e515d1bb0e9e555f3dd1d5dc948cf6a1
> >> [3/6] block: introduce add_disk_fwnode()
> >>       commit: e5f587242b6072ffab4f4a084a459a59f3035873
> >> [4/6] mmc: block: attach partitions fwnode if found in mmc-card
> >>       commit: 45ff6c340ddfc2dade74d5b7a8962c778ab7042c
> >> [5/6] block: add support for partition table defined in OF
> >>       commit: 884555b557e5e6d41c866e2cd8d7b32f50ec974b
> >> [6/6] dt-bindings: mmc: Document support for partition table in mmc-card
> >>       commit: 06f39701d0666d89dd3c86ff0b163c7139b7ba2d
> >>
> >
> > I think we may need another merging strategy for this as I quite big
> > changes in the pipe for the mmc block device this cycle.
> >
> > Would it be possible for you to drop the mmc patches and instead share
> > an immutable branch with the block changes that I can pull in, so I
> > can take the mmc changes?
>
> I mean we can, but the mmc changes in here are pretty self contained.
> I'd rather avoid rebasing the block tree for that, given how small the
> changes are. If it conflicts, should be easy enough to resolve.

Okay, let's give it a try and see how it goes.

>
> You an also just pull in the block tree now and resolve the conflict.
> There's not a whole lot in there yet outside of this series.

Let's wait and see. If we get some conflicts, you can always set a tag
to the latest of the mmc commits in your tree that I can pull instead.

Kind regards
Uffe

Re: [PATCH v6 0/6] block: partition table OF support

[Jens Axboe]

On 10/8/24 8:33 AM, Ulf Hansson wrote:
> On Tue, 8 Oct 2024 at 15:24, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 10/8/24 3:10 AM, Ulf Hansson wrote:
>>> On Mon, 7 Oct 2024 at 22:22, Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>>
>>>> On Thu, 03 Oct 2024 00:11:40 +0200, Christian Marangi wrote:
>>>>> 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.
>>>>>
>>>>> [...]
>>>>
>>>> Applied, thanks!
>>>>
>>>> [1/6] block: add support for defining read-only partitions
>>>>       commit: 03cb793b26834ddca170ba87057c8f883772dd45
>>>> [2/6] docs: block: Document support for read-only partition in cmdline part
>>>>       commit: 62adb971e515d1bb0e9e555f3dd1d5dc948cf6a1
>>>> [3/6] block: introduce add_disk_fwnode()
>>>>       commit: e5f587242b6072ffab4f4a084a459a59f3035873
>>>> [4/6] mmc: block: attach partitions fwnode if found in mmc-card
>>>>       commit: 45ff6c340ddfc2dade74d5b7a8962c778ab7042c
>>>> [5/6] block: add support for partition table defined in OF
>>>>       commit: 884555b557e5e6d41c866e2cd8d7b32f50ec974b
>>>> [6/6] dt-bindings: mmc: Document support for partition table in mmc-card
>>>>       commit: 06f39701d0666d89dd3c86ff0b163c7139b7ba2d
>>>>
>>>
>>> I think we may need another merging strategy for this as I quite big
>>> changes in the pipe for the mmc block device this cycle.
>>>
>>> Would it be possible for you to drop the mmc patches and instead share
>>> an immutable branch with the block changes that I can pull in, so I
>>> can take the mmc changes?
>>
>> I mean we can, but the mmc changes in here are pretty self contained.
>> I'd rather avoid rebasing the block tree for that, given how small the
>> changes are. If it conflicts, should be easy enough to resolve.
> 
> Okay, let's give it a try and see how it goes.
> 
>>
>> You an also just pull in the block tree now and resolve the conflict.
>> There's not a whole lot in there yet outside of this series.
> 
> Let's wait and see. If we get some conflicts, you can always set a tag
> to the latest of the mmc commits in your tree that I can pull instead.

Yep, sounds like plan!

-- 
Jens Axboe

Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6] block: add support for partition table defined in OF)

[Ahmad Fatoum]

Hi,

sorry for not writing sooner. I only noticed this now.

On 03.10.24 00:11, Christian Marangi wrote:
> Add support for partition table defined in Device Tree. Similar to how
> it's done with MTD, add support for defining a fixed partition table in
> device tree.
> 
> A common scenario for this is fixed block (eMMC) embedded devices that
> have no MBR or GPT partition table to save storage space. Bootloader
> access the block device with absolute address of data.

How common are these? I never worked with a system that didn't use MBR
or GPT for the user partition.

> This is to complete the functionality with an equivalent implementation
> with providing partition table with bootargs, for case where the booargs
> can't be modified and tweaking the Device Tree is the only solution to
> have an usabe partition table.
> 
> The implementation follow the fixed-partitions parser used on MTD
> devices where a "partitions" node is expected to be declared with
> "fixed-partitions" compatible in the OF node of the disk device
> (mmc-card for eMMC for example) and each child node declare a label
> and a reg with offset and size. If label is not declared, the node name
> is used as fallback. Eventually is also possible to declare the read-only
> property to flag the partition as read-only.

barebox has for many years supported defining fixed partitions on SD/MMC
nodes and it's used heavily to define e.g. the location of the barebox
environment. Many who do so, do this either before the first partition
of the MBR/GPT or overlay the fixed partition to be identical to
an existing MBR/GPT partition.

barebox also by default copies all fixed partitions it is aware of
into the kernel DT, so if the kernel now stops parsing GPT/MBR when
a fixed partition node is defined, this would break compatibility of
existing barebox-booting systems with new kernels.

> +config OF_PARTITION
> +	bool "Device Tree partition support" if PARTITION_ADVANCED
> +	depends on OF
> +	help
> +	  Say Y here if you want to enable support for partition table
> +	  defined in Device Tree. (mainly for eMMC)
> +	  The format for the device tree node is just like MTD fixed-partition
> +	  schema.

Thanks for making this configurable and disabled by default, so users
won't experience breakage if they just do a make olddefconfig.

> diff --git a/block/partitions/core.c b/block/partitions/core.c
> index abad6c83db8f..dc21734b00ec 100644
> --- a/block/partitions/core.c
> +++ b/block/partitions/core.c
> @@ -43,6 +43,9 @@ static int (*const check_part[])(struct parsed_partitions *) = {
>  #ifdef CONFIG_CMDLINE_PARTITION
>  	cmdline_partition,
>  #endif
> +#ifdef CONFIG_OF_PARTITION
> +	of_partition,		/* cmdline have priority to OF */
> +#endif
>  #ifdef CONFIG_EFI_PARTITION
>  	efi_partition,		/* this must come before msdos */
>  #endif

If I understand correctly, it's possible to have both partitions-boot1 and
a GPT on the user area with your patch, right?

So this only leaves the matter of dealing with both fixed-partitions and
GPT for the same device node.

What are the thoughts on this? An easy way out would be to make of_partition
come later than efi_partition/mbr_partition, but I think it would be
nice if the kernel could consume partition info out of both of_partition
and efi_partition as long they don't collide.

Thanks,
Ahmad



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6] block: add support for partition table defined in OF)

[Christian Marangi (Ansuel)]

>
> Hi,
>
> sorry for not writing sooner. I only noticed this now.
>
> On 03.10.24 00:11, Christian Marangi wrote:
> > Add support for partition table defined in Device Tree. Similar to how
> > it's done with MTD, add support for defining a fixed partition table in
> > device tree.
> >
> > A common scenario for this is fixed block (eMMC) embedded devices that
> > have no MBR or GPT partition table to save storage space. Bootloader
> > access the block device with absolute address of data.
>
> How common are these? I never worked with a system that didn't use MBR
> or GPT for the user partition.
>

On router devices this is the approach for Mediatek and Airoha and also
other vendor for anything that have an eMMC.

Other device have a mixed nor/nand + eMMC but the eMMC
is used entirely for rootfs and not foor bootloader or other special partition.

> > This is to complete the functionality with an equivalent implementation
> > with providing partition table with bootargs, for case where the booargs
> > can't be modified and tweaking the Device Tree is the only solution to
> > have an usabe partition table.
> >
> > The implementation follow the fixed-partitions parser used on MTD
> > devices where a "partitions" node is expected to be declared with
> > "fixed-partitions" compatible in the OF node of the disk device
> > (mmc-card for eMMC for example) and each child node declare a label
> > and a reg with offset and size. If label is not declared, the node name
> > is used as fallback. Eventually is also possible to declare the read-only
> > property to flag the partition as read-only.
>
> barebox has for many years supported defining fixed partitions on SD/MMC
> nodes and it's used heavily to define e.g. the location of the barebox
> environment. Many who do so, do this either before the first partition
> of the MBR/GPT or overlay the fixed partition to be identical to
> an existing MBR/GPT partition.
>
> barebox also by default copies all fixed partitions it is aware of
> into the kernel DT, so if the kernel now stops parsing GPT/MBR when
> a fixed partition node is defined, this would break compatibility of
> existing barebox-booting systems with new kernels.
>

I'm not following... is that a downstream thing? Also fixed-partition
in DT for SD/MMC were never supported, why the partition was
copied in DT? Userspace tools made use of them?

> > +config OF_PARTITION
> > +     bool "Device Tree partition support" if PARTITION_ADVANCED
> > +     depends on OF
> > +     help
> > +       Say Y here if you want to enable support for partition table
> > +       defined in Device Tree. (mainly for eMMC)
> > +       The format for the device tree node is just like MTD fixed-partition
> > +       schema.
>
> Thanks for making this configurable and disabled by default, so users
> won't experience breakage if they just do a make olddefconfig.
>
> > diff --git a/block/partitions/core.c b/block/partitions/core.c
> > index abad6c83db8f..dc21734b00ec 100644
> > --- a/block/partitions/core.c
> > +++ b/block/partitions/core.c
> > @@ -43,6 +43,9 @@ static int (*const check_part[])(struct parsed_partitions *) = {
> >  #ifdef CONFIG_CMDLINE_PARTITION
> >       cmdline_partition,
> >  #endif
> > +#ifdef CONFIG_OF_PARTITION
> > +     of_partition,           /* cmdline have priority to OF */
> > +#endif
> >  #ifdef CONFIG_EFI_PARTITION
> >       efi_partition,          /* this must come before msdos */
> >  #endif
>
> If I understand correctly, it's possible to have both partitions-boot1 and
> a GPT on the user area with your patch, right?
>

No, this array works by, first is found WIN. If OF_PARTITION is enabled
and an OF partition is declared in DT, then efi partition parse is skipped.

> So this only leaves the matter of dealing with both fixed-partitions and
> GPT for the same device node.
>

The logic is applied to skip exactly this scenario. GPT partition can
be edited at
runtime and change, DT is more deterministic. It's one or the other.

If downstream someone have GPT then OF_PARTITION should not
be used at all... Eventually downstream for this special approach, an additional
downstream patch can be added that define a special property in the node to
disable OF parsing. (it's a 3 line patch and since everything is downstream it
really doesn't matter)

> What are the thoughts on this? An easy way out would be to make of_partition
> come later than efi_partition/mbr_partition, but I think it would be
> nice if the kernel could consume partition info out of both of_partition
> and efi_partition as long they don't collide.
>

The 2 thing would conflicts and would introduce so much complexity it might
be not worth at all. Also you would have situation where someone declare
OF partition in the space where the GPT partition table is located, adding
the possibility of corrupting it.

Again would love more explanation of your case because by the looks of it,
you use GPT for partition parsing and just overload the DT with the additional
info maybe for userspace usage. (and that case can be handled by just keeping
OF_PARTITION disabled or adding a little downstream patch)

Or you are telling me you had a downstream patch that declares additional
partition in addition to a disk with a GPT partition table?
If that's the case, I'm confused of why the additional partition can't
be declared
directly in GPT.

Re: Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6] block: add support for partition table defined in OF)

[Ahmad Fatoum]

Hello Christian,

Thanks for the prompt response.

On 05.12.24 12:54, Christian Marangi (Ansuel) wrote:
>> How common are these? I never worked with a system that didn't use MBR
>> or GPT for the user partition.
>>
> 
> On router devices this is the approach for Mediatek and Airoha and also
> other vendor for anything that have an eMMC.

Good to know. Thanks.

>> barebox has for many years supported defining fixed partitions on SD/MMC
>> nodes and it's used heavily to define e.g. the location of the barebox
>> environment. Many who do so, do this either before the first partition
>> of the MBR/GPT or overlay the fixed partition to be identical to
>> an existing MBR/GPT partition.
>>
>> barebox also by default copies all fixed partitions it is aware of
>> into the kernel DT, so if the kernel now stops parsing GPT/MBR when
>> a fixed partition node is defined, this would break compatibility of
>> existing barebox-booting systems with new kernels.
>>
> 
> I'm not following... is that a downstream thing? Also fixed-partition
> in DT for SD/MMC were never supported, why the partition was
> copied in DT? Userspace tools made use of them?

The kernel isn't modified, but the barebox-state utility can parse the
fixed partitions in the DT and map it via udev to a block device partition
(if one exists) or to a block device + offset.

>> If I understand correctly, it's possible to have both partitions-boot1 and
>> a GPT on the user area with your patch, right?
>>
> 
> No, this array works by, first is found WIN. If OF_PARTITION is enabled
> and an OF partition is declared in DT, then efi partition parse is skipped.

Yes, but Boot partitions and the user area are different block devices,
so it should be possible to use OF partition for the boot partitions
and GPT for the user area, right?

>> So this only leaves the matter of dealing with both fixed-partitions and
>> GPT for the same device node.
>>
> 
> The logic is applied to skip exactly this scenario. GPT partition can
> be edited at
> runtime and change, DT is more deterministic. It's one or the other.
> 
> If downstream someone have GPT then OF_PARTITION should not
> be used at all... Eventually downstream for this special approach, an additional
> downstream patch can be added that define a special property in the node to
> disable OF parsing. (it's a 3 line patch and since everything is downstream it
> really doesn't matter)

As mentioned, the kernel itself isn't patched, but there was an implicit
assumption that MBR/GPT parsing would continue to work, even when a fixed
partition node is specified...

>> What are the thoughts on this? An easy way out would be to make of_partition
>> come later than efi_partition/mbr_partition, but I think it would be
>> nice if the kernel could consume partition info out of both of_partition
>> and efi_partition as long they don't collide.
>>
> 
> The 2 thing would conflicts and would introduce so much complexity it might
> be not worth at all. Also you would have situation where someone declare
> OF partition in the space where the GPT partition table is located, adding
> the possibility of corrupting it.

If we go this way, the implementation should of course refuse creating partitions
that conflict. The barebox implementation allows partitions only in the
unpartitioned space or to be identical to an existing GPT partition.

But I agree, this needs to be thought through thoroughly to determine how
it should interact with  runtime repartitioning.

> Again would love more explanation of your case because by the looks of it,
> you use GPT for partition parsing and just overload the DT with the additional
> info maybe for userspace usage. (and that case can be handled by just keeping
> OF_PARTITION disabled or adding a little downstream patch)

Yes, keeping OF_PARTITION disabled would be required to not break barebox
users that made use of the non-upstream binding.

I wonder though, if something can be done to reconcile Linux and barebox'
view of this and allow in the future enabling both Linux OF_PARTITION
and barebox OF partition fixups.

> Or you are telling me you had a downstream patch that declares additional
> partition in addition to a disk with a GPT partition table?
> If that's the case, I'm confused of why the additional partition can't
> be declared
> directly in GPT.

Many of the older boards supported by barebox used to place the barebox image
and the environment prior to the first partition in the unpartitioned area.

To still be able to access them, fixed partitions were used and the rest
of the system was described by MBR/GPT partitions.

This was partially made necessary by BootROMs having strange expectations
of where the bootloader needs to be placed, which partially overlapped
the MBR/GPT itself, making it difficult to define a partition for the bootloader.

For newer boards, it's more common to place the bootloader in a GPT partition
now. barebox has no DT binding for generically describing such a GPT partition
though, so boards may create a fixed-partition "alias" and use that.

Cheers,
Ahmad 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6] block: add support for partition table defined in OF)

[Ahmad Fatoum]

Hi,

On 12/5/24 13:12, Ahmad Fatoum wrote:
>> Or you are telling me you had a downstream patch that declares additional
>> partition in addition to a disk with a GPT partition table?
>> If that's the case, I'm confused of why the additional partition can't
>> be declared
>> directly in GPT.
> 
> Many of the older boards supported by barebox used to place the barebox image
> and the environment prior to the first partition in the unpartitioned area.
> 
> To still be able to access them, fixed partitions were used and the rest
> of the system was described by MBR/GPT partitions.
> 
> This was partially made necessary by BootROMs having strange expectations
> of where the bootloader needs to be placed, which partially overlapped
> the MBR/GPT itself, making it difficult to define a partition for the bootloader.
> 
> For newer boards, it's more common to place the bootloader in a GPT partition
> now. barebox has no DT binding for generically describing such a GPT partition
> though, so boards may create a fixed-partition "alias" and use that.

FTR, starting with barebox v2025.03.0, barebox' default is to fix up a
partitions container with a barebox,fixed-partition compatible for
everything that's not an MTD. This avoids clashing with the binding
added here for MMCs and possibly a future binding for partitioning EEPROMs.

Cheers,
Ahmad

> 
> Cheers,
> Ahmad 
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |