Re: NVMEM address DT post processing [Was: Re: [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order]

[Maxime Ripard <maxime.ripard@bootlin.com>]

On Sat, May 11, 2019 at 04:44:44PM +0200, Petr Štetiar wrote:
> So something like this?
>
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt b/Documentation/devicetree/bindings/nvmem/nvmem.txt
> index fd06c09b822b..d781e47b049d 100644
> --- a/Documentation/devicetree/bindings/nvmem/nvmem.txt
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
> @@ -1,12 +1,14 @@
>  = NVMEM(Non Volatile Memory) Data Device Tree Bindings =
>
>  This binding is intended to represent the location of hardware
> -configuration data stored in NVMEMs like eeprom, efuses and so on.
> +configuration data stored in NVMEMs like eeprom, efuses and so on. This
> +binding provides some basic transformation of the stored data as well.
>
>  On a significant proportion of boards, the manufacturer has stored
>  some data on NVMEM, for the OS to be able to retrieve these information
>  and act upon it. Obviously, the OS has to know about where to retrieve
> -these data from, and where they are stored on the storage device.
> +these data from, where they are stored on the storage device and how to
> +postprocess them.
>
>  This document is here to document this.
>
> @@ -29,6 +31,19 @@ Optional properties:
>  bits:  Is pair of bit location and number of bits, which specifies offset
>         in bit and number of bits within the address range specified by reg property.
>         Offset takes values from 0-7.
> +byte-indices: array, encoded as an arbitrary number of (offset, length) pairs,
> +            within the address range specified by reg property. Each pair is
> +            then processed with byte-transform in order to produce single u8
> +            sized byte.
> +byte-transform: string, specifies the transformation which should be applied
> +              to every byte-indices pair in order to produce usable u8 sized byte,
> +              possible values are "none", "ascii" and "bcd". Default is "none".
> +byte-adjust: number, value by which should be adjusted resulting output byte at
> +           byte-adjust-at offset.
> +byte-adjust-at: number, specifies offset of resulting output byte which should be
> +              adjusted by byte-adjust value, default is 0.
> +byte-result-swap: boolean, specifies if the resulting output bytes should be
> +                swapped prior to return
>
>  For example:
>
> @@ -59,6 +74,36 @@ For example:
>                 ...
>         };
>
> +Another example where we've MAC address for eth1 stored in the NOR EEPROM as
> +following sequence of bytes (output of hexdump -C /dev/mtdX):
> +
> + 00000180  66 61 63 5f 6d 61 63 20  3d 20 44 34 3a 45 45 3a  |fac_mac = D4:EE:|
> + 00000190  30 37 3a 33 33 3a 36 43  3a 32 30 0a 42 44 49 4e  |07:33:6C:20.BDIN|
> +
> +Which means, that MAC address is stored in EEPROM as D4:EE:07:33:6C:20, so
> +ASCII delimited by colons, but we can't use this MAC address directly as
> +there's only one MAC address stored in the EEPROM and we need to increment last
> +octet/byte in this address in order to get usable MAC address for eth1 device.
> +
> + eth1_addr: eth-mac-addr@18a {
> +     reg = <0x18a 0x11>;
> +     byte-indices = < 0 2
> +                      3 2
> +                      6 2
> +                      9 2
> +                     12 2
> +                     15 2>;
> +     byte-transform = "ascii";
> +     byte-increment = <1>;
> +     byte-increment-at = <5>;
> +     byte-result-swap;
> + };
> +
> + &eth1 {
> +     nvmem-cells = <&eth1_addr>;
> +     nvmem-cell-names = "mac-address";
> + };
> +

Something along those lines yes. I'm not sure why in your example the
cell doesn't start at the mac address itself, instead of starting at
the key + having to specify an offset though. The reg property is the
offset already.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com