Skip to contentSkip to conversation

dt-bindings: nvmem: allow MTD to be explicitly an NVMEM provider

PATCH In review Rafał Miłecki 2 participants 2 messages Mar 10, 2023

Subsystems (3)
Device tree bindings Memory technology devices (MTD) NVMEM framework
lore
Share & tools
lore

Rafał Miłecki

author
#0 lore raw

PATCH 1/1 dt-bindings: nvmem: allow MTD to be explicitly an NVMEM provider

From: Rafał Miłecki <[email protected]>

There are a lot of devices with NVMEM content stored in MTD devices in relevant partitions. Add a DT binding for marking such partitions.

Note: Linux already treats every MTD partition as NVMEM provider so in general it doesn't need to care about this binding. It's meant just to make DT clearer in describing hardware.

Signed-off-by Rafał Miłecki <[email protected]>

---
As explained in commit body this isn't really needed for Linux. I thought it'd be a small nice addition for writing clear DTS files.

---
 .../devicetree/bindings/nvmem/mtd.yaml        | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mtd.yaml
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +52 -0
new file mode 100644
index 000000000000..7435b2803cf9
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/mtd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTD access based NVMEM
+
+description: |
+  MTD partitions can be NVMEM providers. This binding allows explicitly marking
+  such partitions.
+
+  The exact way of handling MTD partition content (NVMEM cells) should be
+  described using a proper NVMEM layout.
+
+maintainers:
+  - Rafał Miłecki <[email protected]>
+
+allOf:
+  - $ref: nvmem.yaml#
+  - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+  compatible:
+    const: mtd-nvmem
+
+  reg:
+    maxItems: 1
+
+required:
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    partitions {
+        compatible = "fixed-partitions";
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        partition@0 {
+            compatible = "mtd-nvmem";
+            reg = <0x0 0x40000>;
+            label = "device-data";
+
+            nvmem-layout {
+                /* Just a dummy example: Kontron can be found on OTP actually */
+                compatible = "kontron,sl28-vpd";
+            };
+        };
+    };
Signature · 1 line
2.34.1
maintainer
#1 lore raw

Hi Rafał,

[email protected] wrote on Fri, 10 Mar 2023 11:53:30 +0100:

Quoted 25 lines

From: Rafał Miłecki <[email protected]>

There are a lot of devices with NVMEM content stored in MTD devices in relevant partitions. Add a DT binding for marking such partitions.

Note: Linux already treats every MTD partition as NVMEM provider so in general it doesn't need to care about this binding. It's meant just to make DT clearer in describing hardware.

Signed-off-by Rafał Miłecki <[email protected]>

---
As explained in commit body this isn't really needed for Linux. I thought it'd be a small nice addition for writing clear DTS files.

---
 .../devicetree/bindings/nvmem/mtd.yaml        | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mtd.yaml
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +1 -0
new file mode 100644
index 000000000000..7435b2803cf9
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

Documentation/devicetree/bindings/nvmem/mtd.yaml line 11

Quoted 10 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +10 -0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/mtd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTD access based NVMEM
+
+description: |
+  MTD partitions can be NVMEM providers. This binding allows explicitly marking
+  such partitions.

We already have that, it's nvmem-cell? I understand what you want to do, but I think it suffers from a common problem, see below.

Documentation/devicetree/bindings/nvmem/mtd.yaml line 14

Quoted 2 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +2 -0
+  The exact way of handling MTD partition content (NVMEM cells) should be
+  described using a proper NVMEM layout.

Ok so I believe this is another solution for the layout offset proposed by Michael. Except that it only fixes it for mtd. I think I would prefer the former solution which handles all nvmem cases.

Quoted 19 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +19 -0
+
+maintainers:
+  - Rafał Miłecki <[email protected]>
+
+allOf:
+  - $ref: nvmem.yaml#
+  - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+  compatible:
+    const: mtd-nvmem
+
+  reg:
+    maxItems: 1
+
+required:
+  - reg
+
+unevaluatedProperties: false

Documentation/devicetree/bindings/nvmem/mtd.yaml line 43

Quoted 10 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +10 -0
+
+examples:
+  - |
+    partitions {
+        compatible = "fixed-partitions";
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        partition@0 {
+            compatible = "mtd-nvmem";

Actually there has been valid push-back from devlink gurus against stale compatibles (on a device-driver point of view) like that. Maybe something like this instead:

	partition@x{
		<mtd-nvmem-property>

?

Documentation/devicetree/bindings/nvmem/mtd.yaml line 49

Quoted 6 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +6 -0
+            reg = <0x0 0x40000>;
+            label = "device-data";
+
+            nvmem-layout {
+                /* Just a dummy example: Kontron can be found on OTP actually */
+                compatible = "kontron,sl28-vpd";

The Onie tlv compatible would perfectly apply here.

Documentation/devicetree/bindings/nvmem/mtd.yaml line 52

Quoted 3 lines
Documentation/devicetree/bindings/nvmem/mtd.yaml new file +3 -0
+            };
+        };
+    };

Thanks,
Miquèl