[PATCH v3 0/6] Bindings for NVMEM layouts

[PATCH v3 0/6] Bindings for NVMEM layouts

[Miquel Raynal]

Hello,

A month ago, Michael was sending a new iteration of his series bringing
nvmem layout support. The idea is: we currently can produce nvmem cells
statically defined on top of nvmem devices (which themselves may be MTD
devices sometimes) but in some cases we may need more advanced parsing,
which is possible thanks to the introduction of nvmem layout parsers.

I am not taking over the entire series but I recently tried to make use
of these layouts for the ONIE tlv table layout and Rob (rightfully)
pointed out that the description was messy, because of the mix between
nvmem devices and nvmem parsers. This was known to Michael which
initially argued that it was simpler to handle like that.

So here is a new proposal for the bindings which is described in details
within "dt-bindings: nvmem: Introduce the nvmem-layout container". The
idea to avoid mixing different node contents is to use a container node
when relevant (suggested by Rob) which I named nvmem-layout. This
container will have a compatible that describes the parser (plus
possible additional properties).

Michael, I have a few fixup! patches which apply directly to your former
series in order to support this additional container. I propose we first
settle the bindings (including the two direct use cases as examples) and
once merged, we can move forward and respin both the nvmem series + the
layout drivers.

# Original series (v2) from Michael
Link: https://lore.kernel.org/linux-arm-kernel/20220921115813.208ff789@xps-13/T/#mb97d5376647ff3e686b9c55e3d5e0dc80879e84a

Cheers, Miquèl

Michael Walle (1):
  dt-bindings: nvmem: add YAML schema for the sl28 vpd layout

Miquel Raynal (5):
  dt-bindings: nvmem: Fix example
  dt-bindings: nvmem: Introduce the nvmem-layout container
  dt-bindings: eeprom: Inherit from nvmem.yaml
  dt-bindings: vendor-prefixes: Add ONIE
  dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

 .../devicetree/bindings/eeprom/at24.yaml      |   5 +-
 .../devicetree/bindings/eeprom/at25.yaml      |   1 +
 .../bindings/eeprom/microchip,93lc46b.yaml    |   1 +
 .../nvmem/layouts/kontron,sl28-vpd.yaml       |  60 +++++++++
 .../bindings/nvmem/layouts/nvmem-layout.yaml  |  34 ++++++
 .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
 .../devicetree/bindings/nvmem/nvmem.yaml      |   8 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 8 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml

-- 
2.34.1

[PATCH v3 1/6] dt-bindings: nvmem: Fix example

[Miquel Raynal]

Despite not being listed nor required within the top level nvmem yaml
file, the "compatible" property is mandatory and is actually enforced by
all the nvmem provider bindings.

Unfortunately, the lack of compatible in the nvmem.yaml to level
description file lead to the example not matching anything and thus not
being checked at all.

