nvmem: add block device NVMEM provider

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

new file mode 100644
index 0000000000000..df561dd33cbc9
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Partition on a block device
+
+description: |
+  This binding describes a partition on a block storage device.
+  Partitions may be matched by a combination of partition number, name,
+  and UUID.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  $nodename:
+    pattern: '^block-partition-.+$'

Hi Daniel,

Quoted 25 lines · Daniel Golle

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

new file mode 100644
index 0000000000000..df561dd33cbc9
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Partition on a block device
+
+description: |
+  This binding describes a partition on a block storage device.
+  Partitions may be matched by a combination of partition number, name,
+  and UUID.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  $nodename:
+    pattern: '^block-partition-.+$'

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

Quoted 10 lines

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

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

In the mtd world we originally had the partition nodes directly under the hardware device node as well. That was changed to put a partitions subnode between the hardware device node and the partitions.

From fe2585e9c29a ("doc: dt: mtd: support partitions in a special 'partitions' subnode"):

To avoid conflict with other drivers using subnodes of the mtd device create only one ofpart-specific node rather than any number of arbitrary partition subnodes.

Does it make sense to do the same for block devices?

Add bindings for block devices which are used to allow referencing nvmem bits on them.

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

---
 .../bindings/block/block-device.yaml          | 22 ++++++++
 .../devicetree/bindings/block/partition.yaml  | 51 +++++++++++++++++++
 .../devicetree/bindings/block/partitions.yaml | 20 ++++++++
 3 files changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/block/block-device.yaml
 create mode 100644 Documentation/devicetree/bindings/block/partition.yaml
 create mode 100644 Documentation/devicetree/bindings/block/partitions.yaml

Documentation/devicetree/bindings/block/block-device.yaml new file +22 -0

new file mode 100644
index 0000000000000..c83ea525650ba
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/block-device.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: block storage device
+
+description: |
+  This binding is generic and describes a block-oriented storage device.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  partitions:
+    $ref: /schemas/block/partitions.yaml
+
+  nvmem-layout:
+    $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+unevaluatedProperties: false

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

new file mode 100644
index 0000000000000..df561dd33cbc9
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Partition on a block device
+
+description: |
+  This binding describes a partition on a block storage device.
+  Partitions may be matched by a combination of partition number, name,
+  and UUID.
+
+maintainers:
+  - Daniel Golle <[email protected]>
+
+properties:
+  $nodename:
+    pattern: '^block-partition-.+$'

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

+
+  nvmem-layout:
+    $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+    description:
+      This container may reference an NVMEM layout parser.
+
+anyOf:
+  - required:
+      - partnum
+
+  - required:
+      - partname
+
+  - required:
+      - uuid
+
+unevaluatedProperties: false

-----Original Message-----
From: Rob Herring <[email protected]>
Sent: Thursday, March 7, 2024 6:51 AM
To: Daniel Golle <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>; Conor Dooley <[email protected]>; Ulf Hansson <[email protected]>; Jens Axboe <[email protected]>; Dave Chinner <[email protected]>; Jan Kara <[email protected]>; Thomas Weißschuh <[email protected]>; Christian Brauner <[email protected]>; Li Lingfeng <[email protected]>; Damien Le Moal <[email protected]>; Min Li <[email protected]>; Adrian Hunter <[email protected]>; Hannes Reinecke <[email protected]>; Christian Loehle <[email protected]>; Avri Altman <[email protected]>; Bean Huo <[email protected]>; Yeqi Fu <[email protected]>; Victor Shih <[email protected]>; Christophe JAILLET <[email protected]>; Ricardo B. Marliere <[email protected]>; Greg Kroah-Hartman <[email protected]>; [email protected]; [email protected]; [email protected]; linux- [email protected]; Diping Zhang <[email protected]>; Jianhui Zhao <[email protected]>; Jieying Zeng <[email protected]>; Chad Monroe <[email protected]>; Adam Fox <[email protected]>; John Crispin <[email protected]>
Subject: [EXTERNAL] Re: [RFC PATCH v2 1/8] dt-bindings: block: add basic bindings for block devices

Quoted 10 lines · Daniel Golle

Add bindings for block devices which are used to allow referencing nvmem bits on them.

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

---
.../bindings/block/block-device.yaml | 22 ++++++++ .../devicetree/bindings/block/partition.yaml | 51 +++++++++++++++++++ .../devicetree/bindings/block/partitions.yaml | 20 ++++++++

3 files changed, 93 insertions(+)

create mode 100644 Documentation/devicetree/bindings/block/block-

device.yaml

Review

Quoted 4 lines

create mode 100644 Documentation/devicetree/bindings/block/partition.yaml create mode 100644 Documentation/devicetree/bindings/block/partitions.yaml

(quoted diff) +0 -0

b/Documentation/devicetree/bindings/block/block-device.yaml

Documentation/devicetree/bindings/block/block-device.yaml line 4

Quoted 9 lines

