block: implement NVMEM provider

+$id: http://devicetree.org/schemas/block/partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/block/partition.yaml new file +24 -0

+
+title: Partition on a block device
+
+description: |
+  This binding describes a partition on a block device.
+  Partitions may be matched by a combination of partition number, name,
+  and UUID.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  $nodename:
+    pattern: '^block-partition-.+$'
+
+  partnum:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Matches partition by number if present.
+
+  partname:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      Matches partition by PARTNAME if present.

Quoted 31 lines · Daniel Golle

+$id: http://devicetree.org/schemas/block/partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#

Documentation/devicetree/bindings/block/partition.yaml new file +29 -0

+
+title: Partition on a block device
+
+description: |
+  This binding describes a partition on a block device.
+  Partitions may be matched by a combination of partition number, name,
+  and UUID.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  $nodename:
+    pattern: '^block-partition-.+$'
+
+  partnum:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Matches partition by number if present.
+
+  partname:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      Matches partition by PARTNAME if present.
+
+  partuuid:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      Matches partition by PARTUUID if present.

Documentation/devicetree/bindings/block/partition.yaml line 39

Quoted 5 lines

Documentation/devicetree/bindings/block/partition.yaml new file +5 -0

+
+  nvmem-layout:
+    $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+    description:
+      This container may reference an NVMEM layout parser.

Does the above imply that only systems with a single block device are supported?

Supporting partition numbers seems unfortunate to me. Partition numbers will change if the partition scheme changes.

Add new flag to destinguish block devices which may act as an NVMEM provider.

Signed-off-by Daniel Golle <[email protected]>

---
  include/linux/blkdev.h | 2 ++
  1 file changed, 2 insertions(+)

include/linux/blkdev.h +0 -0

