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: <20190514174447.GE93050@meh.true.cz>
Date:   Tue, 14 May 2019 19:44:47 +0200
From:   Petr Štetiar <ynezz@...e.cz>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Maxime Ripard <maxime.ripard@...tlin.com>,
        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]

Srinivas Kandagatla <srinivas.kandagatla@...aro.org> [2019-05-14 16:13:22]:

> On 13/05/2019 12:16, Petr Štetiar wrote:
> > Srinivas Kandagatla <srinivas.kandagatla@...aro.org> [2019-05-13 11:06:48]:
> > 
> > > On 13/05/2019 10:07, Petr Štetiar wrote:
> > > > Srinivas Kandagatla <srinivas.kandagatla@...aro.org> [2019-05-13 09:25:55]:
> > > > 
> > > > > 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:
> > > > 
> > > > that vendor/compatible list would be quite long[1], there are hundreds of
> > > 
> > > You are right just vendor list could be very long, but I was hoping that the
> > > post-processing would fall in some categories which can be used in
> > > compatible string.
> > > 
> > > Irrespective of which we need to have some sort of compatible string to
> > > enable nvmem core to know that there is some form of post processing to be
> > > done on the cells!. Without which there is a danger of continuing to adding
> > > new properties to the cell bindings which have no relation to each other.
> > 
> > makes sense, so something like this would be acceptable?
> > 
> >   eth1_addr: eth-mac-addr@18a {
> >       /* or rather linux,nvmem-post-process ? */
> >       compatible = "openwrt,nvmem-post-process";
> 
> I don't think this would be a correct compatible string to use here.
> Before we decide on naming, I would like to understand bit more on what are
> the other possible forms of storing mac address,
> Here is what I found,
> 
> Type 1: Octets in ASCII without delimiters. (Swapped/non-Swapped)
> Type 2: Octets in ASCII with delimiters like (":", ",", ".", "-"... so on)
> (Swapped/non-Swapped)
> Type 3: Is the one which stores mac address in Type1/2 but this has to be
> incremented to be used on other instances of eth.
> 
> Did I miss anything?

Type 4: Octets as bytes/u8, swapped/non-swapped

Currently just type4-non-swapped is supported. Support for type4-swapped was
goal of this patch series.

I've simply tried to avoid using mac-address for the compatible as this
provider could be reused by other potential nvmem consumers. The question is,
how much abstracted it should be then.

> My suggestion for type1 and type2 would be something like this, as long as
> its okay with DT maintainers
> 
> eth1_addr: eth-mac-addr@18a {
> 	compatible = "ascii-mac-address";
> 	reg = <0x18a 2>, <0x192 2>, <0x196 2>, <0x200 2>, <0x304 2>, <0x306 2>;
> 	swap-mac-address;
> 	delimiter = ":";
> };

with this reg array, you don't need the delimiter property anymore, do you?

> For type 3:
>
> This sounds like very much vendor specific optimization thing which am not
> 100% sure atm.  If dt maintainers are okay, may be we can add an increment
> in the "ascii-mac-address" binding itself.
> 
> Do you think "increment-at " would ever change?

Currently there's just one such real world use case in OpenWrt tree[1].
Probably some vendor decided to increment 4th octet.

> This [1] is what I had suggested at the end, where in its possible to add
> provider node with its own custom bindings. In above example nvmem_dev would
> be a proper nvmem provider.

Ok, thanks.

1. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts;h=43bec35fa2860fe4d52880ad24ff7c56f5060a0a;hb=HEAD#l109

-- ynezz