new file mode 100644
index 0000000000000..c83ea525650ba

Documentation/devicetree/bindings/block/block-device.yaml new file +4 -0

@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/block-device.yaml# <https://protect-

de.mimecast.com/s/gI6FCDqGk9uBM0gMFZVG39?domain=devicetree.org>

Documentation/devicetree/bindings/block/block-device.yaml line 5

Quoted 1 line

Documentation/devicetree/bindings/block/block-device.yaml new file +1 -0

+$schema: http://devicetree.org/meta-schemas/core.yaml# <https://protect-

de.mimecast.com/s/rGEGCEqJR9uWnMRnHZK6FQ?domain=devicetree.org>

Review

Quoted 18 lines

Documentation/devicetree/bindings/block/block-device.yaml new file +17 -0

+
+title: block storage device
+
+description: |
+ This binding is generic and describes a block-oriented storage device.
+
+maintainers:
+ - Daniel Golle <[email protected]>
+
+properties:
+ partitions:
+ $ref: /schemas/block/partitions.yaml
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+unevaluatedProperties: false

(quoted diff) +0 -0

b/Documentation/devicetree/bindings/block/partition.yaml

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

Quoted 9 lines

new file mode 100644
index 0000000000000..df561dd33cbc9

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

@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/block/partition.yaml# <https://protect-

de.mimecast.com/s/8Tf9CGRL65UJqGjqu07YGR?domain=devicetree.org>

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

Quoted 1 line

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

+$schema: http://devicetree.org/meta-schemas/core.yaml# <https://protect-

de.mimecast.com/s/rGEGCEqJR9uWnMRnHZK6FQ?domain=devicetree.org>

Quoted 14 lines

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

+
+title: Partition on a block device
+
+description: |
+ This binding describes a partition on a block storage device.
+ Partitions may be matched by a combination of partition number, name,
+ and UUID.
+
+maintainers:
+ - Daniel Golle <[email protected]>
+
+properties:
+ $nodename:
+ pattern: '^block-partition-.+$'

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

Quoted 10 lines

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

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

Why do we need something new here? The existing fixed-partitions can already define block device partitions. It just matches by address/offset which works whether its MBR or GPT. Also, in DT we always have an address when there is an address.

I'm sure you want to statically define this and have it work even if the partitions move, but sorry...

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

Quoted 6 lines

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

+
+ uuid:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Matches partition by PARTUUID if present.

If this remains it will need some work in the dtschema tools. The reason is json-schema already has support for UUIDs as a defined 'format' key value and we should use that.

Quoted 17 lines

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

+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+ description:
+ This container may reference an NVMEM layout parser.
+
+anyOf:
+ - required:
+ - partnum
+
+ - required:
+ - partname
+
+ - required:
+ - uuid
+
+unevaluatedProperties: false

static int __init blk_nvmem_init(void)

