Date:   Tue, 30 Nov 2021 13:19:00 -0600
From:   Rob Herring <robh@kernel.org>
To:     Michael Walle <michael@walle.cc>
Cc:     devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Frank Rowand <frowand.list@gmail.com>,
        Ansuel Smith <ansuelsmth@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>
Subject: Re: [RFC PATCH] dt-bindings: nvmem: add transformation support
Message-ID: <YaZ5JNCFeKcdIfu8@robh.at.kernel.org>
References: <20211123134425.3875656-1-michael@walle.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211123134425.3875656-1-michael@walle.cc>
Precedence: bulk

On Tue, Nov 23, 2021 at 02:44:25PM +0100, Michael Walle wrote:
> 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
> boards.
> 
> 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.

A compatible string can define what is the format of the data.

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

I still don't think trying to encode transformations of data into the DT 
is right approach.

> 
> Example:
>   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.

The content and number of cells is supposed to be opaque to the client 
and interpreted by the provider. That's sort of true here, but not 
really because the interpretation is tied to 'transformation'. So I'm 
okay with adding cells, but not fixing the interpretation of them. A 
compatible should determine how the cells are interpreted.


> 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?

We don't have any choice if we add "#nvmem-cell-cells". There's already 
cases without it.

> 
> [1] https://lore.kernel.org/all/20210414152657.12097-2-michael@walle.cc/
> [2] https://lore.kernel.org/linux-devicetree/362f1c6a8b0ec191b285ac6a604500da@walle.cc/
> [3] https://lore.kernel.org/lkml/20211013131957.30271-1-srinivas.kandagatla@linaro.org/
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  .../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:
>    "#size-cells":
>      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.
> +
>    read-only:
>      $ref: /schemas/types.yaml#/definitions/flag
>      description:
>        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
> +
> +
>    wp-gpios:
>      description:
>        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>;
> +          };
>        };
>  
>  ...
> -- 
> 2.30.2
> 
>