netdev - Re: NVMEM address DT post processing [Was: Re: [PATCH net 0/3] add property "nvmem_macaddr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <547abcff-103a-13b8-f42a-c0bd1d910bbc@linaro.org>
Date:   Mon, 13 May 2019 09:25:55 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Petr Štetiar <ynezz@...e.cz>,
        Maxime Ripard <maxime.ripard@...tlin.com>
Cc:     Andy Duan <fugang.duan@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "john@...ozen.org" <john@...ozen.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Alban Bedel <albeu@...e.fr>, devicetree@...r.kernel.org
Subject: Re: NVMEM address DT post processing [Was: Re: [PATCH net 0/3] add
 property "nvmem_macaddr_swap" to swap macaddr bytes order]



On 11/05/2019 15:44, Petr Štetiar wrote:
>          };
>   
> +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";
> + };
> +
>   = Data consumers =
>   Are device nodes which consume nvmem data cells/providers.

TBH, I have not see the full thread as I don't seem to be added to the 
original thread for some reason!

Looking at the comments from last few emails, I think the overall idea 
of moving the transformations in to nvmem core looks fine with me. I 
remember we discuss this while nvmem was first added and the plan was to 
add some kinda nvmem plugin/transformation interface at cell/provider 
level. And this looks like correct time to introduce this.

My initial idea was to add compatible strings to the cell so that most 
of the encoding information can be derived from it. For example if the 
encoding representing in your example is pretty standard or vendor 
specific we could just do with a simple compatible like below:

eth1_addr: eth-mac-addr@18a {
	compatible = "xxx,nvmem-mac-address";
	reg = <0x18a 0x11>;	
};

&eth1 {
	nvmem-cells = <&eth1_addr>;
	nvmem-cell-names = "mac-address";
}

thanks,
srini