{
	int ret;
 
	ret = class_interface_register(&blk_nvmem_bus_interface);
	if (ret)
		return ret;
 
	return 0;

Set fwnode in case it isn't set yet and of_node is present.

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

---
 drivers/mmc/core/bus.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/mmc/core/bus.c index renamed from drivers/mmc/core/bus.c +0 -0

0ddaee0eae54f..e1c5fc1b3ce4b 100644

drivers/mmc/core/bus.c +0 -1

        device_enable_async_suspend(&card->dev);
 
--

2.44.0

Quoted 14 lines

Set fwnode in case it isn't set yet and of_node is present.

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

---
 drivers/mmc/core/bus.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/mmc/core/bus.c index renamed from drivers/mmc/core/bus.c +0 -0

0ddaee0eae54f..e1c5fc1b3ce4b 100644

drivers/mmc/core/bus.c +0 -0

@@ -364,6 +364,8 @@ int mmc_add_card(struct mmc_card *card)
 

drivers/mmc/core/bus.c int mmc_add_card(struct mmc_card *card) · line 368

Quoted 4 lines

drivers/mmc/core/bus.c +2 -0

        mmc_add_card_debugfs(card);
        card->dev.of_node = mmc_of_find_child_device(card->host, 0);
+       if (card->dev.of_node && !card->dev.fwnode)
+               card->dev.fwnode = &card->dev.of_node->fwnode;

Should this be restricted to eMMC only, or is it fine to be called for SD as well?

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 block devices 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.

This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices...

And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere.

Quoted 34 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 block devices 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.

This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices...

Quoted 4 lines

And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere.

I don't object to the above, however to keep things scalable at the block device driver level, such as the MMC subsystem, I think we should avoid having *any* knowledge about the binary format at these kinds of lower levels.

Even if most of the NVMEM format is managed elsewhere, the support for NVMEM partitions seems to be dealt with from the MMC subsystem too.

Why can't NVMEM partitions be managed the usual way via the MBR/GPT?

Hi Ulf,

Quoted 40 lines · Ulf Hansson

Quoted 34 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 block devices 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.

This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices...

Quoted 4 lines

And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere.

Quoted 7 lines

I don't object to the above, however to keep things scalable at the block device driver level, such as the MMC subsystem, I think we should avoid having *any* knowledge about the binary format at these kinds of lower levels.

Even if most of the NVMEM format is managed elsewhere, the support for NVMEM partitions seems to be dealt with from the MMC subsystem too.

In an earlier iteration of this RFC it was requested to make NVMEM support opt-in (instead of opt-out for mtdblock and ubiblock, which already got their own NVMEM provider implementation).
Hence at least a change to opt-in for NVMEM support is required in the MMC subsystem, together with making sure that MMC devices have their fwnode assigned.

Quoted 2 lines

Why can't NVMEM partitions be managed the usual way via the MBR/GPT?

Absolutely, maybe my wording was not clear, but that's exactly what I'm suggesting here. There are no added parsers nor any knowledge about binary formats in this patchset.

Or did I misunderstand your comment?

Quoted 52 lines · Daniel Golle

Hi Ulf,

Quoted 40 lines · Ulf Hansson

Quoted 34 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 block devices 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.

This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices...

Quoted 4 lines

And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere.

Quoted 7 lines

I don't object to the above, however to keep things scalable at the block device driver level, such as the MMC subsystem, I think we should avoid having *any* knowledge about the binary format at these kinds of lower levels.

Even if most of the NVMEM format is managed elsewhere, the support for NVMEM partitions seems to be dealt with from the MMC subsystem too.

Quoted 6 lines

In an earlier iteration of this RFC it was requested to make NVMEM support opt-in (instead of opt-out for mtdblock and ubiblock, which already got their own NVMEM provider implementation).
Hence at least a change to opt-in for NVMEM support is required in the MMC subsystem, together with making sure that MMC devices have their fwnode assigned.

So, the NVMEM support needs to be turned on (opt-in) for each and every block device driver?

It's not a big deal for me - and I would be happy to apply such a change. On the other hand, it is just some binary data that is stored on the flash, why should MMC have to opt-in or opt-out at all? It should be the upper layers who decide what to store on the flash, not the MMC subsystem, if you get my point.

Quoted 6 lines

Quoted 2 lines

Why can't NVMEM partitions be managed the usual way via the MBR/GPT?

Absolutely, maybe my wording was not clear, but that's exactly what I'm suggesting here. There are no added parsers nor any knowledge about binary formats in this patchset.

Right, but there are new DT bindings added in the $subject series that allows us to describe NVMEM partitions for an eMMC. Why isn't that parsed from the MBR/GPT, etc, rather than encoded in DT?

Quoted 3 lines

Or did I misunderstand your comment?

Maybe. I am just trying to understand this, so apologize if you find my questions silly. :-)

Quoted 60 lines · Ulf Hansson

Quoted 52 lines · Daniel Golle

Hi Ulf,

Quoted 40 lines · Ulf Hansson

Quoted 34 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 block devices 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.

This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices...

Quoted 4 lines

And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere.

Quoted 7 lines

I don't object to the above, however to keep things scalable at the block device driver level, such as the MMC subsystem, I think we should avoid having *any* knowledge about the binary format at these kinds of lower levels.

Even if most of the NVMEM format is managed elsewhere, the support for NVMEM partitions seems to be dealt with from the MMC subsystem too.

Quoted 6 lines

In an earlier iteration of this RFC it was requested to make NVMEM support opt-in (instead of opt-out for mtdblock and ubiblock, which already got their own NVMEM provider implementation).
Hence at least a change to opt-in for NVMEM support is required in the MMC subsystem, together with making sure that MMC devices have their fwnode assigned.

Quoted 9 lines

So, the NVMEM support needs to be turned on (opt-in) for each and every block device driver?

It's not a big deal for me - and I would be happy to apply such a change. On the other hand, it is just some binary data that is stored on the flash, why should MMC have to opt-in or opt-out at all? It should be the upper layers who decide what to store on the flash, not the MMC subsystem, if you get my point.

I agree, and that's exactly how I originally wrote it. However, in the first round of rewiew it was requested to be in that way (ie. opt-in for each subsystem; rather than opt-out for subsystems already providing NVMEM in another way, such as MTD or UBI), see here:

https://patchwork.kernel.org/comment/25432948/

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

Why can't NVMEM partitions be managed the usual way via the MBR/GPT?

Absolutely, maybe my wording was not clear, but that's exactly what I'm suggesting here. There are no added parsers nor any knowledge about binary formats in this patchset.

Quoted 3 lines

Right, but there are new DT bindings added in the $subject series that allows us to describe NVMEM partitions for an eMMC. Why isn't that parsed from the MBR/GPT, etc, rather than encoded in DT?

The added dt-bindings merely allow to **identify** the partition by it's PARTNAME, PARTNO or PARTUUID, so we can reference them in DT. We'd still rely on MBR or GPT to do the actual parsing of the on-disk format.