Let's pick a compatible almost randomly (one which is already used with
the qfprom label) to make the example at least valid on a semantic
point of view and getting it checked.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 Documentation/devicetree/bindings/nvmem/nvmem.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 1eb22dba364c..0455506fc30f 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -67,6 +67,7 @@ examples:
       #include <dt-bindings/gpio/gpio.h>
 
       qfprom: eeprom@700000 {
+          compatible = "qcom,msm8974-qfprom", "qcom,qfprom";
           #address-cells = <1>;
           #size-cells = <1>;
           reg = <0x00700000 0x100000>;
-- 
2.34.1

[PATCH v3 2/6] dt-bindings: nvmem: Introduce the nvmem-layout container

[Miquel Raynal]

The nvmem devices description works like this:

* Most cases (EEPROM & co):

eeprom@x {
	 compatible = "<eeprom-compatible>";
	 ...
};

* MTD case:

flash@y {
	compatible = "<flash-compatible>";
	...
	otp {
		compatible = "user-otp"; /* or "factory-otp" */
		...
	};
};

In the former case, the nvmem device is "eeprom@x", while in the latter
case the nvmem device is "otp".

Nvmem devices can produce nvmem cells. The current way to describe nvmem
cells is to locate them by providing their static byte and bit offset
and length. These information are stored in subnodes of the nvmem
device.

It is now a fact that such description does not fit more advanced use
cases where the location or the size of the cells may vary. There are
currently three known situations which require being described
differently: Kontron's SL28 VPD, ONIE's TLV table and U-Boot's
environment variables.

Hence, we need a way to describe the parsers that must be used in order
to make the dynamic discovery of the nvmem cells. This new description
must fit both use cases (the generic situation and the MTD case).

Let's create in both cases a container node named nvmem-layout whose
content will depend on the parser. Right now nvmem-layout.yaml is
"empty", but references to additional layout parser bindings will be
inserted in the near future. The final goal being something that looks
like:

* Most cases (EEPROM & co):

eeprom@x {
	compatible = "<eeprom-compatible>";
	...
	nvmem-layout {
		compatible = "<parser-compatible>";
		...
	};
};

* MTD case:

flash@y {
	compatible = "<flash-compatible>";
	...
	otp {
		compatible = "user-otp"; /* or "factory-otp" */
		...
		nvmem-layout {
			compatible = "<parser-compatible>";
			...
		};
	};
};

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../bindings/nvmem/layouts/nvmem-layout.yaml  | 30 +++++++++++++++++++
 .../devicetree/bindings/nvmem/nvmem.yaml      |  7 +++++
 2 files changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
new file mode 100644
index 000000000000..ecc7c37cbc1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/nvmem-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM (Non Volatile Memory) layouts
+
+maintainers:
+  - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+  - Michael Walle <michael@walle.cc>
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+  Most NVMEM layouts are static and thus do not require additional description
+  besides the bytes/bits offset and length. Other layouts can be less statically
+  define and might require dynamic reading of the NVMEM device in order to
+  perform their parsing. The nvmem-layout container is here to describe these.
+
+properties:
+  compatible: true
+
+  '#address-cells': false
+
+  '#size-cells': false
+
+required:
+  - compatible
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 0455506fc30f..75bb93dda9df 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -39,6 +39,13 @@ properties:
       when it's driven low (logical '0') to allow writing.
     maxItems: 1
 
+  nvmem-layout:
+    $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+    description:
+      Alternative to the statically defined nvmem cells, this
+      container may reference more advanced (dynamic) layout
+      parsers.
+
 patternProperties:
   "@[0-9a-f]+(,[0-7])?$":
     type: object
-- 
2.34.1

[PATCH v3 3/6] dt-bindings: eeprom: Inherit from nvmem.yaml

[Miquel Raynal]

EEPROMs can be nvmem providers. Let's make all EEPROM bindings
reference nvmem.yaml as they should, so that nvmem cells and layout
parsers can be safely described within the EEPROM nodes.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 Documentation/devicetree/bindings/eeprom/at24.yaml           | 5 ++++-
 Documentation/devicetree/bindings/eeprom/at25.yaml           | 1 +
 .../devicetree/bindings/eeprom/microchip,93lc46b.yaml        | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml
index d14e0accbda8..84af0d5f52aa 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -10,6 +10,9 @@ title: I2C EEPROMs compatible with Atmel's AT24
 maintainers:
   - Bartosz Golaszewski <bgolaszewski@baylibre.com>
 
+allOf:
+  - $ref: /schemas/nvmem/nvmem.yaml
+
 select:
   properties:
     compatible:
@@ -183,7 +186,7 @@ required:
   - compatible
   - reg
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 8b1c997caac1..0f5a8ef996d3 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -104,6 +104,7 @@ required:
 
 allOf:
   - $ref: /schemas/spi/spi-peripheral-props.yaml#
+  - $ref: /schemas/nvmem/nvmem.yaml
   - if:
       properties:
         compatible:
diff --git a/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
index 0c2f5ddb79c5..64cfd971c9c5 100644
--- a/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
+++ b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
@@ -47,6 +47,7 @@ required:
 
 allOf:
   - $ref: /schemas/spi/spi-peripheral-props.yaml#
+  - $ref: /schemas/nvmem/nvmem.yaml
 
 unevaluatedProperties: false
 
-- 
2.34.1

[PATCH v3 4/6] dt-bindings: nvmem: add YAML schema for the sl28 vpd layout

[Miquel Raynal]

From: Michael Walle <michael@walle.cc>

Add a schema for the NVMEM layout on Kontron's sl28 boards.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../nvmem/layouts/kontron,sl28-vpd.yaml       | 60 +++++++++++++++++++
 .../bindings/nvmem/layouts/nvmem-layout.yaml  |  3 +
 2 files changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
new file mode 100644
index 000000000000..44088c8b4153
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
+
+maintainers:
+  - Michael Walle <michael@walle.cc>
+
+description:
+  The vital product data (VPD) of the sl28 boards contains a serial
+  number and a base MAC address. The actual MAC addresses for the
+  on-board ethernet devices are derived from this base MAC address by
+  adding an offset.
+
+properties:
+  compatible:
+    const: kontron,sl28-vpd
+
+  serial-number:
+    type: object
+    description: The board's serial number
+
+  base-mac-address:
+    type: object
+    description:
+      Base MAC address for all on-module network interfaces. The first
+      argument of the phandle will be treated as an offset.
+
+    properties:
+      "#nvmem-cell-cells":
+        const: 1
+
+    additionalProperties: false
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+      otp-1 {
+          compatible = "user-otp";
+
+          nvmem-layout {
+              compatible = "kontron,sl28-vpd";
+
+              serial_number: serial-number {
+              };
+
+              base_mac_address: base-mac-address {
+                  #nvmem-cell-cells = <1>;
+              };
+          };
+      };
+
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index ecc7c37cbc1f..f64ea2fa362d 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -17,6 +17,9 @@ description: |
   define and might require dynamic reading of the NVMEM device in order to
   perform their parsing. The nvmem-layout container is here to describe these.
 
+oneOf:
+  - $ref: kontron,sl28-vpd.yaml
+
 properties:
   compatible: true
 
-- 
2.34.1

[PATCH v3 5/6] dt-bindings: vendor-prefixes: Add ONIE

[Miquel Raynal]

As described on their website (see link below),

   "The Open Network Install Environment (ONIE) is an open source
    initiative that defines an open “install environment” for modern
    networking hardware."

It is not a proper corporation per-se but rather more a group which
tries to spread the use of open source standards in the networking
hardware world.

Link: https://opencomputeproject.github.io/onie/
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6e323a380294..65a74026cf2b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -927,6 +927,8 @@ patternProperties:
     description: One Laptop Per Child
   "^oneplus,.*":
     description: OnePlus Technology (Shenzhen) Co., Ltd.
+  "^onie,.*":
+    description: Open Network Install Environment group
   "^onion,.*":
     description: Onion Corporation
   "^onnn,.*":
-- 
2.34.1

[PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Miquel Raynal]

Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
compatible networking device.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
 .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
 2 files changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index f64ea2fa362d..8512ee538c4c 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -19,6 +19,7 @@ description: |
 
 oneOf:
   - $ref: kontron,sl28-vpd.yaml
+  - $ref: onie,tlv-layout.yaml
 
 properties:
   compatible: true
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
new file mode 100644
index 000000000000..1d91277324ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the ONIE tlv table
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description:
+  Modern networking hardware implementing the Open Compute Project ONIE
+  infrastructure shall provide a non-volatile memory with a table whose the
+  content is well specified and gives many information about the manufacturer
+  (name, country of manufacture, etc) as well as device caracteristics (serial
+  number, hardware version, mac addresses, etc). The underlaying device type
+  (flash, EEPROM,...) is not specified. The exact location of each value is also
+  dynamic and should be discovered at run time because it depends on the
+  parameters the manufacturer decided to embed.
+
+properties:
+  compatible:
+    const: onie,tlv-layout
+
+  product-name: true
+
+  part-number: true
+
+  serial-number: true
+
+  mac-address:
+    type: object
+    description:
+      Base MAC address for all on-module network interfaces. The first
+      argument of the phandle will be treated as an offset.
+
+    properties:
+      "#nvmem-cell-cells":
+        const: 1
+
+    additionalProperties: false
+
+  manufacture-date: true
+
+  device-version: true
+
+  label-revision: true
+
+  platforn-name: true
+
+  onie-version: true
+
+  num-macs: true
+
+  manufacturer: true
+
+  country-code: true
+
+  vendor: true
+
+  diag-version: true
+
+  service-tag: true
+
+  vendor-extension: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        eeprom@56 {
+            compatible = "atmel,24c64";
+            read-only;
+            reg = <0x56>;
+
+            nvmem-layout {
+                compatible = "onie,tlv-layout";
+
+                serial-number {
+                };
+            };
+        };
+    };
+
+  - |
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        flash@0 {
+            compatible = "m25p80", "jedec,spi-nor";
+            reg = <0>;
+
+            otp {
+                compatible = "user-otp";
+
+                nvmem-layout {
+                    compatible = "onie,tlv-layout";
+
+                    mac-address {
+                        #nvmem-cell-cells = <1>;
+                    };
+                };
+            };
+        };
+    };
+...
-- 
2.34.1

