archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <>
Cc: Srinivas Kandagatla <>,
	Rob Herring <>,
	Frank Rowand <>,
	Ansuel Smith <>, Andrew Lunn <>,
	Michael Walle <>
Subject: [RFC PATCH] dt-bindings: nvmem: add transformation support
Date: Tue, 23 Nov 2021 14:44:25 +0100	[thread overview]
Message-ID: <> (raw)

This is my second attempt to solve the use case where there is only the
base MAC address stored in an EEPROM or similar storage provider. This
is the case for the Kontron sl28 board and multiple openwrt supported

The first proposal [1] didn't find much appreciation and there wasn't
any reply to my question or new proposal [2]. So here we are with my new
proposal, that is more flexible and doesn't fix the ethernet mac only.
This is just an RFC for the device tree representation for now to see if
this is the correct way to tackle this.

I'm also aware of the latest post process hook support [3]. This doesn't
fix the base mac address issue, but I think it also doesn't solve the
case with swapped ethernet addresses in the general case. That hook will
involve the driver to do the swapping, but how would the driver know
if that swapping is actually required. Usually the interpretation of the
content is opaque to the driver, after all it is the user/board
manufacturer who does program the storage device. We might be lucky in
the imx-ocotp case because the IMX reference manual actually states
where and in which format the mac address is programmed.

Introduce a transformation property. This is intended to be just an
enumeration of operations. If there will be a new operation, support for
it has to be added to the nvmem core.

A transformation might have multiple output values, like in the base mac
address case. It reads the mac address from the nvmem storage and
generates multiple individual addresses, i.e. on our board we reserve 8
consecutive addresses. These addresses then can be assigned to different
network interfaces. To make it possible to reference different values we
need to introduce an argument to the phandle. This additional argument
is then an index into a list of values.

  mac_addresses: base-mac-address@10 {
    #nvmem-cell-cells = <1>;
    reg = <10 6>;
    transformation = <NVMEM_T_ETH_OFFSET 0 1 7>;

  &eth0 {
    nvmem-cells = <&mac_addresses 0>;
    nvmem-cell-names = "mac-address";

  &eth1 {
    nvmem-cells = <&mac_addresses 2>;
    nvmem-cell-names = "mac-address";

The NVMEM_T_ETH_OFFSET transformation takes N additional (dt) cells and
will generate N values. In this example BASE_MAC+0, BASE_MAC+1, BASE_MAC+7.
An nvmem consumer can then reference the nvmem cell with an index. So eth0
will get BASE_MAC+0 and eth1 will get BASE_MAC+7.

This should be sufficient flexible for many different transformations
without having to touch the bindings except for adding documentation and
checks for new transformations.

I do have one question regarding "#nvmem-cell-cells" (aside from the
awkward naming): is it allowed to have that property optional if there
is no additional argument to the phandle?


Signed-off-by: Michael Walle <>
 .../devicetree/bindings/nvmem/nvmem.yaml      | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 456fb808100a..8893d045be77 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -26,11 +26,34 @@ properties:
     const: 1
+  '#nvmem-cell-cells':
+    enum: [0, 1]
+    description:
+      Must be 1 if the transformations has multiple output values.
+      The argument is then the index into the list of output values.
+      For example, if the nvmem cell only specify a base ethernet
+      address the transformation can then create different individual
+      ethernet addresses.
     $ref: /schemas/types.yaml#/definitions/flag
       Mark the provider as read only.
+  transformation:
+    description:
+      Transform the content of a NVMEM cell. Sometimes it is necessary
+      to preprocess the content of a cell so it is usable by the NVMEM
+      consumer. There are also cases where one NVMEM cell value can
+      generate a list of values.
+      Use one of the NVMEM_T_* prefixed definitions from the header
+      include/dt-bindings/nvmem/nvmem.h.
+      Some transformations might have additional arguments.
+    $ref: /schemas/types.yaml#/definitions/uint32
       GPIO to which the write-protect pin of the chip is connected.
@@ -98,6 +121,12 @@ examples:
               reg = <0xc 0x1>;
               bits = <2 3>;
+          ethernet_base_mac: base-mac-address@100 {
+              #nvmem-cell-cells = <1>;
+              reg = <0x100 0x6>;
+              transformation = <NVMEM_T_ETH_OFFSET 0 1 2 7>;
+          };

             reply	other threads:[~2021-11-23 13:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23 13:44 Michael Walle [this message]
2021-11-23 16:34 ` [RFC PATCH] dt-bindings: nvmem: add transformation support Rob Herring
2021-11-29 12:54 ` Srinivas Kandagatla
2021-11-29 17:43   ` Michael Walle
2021-11-30 11:54     ` Srinivas Kandagatla
2021-11-30 19:19 ` Rob Herring
2021-12-01 14:30   ` Michael Walle
2021-12-01 16:31     ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).