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;
> + };
> +
> + ð1 {
> + nvmem-cells = <ð1_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