Re: [PATCH v3 1/6] dt-bindings: nvmem: Fix example

[Rob Herring]

On Fri, 04 Nov 2022 17:38:28 +0100, Miquel Raynal wrote:
> Despite not being listed nor required within the top level nvmem yaml
> file, the "compatible" property is mandatory and is actually enforced by
> all the nvmem provider bindings.
> 
> Unfortunately, the lack of compatible in the nvmem.yaml to level
> description file lead to the example not matching anything and thus not
> being checked at all.
> 
> Let's pick a compatible almost randomly (one which is already used with
> the qfprom label) to make the example at least valid on a semantic
> point of view and getting it checked.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  Documentation/devicetree/bindings/nvmem/nvmem.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Rob Herring]

On Fri, Nov 04, 2022 at 05:38:33PM +0100, Miquel Raynal wrote:
> Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
> compatible networking device.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
>  .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
>  2 files changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> index f64ea2fa362d..8512ee538c4c 100644
> --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> @@ -19,6 +19,7 @@ description: |
>  
>  oneOf:
>    - $ref: kontron,sl28-vpd.yaml
> +  - $ref: onie,tlv-layout.yaml
>  
>  properties:
>    compatible: true
> diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> new file mode 100644
> index 000000000000..1d91277324ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVMEM layout of the ONIE tlv table
> +
> +maintainers:
> +  - Miquel Raynal <miquel.raynal@bootlin.com>
> +
> +description:
> +  Modern networking hardware implementing the Open Compute Project ONIE
> +  infrastructure shall provide a non-volatile memory with a table whose the
> +  content is well specified and gives many information about the manufacturer
> +  (name, country of manufacture, etc) as well as device caracteristics (serial
> +  number, hardware version, mac addresses, etc). The underlaying device type
> +  (flash, EEPROM,...) is not specified. The exact location of each value is also
> +  dynamic and should be discovered at run time because it depends on the
> +  parameters the manufacturer decided to embed.
> +
> +properties:
> +  compatible:
> +    const: onie,tlv-layout
> +
> +  product-name: true

This is a node? If so, you need:

type: object
additionalProperties: false

