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]

Date:   Mon, 13 May 2019 11:28:07 +0200
From:   Petr Štetiar <ynezz@...e.cz>
To:     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>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        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]

Maxime Ripard <maxime.ripard@...tlin.com> [2019-05-12 14:19:10]:

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

The cell starts at the MAC address itself, 0x180 is offset within the EEPROM
and 0xa is byte within the offset (off-by-one, correct should be 0x9 though).

  EEPROM                 byte within EEPROM offset
  offset    1  2  3  4  5  5  6  7   8  9  a  b  c  d  e  f
 ------------------------------------------------------------|-----------------
 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|

So this would produce following:

 eth1_addr: eth-mac-addr@189 {
    reg = <0x189 0x11>;         /* 0x44 0x34 0x3a 0x45 0x45 0x3a 0x30 0x37
                                 * 0x3a 0x33 0x33 0x3a 0x36 0x43 0x3a 0x32 0x30 */
    byte-indices = < 0 2        /* 0x44 0x34 */
                     3 2        /* 0x45 0x45 */
                     6 2        /* 0x30 0x37 */
                     9 2        /* 0x33 0x33 */
                    12 2        /* 0x36 0x43 */
                    15 2>;      /* 0x32 0x30 */
    byte-transform = "ascii";   /* 0xd4 0xee 0x7 0x33 0x6c 0x20 */
    byte-increment = <1>;
    byte-increment-at = <5>;    /* 0xd4 0xee 0x7 0x33 0x6c 0x21 */
    byte-result-swap;           /* 0x21 0x6c 0x33 0x7 0xee 0xd4 */
 };

-- ynezz