index c3e8f7cf96be9..f2c4f280d7619 100644
@@ -81,11 +81,13 @@ struct partition_meta_info {
   * ``GENHD_FL_NO_PART``: partition support is disabled.  The kernel will not

Quoted 18 lines · Daniel Golle

Add new flag to destinguish block devices which may act as an NVMEM provider.

Signed-off-by Daniel Golle <[email protected]>

---
  include/linux/blkdev.h | 2 ++
  1 file changed, 2 insertions(+)

include/linux/blkdev.h +1 -0

index c3e8f7cf96be9..f2c4f280d7619 100644
@@ -81,11 +81,13 @@ struct partition_meta_info {
   * ``GENHD_FL_NO_PART``: partition support is disabled.  The kernel will not
   * scan for partitions from add_disk, and users can't add partitions manually.
   *
+ * ``GENHD_FL_NVMEM``: the block device should be considered as NVMEM provider.
   */

include/linux/blkdev.h struct partition_meta_info { · line 91

Quoted 6 lines

include/linux/blkdev.h +1 -0

  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?

Quoted 9 lines · Bart Van Assche

include/linux/blkdev.h struct partition_meta_info { · line 91

Quoted 6 lines · Daniel Golle

   enum {
   	GENHD_FL_REMOVABLE			= 1 << 0,
   	GENHD_FL_HIDDEN				= 1 << 1,
   	GENHD_FL_NO_PART			= 1 << 2,

include/linux/blkdev.h +1 -0

+	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.

Quoted 11 lines · Daniel Golle

Quoted 9 lines · Bart Van Assche

include/linux/blkdev.h struct partition_meta_info { · line 91

Quoted 6 lines · Daniel Golle

   enum {
   	GENHD_FL_REMOVABLE			= 1 << 0,
   	GENHD_FL_HIDDEN				= 1 << 1,
   	GENHD_FL_NO_PART			= 1 << 2,

include/linux/blkdev.h +1 -0

+	GENHD_FL_NVMEM				= 1 << 3,
   };

What would break if this flag wouldn't exist?

Quoted 5 lines

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?

On embedded devices using an eMMC it is common that one or more partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data. Allow referencing the partition in device tree for the kernel and Wi-Fi drivers accessing it via the NVMEM layer.

Quoted 4 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data. Allow referencing the partition in device tree for the kernel and Wi-Fi drivers accessing it via the NVMEM layer.

Why to store calibration data in a partition instead of in a file on a filesystem?

MAINTAINERS L: [email protected] · line 3667

Quoted 12 lines

MAINTAINERS +4 -0

index 8c88f362feb55..242a0a139c00a 100644
@@ -3662,6 +3662,11 @@ L:	[email protected]
  S:	Maintained
  F:	drivers/mtd/devices/block2mtd.c
+BLOCK NVMEM DRIVER
+M:	Daniel Golle <[email protected]>
+S:	Maintained
+F:	block/blk-nvmem.c

Why to add this functionality to the block layer instead of somewhere in the drivers/ directory?

Quoted 2 lines · Bart Van Assche

Why to add this functionality to the block layer instead of somewhere in the drivers/ directory?

Simply because we need notifications about appearing and disappearing block devices, or a way to iterate over all block devices in a system. For both there isn't currently any other interface than using a class_interface for that, and that requires access to &block_class which is considered a block subsystem internal.

Quoted 9 lines · Daniel Golle

Quoted 2 lines · Bart Van Assche

Why to add this functionality to the block layer instead of somewhere in the drivers/ directory?

Simply because we need notifications about appearing and disappearing block devices, or a way to iterate over all block devices in a system. For both there isn't currently any other interface than using a class_interface for that, and that requires access to &block_class which is considered a block subsystem internal.

That's an argument for adding an interface to the block layer that implements this functionality but not for adding this code in the block layer.

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 14 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

Quoted 3 lines

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Since this patch series adds code that opens partitions and reads from partitions, can that part of the functionality be implemented in user space? There is already a mechanism for notifying user space about block device changes, namely udev.

Quoted 15 lines · Bart Van Assche

Quoted 14 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

Quoted 8 lines

Quoted 3 lines

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Since this patch series adds code that opens partitions and reads from partitions, can that part of the functionality be implemented in user space? There is already a mechanism for notifying user space about block device changes, namely udev.

No. Because it has to happen (e.g. for nfsroot to work) before userland gets initiated: Without Ethernet MAC address (which if often stored at some raw offset on a partition or hw-partition of an eMMC), we don't have a way to use nfsroot (because that requires functional Ethernet), hence userland won't come up. It's a circular dependency problem which can only be addressed by making sure that everything needed for Ethernet to come up is provided by the kernel **before** rootfs (which can be nfsroot) is mounted.

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Quoted 18 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 6 lines

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

I don't recall giving positive feedback.

I still think this should use offsets rather than partition specific information. Not wanting to have to update the offsets if they change is not reason enough to not use them.

Quoted 26 lines · Rob Herring

Quoted 18 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 6 lines

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Quoted 5 lines

I don't recall giving positive feedback.

I still think this should use offsets rather than partition specific information. Not wanting to have to update the offsets if they change is not reason enough to not use them.

Using raw offsets on the block device (rather than the partition) won't work for most existing devices and boot firmware out there. They always reference the partition, usually by the name of a GPT partition (but sometimes also PARTUUID or even PARTNO) which is then used in the exact same way as an MTD partition or UBI volume would be on devices with NOR or NAND flash.

Just on eMMC we usually use a GPT
or MBR partition table rather than defining partitions in DT or cmdline, which is rather rare (for historic reasons, I suppose, but it is what it is now).

Depending on the eMMC chip used, that partition may not even be at the same offset for different batches of the same device and hence I'd like to just do it in the same way vendor firmware does it as well.

Chad of Adtran has previously confirmed that [1], which was the positive feedback I was refering to. Other vendors like GL-iNet or Netgear are doing the exact same thing.

As of now, we support this in OpenWrt by adding a lot of board-specific knowledge to userland, which is ugly and also prevents using things like PXE-initiated nfsroot on those devices.

The purpose of this series is to be able to properly support such devices (ie. practially all consumer-grade routers out there using an eMMC for storing firmware).

Also, those devices have enough resources to run a general purpose distribution like Debian instead of OpenWrt, and all the userland hacks to set MAC addresses and extract WiFi-EEPROM-data in a board-specific ways will most certainly never find their way into Debian. It's just not how embedded Linux works, unless you are looking only at the RaspberryPi which got that data stored in a textfile which is shipped by the distribution -- something very weird and very different from literally all of-the-shelf routers, access-points or switches I have ever seen (and I've seen many). Maybe Felix who has seen even more of them can tell us more about that.

+boot-architecture list

Quoted 33 lines · Rob Herring

Quoted 26 lines · Daniel Golle

Quoted 18 lines

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 6 lines

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Quoted 5 lines

I don't recall giving positive feedback.

I still think this should use offsets rather than partition specific information. Not wanting to have to update the offsets if they change is not reason enough to not use them.

Quoted 6 lines

Using raw offsets on the block device (rather than the partition) won't work for most existing devices and boot firmware out there. They always reference the partition, usually by the name of a GPT partition (but sometimes also PARTUUID or even PARTNO) which is then used in the exact same way as an MTD partition or UBI volume would be on devices with NOR or NAND flash.

MTD normally uses offsets hence why I'd like some alignment. UBI is special because raw NAND is, well, special.

Quoted 5 lines

Just on eMMC we usually use a GPT
or MBR partition table rather than defining partitions in DT or cmdline, which is rather rare (for historic reasons, I suppose, but it is what it is now).

Yes, I understand how eMMC works. I don't understand why if you have part #, uuid, or name you can't get to the offset or vice-versa. You need only 1 piece of identification to map partition table entries to DT nodes.

Sure, offsets can change, but surely the firmware can handle adjusting the DT?

An offset would also work for the case of random firmware data on the disk that may or may not have a partition associated with it. There are certainly cases of that. I don't think we have much of a solution for that other than trying to educate vendors to not do that or OS installers only supporting installing to something other than eMMC. This is something EBBR[1] is trying to address.

Quoted 4 lines

Depending on the eMMC chip used, that partition may not even be at the same offset for different batches of the same device and hence I'd like to just do it in the same way vendor firmware does it as well.

Often vendor firmware is not a model to follow...

Quoted 13 lines

Chad of Adtran has previously confirmed that [1], which was the positive feedback I was refering to. Other vendors like GL-iNet or Netgear are doing the exact same thing.

As of now, we support this in OpenWrt by adding a lot of board-specific knowledge to userland, which is ugly and also prevents using things like PXE-initiated nfsroot on those devices.

The purpose of this series is to be able to properly support such devices (ie. practially all consumer-grade routers out there using an eMMC for storing firmware).

Quoted 10 lines

Also, those devices have enough resources to run a general purpose distribution like Debian instead of OpenWrt, and all the userland hacks to set MAC addresses and extract WiFi-EEPROM-data in a board-specific ways will most certainly never find their way into Debian. It's just not how embedded Linux works, unless you are looking only at the RaspberryPi which got that data stored in a textfile which is shipped by the distribution -- something very weird and very different from literally all of-the-shelf routers, access-points or switches I have ever seen (and I've seen many). Maybe Felix who has seen even more of them can tell us more about that.

General purpose distros want to partition the disk themselves. Adding anything to the DT for disk partitions would require the installer to be aware of it. There's various distro folks on the boot-arch list, so maybe one of them can comment.

Rob

[1] https://arm-software.github.io/ebbr/index.html#document-chapter4-firmware-media

Hi Rob,

Quoted 1 line · Rob Herring

+boot-architecture list

Good idea, thank you :)

Quoted 42 lines · Daniel Golle

Quoted 33 lines · Rob Herring

Quoted 26 lines · Daniel Golle

Quoted 18 lines

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 6 lines

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Quoted 5 lines

I don't recall giving positive feedback.

I still think this should use offsets rather than partition specific information. Not wanting to have to update the offsets if they change is not reason enough to not use them.

Quoted 6 lines

Using raw offsets on the block device (rather than the partition) won't work for most existing devices and boot firmware out there. They always reference the partition, usually by the name of a GPT partition (but sometimes also PARTUUID or even PARTNO) which is then used in the exact same way as an MTD partition or UBI volume would be on devices with NOR or NAND flash.

Quoted 2 lines

MTD normally uses offsets hence why I'd like some alignment. UBI is special because raw NAND is, well, special.

I get the point and in a way this is also already intended and supported by this series. You can already just add an 'nvmem-layout' node directly to a disk device rather than to a partition and define a layout in this way.

Making this useful in practice will require some improvements to the nvmem system in Linux though, because that currently uses signed 32-bit integers as addresses which is not sufficient for the size of the user-part of an eMMC. However, that needs to be done then and should of course not be read as an excuse.

Quoted 10 lines

Quoted 5 lines

Just on eMMC we usually use a GPT
or MBR partition table rather than defining partitions in DT or cmdline, which is rather rare (for historic reasons, I suppose, but it is what it is now).

Yes, I understand how eMMC works. I don't understand why if you have part #, uuid, or name you can't get to the offset or vice-versa. You need only 1 piece of identification to map partition table entries to DT nodes.

Yes, either of them (or a combination) is fine. In practise I've mostly seen PARTNAME as identifier used in userland scripts, and only adding this for now will probably cover most devices (and existing boot firmware) out there. Notable exceptions are devices which are using MBR partitions because the BootROM expects the bootloader to be at the same block as we would usually have the primary GPT. In this case we can only use the PARTNO, of course, and it stinks.
MediaTek's MT7623A/N is such an example, but it's a slingly outdated and pretty weird niche SoC I admit.

Quoted 2 lines

Sure, offsets can change, but surely the firmware can handle adjusting the DT?

Future firmware may be able to do this, of course. Current existing firmware already out there on devices such as the quite popular GL.iNet MT-6000, Netgear's Orbi and Orbi Pro series as well as all Adtran SmartRG devices does not. Updating or changing the boot firmware of devices already out there is not intended and quite challenging, and will make the device incompatible with its vendor firmware. Hence it would be better to support replacing only the Linux-based firmware (eg. with OpenWrt or even Debian or any general-purpose Linux, the eMMC is large enough...) while not having to touch the boot firmware (and risking to brick the device if that goes wrong).

Personally, I'm rather burdened and unhappy with vendor attempts to have the boot firmware mess around too much in (highly customized, downstream) DT, it may look like a good solution at the moment, but can totally become an obstacle in an unpredictable future (no offense ASUS...)

Quoted 7 lines

An offset would also work for the case of random firmware data on the disk that may or may not have a partition associated with it. There are certainly cases of that. I don't think we have much of a solution for that other than trying to educate vendors to not do that or OS installers only supporting installing to something other than eMMC. This is something EBBR[1] is trying to address.

Absolutely. Actually *early* GL-iNet devices did exactly that: Use the eMMC boot hw-partitions to store boot firmware as well as MAC addresses and potentially also Wi-Fi calibration data.

The MT-2500 is the example I'm aware of and got sitting on my desk for testing with this very series (which allows to also reference eMMC hardware partitions, see "[7/8] mmc: block: set fwnode of disk devices").
Unfortunately later devices such the the flag-ship MT-6000 moved MAC addresses and WiFi-EEPROMs into a GPT partition on the user-part of the eMMC.

Quoted 6 lines

Quoted 4 lines

Depending on the eMMC chip used, that partition may not even be at the same offset for different batches of the same device and hence I'd like to just do it in the same way vendor firmware does it as well.

Often vendor firmware is not a model to follow...

I totally agree. However, I don't see a good reason for not supporting those network-appliance-type embedded devices which even ship with (outdated, downstream) Linux by default while going through great lengths for things like broken ACPI tables in many laptops which require lots of work-arounds to have features like suspend-to-disk working, or even be able to run Linux at all.

Quoted 24 lines

Quoted 13 lines

Chad of Adtran has previously confirmed that [1], which was the positive feedback I was refering to. Other vendors like GL-iNet or Netgear are doing the exact same thing.

As of now, we support this in OpenWrt by adding a lot of board-specific knowledge to userland, which is ugly and also prevents using things like PXE-initiated nfsroot on those devices.

The purpose of this series is to be able to properly support such devices (ie. practially all consumer-grade routers out there using an eMMC for storing firmware).

Quoted 10 lines

Also, those devices have enough resources to run a general purpose distribution like Debian instead of OpenWrt, and all the userland hacks to set MAC addresses and extract WiFi-EEPROM-data in a board-specific ways will most certainly never find their way into Debian. It's just not how embedded Linux works, unless you are looking only at the RaspberryPi which got that data stored in a textfile which is shipped by the distribution -- something very weird and very different from literally all of-the-shelf routers, access-points or switches I have ever seen (and I've seen many). Maybe Felix who has seen even more of them can tell us more about that.

Quoted 4 lines

General purpose distros want to partition the disk themselves. Adding anything to the DT for disk partitions would require the installer to be aware of it. There's various distro folks on the boot-arch list, so maybe one of them can comment.

Usually the installers are already aware to not touch partitions when unaware of their purpose. Repartitioning the disk from scratch is not what (modern) distributions are doing, at least the EFI System partition is kept, as well as typical rescue/recovery partitions many vendors put on their (Windows, Mac) laptops to allow to "factory reset" them.

Installers usually offer to replace (or resize) the "large" partition used by the currently installed OS instead.

And well, the DT reference to a partition holding e.g. MAC addresses does make the installer aware of it, obviously.

Thank you for the constructive debate!

Cheers

Daniel

Quoted 4 lines

Rob

[1] https://arm-software.github.io/ebbr/index.html#document-chapter4-firmware-media

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Quoted 18 lines · Daniel Golle

On embedded devices using an eMMC it is common that one or more (hw/sw) partitions on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM data.

Implement an NVMEM provider backed by a block device as typically the NVMEM framework is used to have kernel drivers read and use binary data from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code to bind each hardware partition to a specific firmware subnode.

Overall, this enables uniform handling across practially all flash storage types used for this purpose (MTD, UBI, and now also MMC).

As part of this series it was necessary to define a device tree schema for block devices and partitions on them, which (similar to how it now works also for UBI volumes) can be matched by one or more properties.

Quoted 6 lines

---
This series has previously been submitted as RFC on July 19th 2023[1] and most of the basic idea did not change since. Another round of RFC was submitted on March 5th 2024[2] which has received overall positive feedback and only minor corrections have been done since (see changelog below).

Also, please version your patches. 'RFC' is a tag, not a version. v1 was July. v2 was March 5th. This is v3.