> +
> +  part-number: true
> +
> +  serial-number: true
> +
> +  mac-address:
> +    type: object
> +    description:
> +      Base MAC address for all on-module network interfaces. The first
> +      argument of the phandle will be treated as an offset.
> +
> +    properties:
> +      "#nvmem-cell-cells":
> +        const: 1
> +
> +    additionalProperties: false
> +
> +  manufacture-date: true
> +
> +  device-version: true
> +
> +  label-revision: true
> +
> +  platforn-name: true
> +
> +  onie-version: true
> +
> +  num-macs: true
> +
> +  manufacturer: true
> +
> +  country-code: true
> +
> +  vendor: true
> +
> +  diag-version: true
> +
> +  service-tag: true
> +
> +  vendor-extension: true
> +
> +required:
> +  - compatible
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        eeprom@56 {
> +            compatible = "atmel,24c64";
> +            read-only;
> +            reg = <0x56>;
> +
> +            nvmem-layout {
> +                compatible = "onie,tlv-layout";
> +
> +                serial-number {
> +                };
> +            };
> +        };
> +    };
> +
> +  - |
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        flash@0 {
> +            compatible = "m25p80", "jedec,spi-nor";
> +            reg = <0>;
> +
> +            otp {
> +                compatible = "user-otp";
> +
> +                nvmem-layout {
> +                    compatible = "onie,tlv-layout";
> +
> +                    mac-address {
> +                        #nvmem-cell-cells = <1>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +...
> -- 
> 2.34.1
> 
> 

Re: [PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Miquel Raynal]

Hi Rob,

robh@kernel.org wrote on Wed, 9 Nov 2022 22:00:55 -0600:

> On Fri, Nov 04, 2022 at 05:38:33PM +0100, Miquel Raynal wrote:
> > Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
> > compatible networking device.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
> >  .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
> >  2 files changed, 116 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > index f64ea2fa362d..8512ee538c4c 100644
> > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > @@ -19,6 +19,7 @@ description: |
> >  
> >  oneOf:
> >    - $ref: kontron,sl28-vpd.yaml
> > +  - $ref: onie,tlv-layout.yaml
> >  
> >  properties:
> >    compatible: true
> > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > new file mode 100644
> > index 000000000000..1d91277324ac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > @@ -0,0 +1,115 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVMEM layout of the ONIE tlv table
> > +
> > +maintainers:
> > +  - Miquel Raynal <miquel.raynal@bootlin.com>
> > +
> > +description:
> > +  Modern networking hardware implementing the Open Compute Project ONIE
> > +  infrastructure shall provide a non-volatile memory with a table whose the
> > +  content is well specified and gives many information about the manufacturer
> > +  (name, country of manufacture, etc) as well as device caracteristics (serial
> > +  number, hardware version, mac addresses, etc). The underlaying device type
> > +  (flash, EEPROM,...) is not specified. The exact location of each value is also
> > +  dynamic and should be discovered at run time because it depends on the
> > +  parameters the manufacturer decided to embed.
> > +
> > +properties:
> > +  compatible:
> > +    const: onie,tlv-layout
> > +
> > +  product-name: true  
> 
> This is a node? If so, you need:
> 
> type: object
> additionalProperties: false

I thought referencing a schema under a property would be enough?

Indeed in nvmem.yaml we create the property nvmem-layout and make it
reference nvmem-layout.yaml. Then, in nvmem-layout.yaml:

	 oneOf:
	  - $ref: kontron,sl28-vpd.yaml
	  - $ref: onie,tlv-layout.yaml

we reference the different layouts that may apply (very much like what
you proposed to list the mtd partition parsers, if I got it right).

Isn't it enough?

Then if you look below there is an "additionalProperties: false"
defined.

> > +
> > +  part-number: true
> > +

[...]

> > +  service-tag: true
> > +
> > +  vendor-extension: true
> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: false

(here)

> > +
> > +examples:
> > +  - |
> > +    spi {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        eeprom@56 {
> > +            compatible = "atmel,24c64";
> > +            read-only;
> > +            reg = <0x56>;
> > +
> > +            nvmem-layout {
> > +                compatible = "onie,tlv-layout";
> > +
> > +                serial-number {
> > +                };
> > +            };
> > +        };
> > +    };
> > +
> > +  - |
> > +    spi {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        flash@0 {
> > +            compatible = "m25p80", "jedec,spi-nor";
> > +            reg = <0>;
> > +
> > +            otp {
> > +                compatible = "user-otp";
> > +
> > +                nvmem-layout {
> > +                    compatible = "onie,tlv-layout";
> > +
> > +                    mac-address {
> > +                        #nvmem-cell-cells = <1>;
> > +                    };
> > +                };
> > +            };
> > +        };
> > +    };
> > +...
> > -- 
> > 2.34.1
> > 
> >   


Thanks,
Miquèl

Re: [PATCH v3 4/6] dt-bindings: nvmem: add YAML schema for the sl28 vpd layout

[Rob Herring]

On Fri, Nov 04, 2022 at 05:38:31PM +0100, Miquel Raynal wrote:
> From: Michael Walle <michael@walle.cc>
> 
> Add a schema for the NVMEM layout on Kontron's sl28 boards.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  .../nvmem/layouts/kontron,sl28-vpd.yaml       | 60 +++++++++++++++++++
>  .../bindings/nvmem/layouts/nvmem-layout.yaml  |  3 +
>  2 files changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> new file mode 100644
> index 000000000000..44088c8b4153
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
> +
> +maintainers:
> +  - Michael Walle <michael@walle.cc>
> +
> +description:
> +  The vital product data (VPD) of the sl28 boards contains a serial
> +  number and a base MAC address. The actual MAC addresses for the
> +  on-board ethernet devices are derived from this base MAC address by
> +  adding an offset.
> +
> +properties:
> +  compatible:
> +    const: kontron,sl28-vpd
> +
> +  serial-number:
> +    type: object
> +    description: The board's serial number
> +
> +  base-mac-address:
> +    type: object
> +    description:
> +      Base MAC address for all on-module network interfaces. The first
> +      argument of the phandle will be treated as an offset.
> +
> +    properties:
> +      "#nvmem-cell-cells":
> +        const: 1
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +      otp-1 {
> +          compatible = "user-otp";
> +
> +          nvmem-layout {
> +              compatible = "kontron,sl28-vpd";
> +
> +              serial_number: serial-number {
> +              };
> +
> +              base_mac_address: base-mac-address {
> +                  #nvmem-cell-cells = <1>;
> +              };
> +          };
> +      };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> index ecc7c37cbc1f..f64ea2fa362d 100644
> --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> @@ -17,6 +17,9 @@ description: |
>    define and might require dynamic reading of the NVMEM device in order to
>    perform their parsing. The nvmem-layout container is here to describe these.
>  
> +oneOf:
> +  - $ref: kontron,sl28-vpd.yaml

This is the other way around from how we normally structure things. 
Normally, the specific schema would reference the common/base schema. 
This works, though you will be applying the schema twice. Once here and 
then by matching on compatible string. Not a big deal as that happens 
fairly often, but a 'select: false' in kontron,sl28-vpd.yaml would 
prevent that. This way does more to enforce the overall structure of 
nodes.

The one downside I see with it this way is nvmem-layout can't ever have 
common properties defined without listing them in each layout schema.

In the end, I'm okay with either way.

Rob

Re: [PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Rob Herring]

On Thu, Nov 10, 2022 at 09:50:34AM +0100, Miquel Raynal wrote:
> Hi Rob,
> 
> robh@kernel.org wrote on Wed, 9 Nov 2022 22:00:55 -0600:
> 
> > On Fri, Nov 04, 2022 at 05:38:33PM +0100, Miquel Raynal wrote:
> > > Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
> > > compatible networking device.
> > > 
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
> > >  .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
> > >  2 files changed, 116 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > index f64ea2fa362d..8512ee538c4c 100644
> > > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > @@ -19,6 +19,7 @@ description: |
> > >  
> > >  oneOf:
> > >    - $ref: kontron,sl28-vpd.yaml
> > > +  - $ref: onie,tlv-layout.yaml
> > >  
> > >  properties:
> > >    compatible: true
> > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > new file mode 100644
> > > index 000000000000..1d91277324ac
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > @@ -0,0 +1,115 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: NVMEM layout of the ONIE tlv table
> > > +
> > > +maintainers:
> > > +  - Miquel Raynal <miquel.raynal@bootlin.com>
> > > +
> > > +description:
> > > +  Modern networking hardware implementing the Open Compute Project ONIE
> > > +  infrastructure shall provide a non-volatile memory with a table whose the
> > > +  content is well specified and gives many information about the manufacturer
> > > +  (name, country of manufacture, etc) as well as device caracteristics (serial
> > > +  number, hardware version, mac addresses, etc). The underlaying device type
> > > +  (flash, EEPROM,...) is not specified. The exact location of each value is also
> > > +  dynamic and should be discovered at run time because it depends on the
> > > +  parameters the manufacturer decided to embed.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: onie,tlv-layout
> > > +
> > > +  product-name: true  
> > 
> > This is a node? If so, you need:
> > 
> > type: object
> > additionalProperties: false
> 
> I thought referencing a schema under a property would be enough?
> 
> Indeed in nvmem.yaml we create the property nvmem-layout and make it
> reference nvmem-layout.yaml. Then, in nvmem-layout.yaml:
> 
> 	 oneOf:
> 	  - $ref: kontron,sl28-vpd.yaml
> 	  - $ref: onie,tlv-layout.yaml
> 
> we reference the different layouts that may apply (very much like what
> you proposed to list the mtd partition parsers, if I got it right).
> 
> Isn't it enough?

No. It is enough to allow the property, but nothing defines what it must 
be (a node) and what the node contains in the case of empty nodes. Try 
adding 'product-name = "foo";' and it won't warn.

Rob

Re: [PATCH v3 4/6] dt-bindings: nvmem: add YAML schema for the sl28 vpd layout

[Miquel Raynal]

Hi Rob,

robh@kernel.org wrote on Thu, 10 Nov 2022 07:49:18 -0600:

> On Fri, Nov 04, 2022 at 05:38:31PM +0100, Miquel Raynal wrote:
> > From: Michael Walle <michael@walle.cc>
> > 
> > Add a schema for the NVMEM layout on Kontron's sl28 boards.
> > 
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >  .../nvmem/layouts/kontron,sl28-vpd.yaml       | 60 +++++++++++++++++++
> >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |  3 +
> >  2 files changed, 63 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > new file mode 100644
> > index 000000000000..44088c8b4153
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
> > +
> > +maintainers:
> > +  - Michael Walle <michael@walle.cc>
> > +
> > +description:
> > +  The vital product data (VPD) of the sl28 boards contains a serial
> > +  number and a base MAC address. The actual MAC addresses for the
> > +  on-board ethernet devices are derived from this base MAC address by
> > +  adding an offset.
> > +
> > +properties:
> > +  compatible:
> > +    const: kontron,sl28-vpd
> > +
> > +  serial-number:
> > +    type: object
> > +    description: The board's serial number
> > +
> > +  base-mac-address:
> > +    type: object
> > +    description:
> > +      Base MAC address for all on-module network interfaces. The first
> > +      argument of the phandle will be treated as an offset.
> > +
> > +    properties:
> > +      "#nvmem-cell-cells":
> > +        const: 1
> > +
> > +    additionalProperties: false
> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +      otp-1 {
> > +          compatible = "user-otp";
> > +
> > +          nvmem-layout {
> > +              compatible = "kontron,sl28-vpd";
> > +
> > +              serial_number: serial-number {
> > +              };
> > +
> > +              base_mac_address: base-mac-address {
> > +                  #nvmem-cell-cells = <1>;
> > +              };
> > +          };
> > +      };
> > +
> > +...
> > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > index ecc7c37cbc1f..f64ea2fa362d 100644
> > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > @@ -17,6 +17,9 @@ description: |
> >    define and might require dynamic reading of the NVMEM device in order to
> >    perform their parsing. The nvmem-layout container is here to describe these.
> >  
> > +oneOf:
> > +  - $ref: kontron,sl28-vpd.yaml  
> 
> This is the other way around from how we normally structure things. 
> Normally, the specific schema would reference the common/base schema. 
> This works, though you will be applying the schema twice. Once here and 
> then by matching on compatible string. Not a big deal as that happens 
> fairly often, but a 'select: false' in kontron,sl28-vpd.yaml would 
> prevent that. This way does more to enforce the overall structure of 
> nodes.

Oh right, I knew about the "select: false" thing, but I forgot it in
the two layouts.

> The one downside I see with it this way is nvmem-layout can't ever have 
> common properties defined without listing them in each layout schema.

Oh that's right, actually I solved it in the mtd dt-binding series with:

partitions.yaml:

	oneOf:
	  - $ref: <parser>.yaml

	generic-property:
	  $ref: something
	  min/max...: foo

<parser>.yaml:
	generic-property: true

But in this case, are the constraints provided by partitions.yaml on
"generic-property" actually still enforced?

Thanks,
Miquèl

Re: [PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Miquel Raynal]

Hi Rob,

robh@kernel.org wrote on Thu, 10 Nov 2022 08:05:45 -0600:

> On Thu, Nov 10, 2022 at 09:50:34AM +0100, Miquel Raynal wrote:
> > Hi Rob,
> > 
> > robh@kernel.org wrote on Wed, 9 Nov 2022 22:00:55 -0600:
> >   
> > > On Fri, Nov 04, 2022 at 05:38:33PM +0100, Miquel Raynal wrote:  
> > > > Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
> > > > compatible networking device.
> > > > 
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
> > > >  .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
> > > >  2 files changed, 116 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > index f64ea2fa362d..8512ee538c4c 100644
> > > > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > @@ -19,6 +19,7 @@ description: |
> > > >  
> > > >  oneOf:
> > > >    - $ref: kontron,sl28-vpd.yaml
> > > > +  - $ref: onie,tlv-layout.yaml
> > > >  
> > > >  properties:
> > > >    compatible: true
> > > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > new file mode 100644
> > > > index 000000000000..1d91277324ac
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > @@ -0,0 +1,115 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: NVMEM layout of the ONIE tlv table
> > > > +
> > > > +maintainers:
> > > > +  - Miquel Raynal <miquel.raynal@bootlin.com>
> > > > +
> > > > +description:
> > > > +  Modern networking hardware implementing the Open Compute Project ONIE
> > > > +  infrastructure shall provide a non-volatile memory with a table whose the
> > > > +  content is well specified and gives many information about the manufacturer
> > > > +  (name, country of manufacture, etc) as well as device caracteristics (serial
> > > > +  number, hardware version, mac addresses, etc). The underlaying device type
> > > > +  (flash, EEPROM,...) is not specified. The exact location of each value is also
> > > > +  dynamic and should be discovered at run time because it depends on the
> > > > +  parameters the manufacturer decided to embed.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: onie,tlv-layout
> > > > +
> > > > +  product-name: true    
> > > 
> > > This is a node? If so, you need:
> > > 
> > > type: object
> > > additionalProperties: false  
> > 
> > I thought referencing a schema under a property would be enough?
> > 
> > Indeed in nvmem.yaml we create the property nvmem-layout and make it
> > reference nvmem-layout.yaml. Then, in nvmem-layout.yaml:
> > 
> > 	 oneOf:
> > 	  - $ref: kontron,sl28-vpd.yaml
> > 	  - $ref: onie,tlv-layout.yaml
> > 
> > we reference the different layouts that may apply (very much like what
> > you proposed to list the mtd partition parsers, if I got it right).
> > 
> > Isn't it enough?  
> 
> No. It is enough to allow the property, but nothing defines what it must 
> be (a node) and what the node contains in the case of empty nodes. Try 
> adding 'product-name = "foo";' and it won't warn.

There was a misunderstanding on my side. I thought your comment was
about the nvmem-layout node. Actually you were commenting about all the
sub-nodes defining nvmem-cells inside, so I'm fully aligned with your
response.

However, if I understood it correctly, you basically said that:

	property:
	  $ref: foo.yaml

is not the same as:

	property:
	  type: object
	  $ref: foo.yaml

If that's the case, then should we consider dropping this patch (which
you agreed with in the first place)?

https://lore.kernel.org/linux-mtd/20221104164718.1290859-17-miquel.raynal@bootlin.com/T/#u 

Thanks,
Miquèl

Re: [PATCH v3 4/6] dt-bindings: nvmem: add YAML schema for the sl28 vpd layout

[Rob Herring]

On Thu, Nov 10, 2022 at 06:38:55PM +0100, Miquel Raynal wrote:
> Hi Rob,
> 
> robh@kernel.org wrote on Thu, 10 Nov 2022 07:49:18 -0600:
> 
> > On Fri, Nov 04, 2022 at 05:38:31PM +0100, Miquel Raynal wrote:
> > > From: Michael Walle <michael@walle.cc>
> > > 
> > > Add a schema for the NVMEM layout on Kontron's sl28 boards.
> > > 
> > > Signed-off-by: Michael Walle <michael@walle.cc>
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > >  .../nvmem/layouts/kontron,sl28-vpd.yaml       | 60 +++++++++++++++++++
> > >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |  3 +
> > >  2 files changed, 63 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > > new file mode 100644
> > > index 000000000000..44088c8b4153
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> > > @@ -0,0 +1,60 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
> > > +
> > > +maintainers:
> > > +  - Michael Walle <michael@walle.cc>
> > > +
> > > +description:
> > > +  The vital product data (VPD) of the sl28 boards contains a serial
> > > +  number and a base MAC address. The actual MAC addresses for the
> > > +  on-board ethernet devices are derived from this base MAC address by
> > > +  adding an offset.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: kontron,sl28-vpd
> > > +
> > > +  serial-number:
> > > +    type: object
> > > +    description: The board's serial number
> > > +
> > > +  base-mac-address:
> > > +    type: object
> > > +    description:
> > > +      Base MAC address for all on-module network interfaces. The first
> > > +      argument of the phandle will be treated as an offset.
> > > +
> > > +    properties:
> > > +      "#nvmem-cell-cells":
> > > +        const: 1
> > > +
> > > +    additionalProperties: false
> > > +
> > > +required:
> > > +  - compatible
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +      otp-1 {
> > > +          compatible = "user-otp";
> > > +
> > > +          nvmem-layout {
> > > +              compatible = "kontron,sl28-vpd";
> > > +
> > > +              serial_number: serial-number {
> > > +              };
> > > +
> > > +              base_mac_address: base-mac-address {
> > > +                  #nvmem-cell-cells = <1>;
> > > +              };
> > > +          };
> > > +      };
> > > +
> > > +...
> > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > index ecc7c37cbc1f..f64ea2fa362d 100644
> > > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > @@ -17,6 +17,9 @@ description: |
> > >    define and might require dynamic reading of the NVMEM device in order to
> > >    perform their parsing. The nvmem-layout container is here to describe these.
> > >  
> > > +oneOf:
> > > +  - $ref: kontron,sl28-vpd.yaml  
> > 
> > This is the other way around from how we normally structure things. 
> > Normally, the specific schema would reference the common/base schema. 
> > This works, though you will be applying the schema twice. Once here and 
> > then by matching on compatible string. Not a big deal as that happens 
> > fairly often, but a 'select: false' in kontron,sl28-vpd.yaml would 
> > prevent that. This way does more to enforce the overall structure of 
> > nodes.
> 
> Oh right, I knew about the "select: false" thing, but I forgot it in
> the two layouts.
> 
> > The one downside I see with it this way is nvmem-layout can't ever have 
> > common properties defined without listing them in each layout schema.
> 
> Oh that's right, actually I solved it in the mtd dt-binding series with:
> 
> partitions.yaml:
> 
> 	oneOf:
> 	  - $ref: <parser>.yaml
> 
> 	generic-property:
> 	  $ref: something
> 	  min/max...: foo
> 
> <parser>.yaml:
> 	generic-property: true
> 
> But in this case, are the constraints provided by partitions.yaml on
> "generic-property" actually still enforced?

Yes, they are. 

Rob

Re: [PATCH v3 6/6] dt-bindings: nvmem: add YAML schema for the ONIE tlv layout

[Rob Herring]

On Thu, Nov 10, 2022 at 06:43:34PM +0100, Miquel Raynal wrote:
> Hi Rob,
> 
> robh@kernel.org wrote on Thu, 10 Nov 2022 08:05:45 -0600:
> 
> > On Thu, Nov 10, 2022 at 09:50:34AM +0100, Miquel Raynal wrote:
> > > Hi Rob,
> > > 
> > > robh@kernel.org wrote on Wed, 9 Nov 2022 22:00:55 -0600:
> > >   
> > > > On Fri, Nov 04, 2022 at 05:38:33PM +0100, Miquel Raynal wrote:  
> > > > > Add a schema for the ONIE tlv NVMEM layout that can be found on any ONIE
> > > > > compatible networking device.
> > > > > 
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > > >  .../bindings/nvmem/layouts/nvmem-layout.yaml  |   1 +
> > > > >  .../nvmem/layouts/onie,tlv-layout.yaml        | 115 ++++++++++++++++++
> > > > >  2 files changed, 116 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > > index f64ea2fa362d..8512ee538c4c 100644
> > > > > --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> > > > > @@ -19,6 +19,7 @@ description: |
> > > > >  
> > > > >  oneOf:
> > > > >    - $ref: kontron,sl28-vpd.yaml
> > > > > +  - $ref: onie,tlv-layout.yaml
> > > > >  
> > > > >  properties:
> > > > >    compatible: true
> > > > > diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..1d91277324ac
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
> > > > > @@ -0,0 +1,115 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: NVMEM layout of the ONIE tlv table
> > > > > +
> > > > > +maintainers:
> > > > > +  - Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > +
> > > > > +description:
> > > > > +  Modern networking hardware implementing the Open Compute Project ONIE
> > > > > +  infrastructure shall provide a non-volatile memory with a table whose the
> > > > > +  content is well specified and gives many information about the manufacturer
> > > > > +  (name, country of manufacture, etc) as well as device caracteristics (serial
> > > > > +  number, hardware version, mac addresses, etc). The underlaying device type
> > > > > +  (flash, EEPROM,...) is not specified. The exact location of each value is also
> > > > > +  dynamic and should be discovered at run time because it depends on the
> > > > > +  parameters the manufacturer decided to embed.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: onie,tlv-layout
> > > > > +
> > > > > +  product-name: true    
> > > > 
> > > > This is a node? If so, you need:
> > > > 
> > > > type: object
> > > > additionalProperties: false  
> > > 
> > > I thought referencing a schema under a property would be enough?
> > > 
> > > Indeed in nvmem.yaml we create the property nvmem-layout and make it
> > > reference nvmem-layout.yaml. Then, in nvmem-layout.yaml:
> > > 
> > > 	 oneOf:
> > > 	  - $ref: kontron,sl28-vpd.yaml
> > > 	  - $ref: onie,tlv-layout.yaml
> > > 
> > > we reference the different layouts that may apply (very much like what
> > > you proposed to list the mtd partition parsers, if I got it right).
> > > 
> > > Isn't it enough?  
> > 
> > No. It is enough to allow the property, but nothing defines what it must 
> > be (a node) and what the node contains in the case of empty nodes. Try 
> > adding 'product-name = "foo";' and it won't warn.
> 
> There was a misunderstanding on my side. I thought your comment was
> about the nvmem-layout node. Actually you were commenting about all the
> sub-nodes defining nvmem-cells inside, so I'm fully aligned with your
> response.
> 
> However, if I understood it correctly, you basically said that:
> 
> 	property:
> 	  $ref: foo.yaml
> 
> is not the same as:
> 
> 	property:
> 	  type: object
> 	  $ref: foo.yaml
> 
> If that's the case, then should we consider dropping this patch (which
> you agreed with in the first place)?

From a json-schema standpoint, they may not be the same. You can't know 
without knowing what's in foo.yaml. They are the same only if foo.yaml 
contains 'type: object'. It does for us because the tools will add 
'type: object' to the top-level of every schema file.


properties:
  property:
    properties:
      foo: {}

These would all pass validation with the above:

property;
property = "bar";

More generally, json-schema's behavior is if a keyword doesn't apply for 
an instance, just silently ignore it. So while 'properties' keyword only 
makes sense on an object or maxItems on an array, json-schema doesn't 
care. The dtschema tools do a bit to counteract that.

Rob

Re: [PATCH v3 1/6] dt-bindings: nvmem: Fix example

[Srinivas Kandagatla]

On 04/11/2022 16:38, Miquel Raynal wrote:
> Despite not being listed nor required within the top level nvmem yaml
> file, the "compatible" property is mandatory and is actually enforced by
> all the nvmem provider bindings.
> 
> Unfortunately, the lack of compatible in the nvmem.yaml to level
> description file lead to the example not matching anything and thus not
> being checked at all.
> 
> Let's pick a compatible almost randomly (one which is already used with
> the qfprom label) to make the example at least valid on a semantic
> point of view and getting it checked.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied thanks

--srini
> ---
>   Documentation/devicetree/bindings/nvmem/nvmem.yaml | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> index 1eb22dba364c..0455506fc30f 100644
> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> @@ -67,6 +67,7 @@ examples:
>         #include <dt-bindings/gpio/gpio.h>
>   
>         qfprom: eeprom@700000 {
> +          compatible = "qcom,msm8974-qfprom", "qcom,qfprom";
>             #address-cells = <1>;
>             #size-cells = <1>;
>             reg = <0x00700000 0x100000>;