[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <00f801d6936b$36551e20$a2ff5a60$@gmail.com>
Date: Fri, 25 Sep 2020 20:39:30 +0200
From: <ansuelsmth@...il.com>
To: "'Rob Herring'" <robh+dt@...nel.org>
Cc: "'Miquel Raynal'" <miquel.raynal@...tlin.com>,
"'Richard Weinberger'" <richard@....at>,
"'Vignesh Raghavendra'" <vigneshr@...com>,
"'David S. Miller'" <davem@...emloft.net>,
"'Jakub Kicinski'" <kuba@...nel.org>,
"'Andrew Lunn'" <andrew@...n.ch>,
"'Heiner Kallweit'" <hkallweit1@...il.com>,
"'Russell King'" <linux@...linux.org.uk>,
"'Frank Rowand'" <frowand.list@...il.com>,
"'Boris Brezillon'" <bbrezillon@...nel.org>,
"'MTD Maling List'" <linux-mtd@...ts.infradead.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
"'netdev'" <netdev@...r.kernel.org>
Subject: RE: [PATCH v3 3/4] of_net: add mac-address-increment support
> -----Original Message-----
> From: Rob Herring <robh+dt@...nel.org>
> Sent: Friday, September 25, 2020 8:24 PM
> To: Ansuel Smith <ansuelsmth@...il.com>
> Cc: Miquel Raynal <miquel.raynal@...tlin.com>; Richard Weinberger
> <richard@....at>; Vignesh Raghavendra <vigneshr@...com>; David S.
> Miller <davem@...emloft.net>; Jakub Kicinski <kuba@...nel.org>;
> Andrew Lunn <andrew@...n.ch>; Heiner Kallweit
> <hkallweit1@...il.com>; Russell King <linux@...linux.org.uk>; Frank
> Rowand <frowand.list@...il.com>; Boris Brezillon
> <bbrezillon@...nel.org>; MTD Maling List <linux-mtd@...ts.infradead.org>;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; netdev
> <netdev@...r.kernel.org>
> Subject: Re: [PATCH v3 3/4] of_net: add mac-address-increment support
>
> On Sun, Sep 20, 2020 at 3:57 AM Ansuel Smith <ansuelsmth@...il.com>
> wrote:
> >
> > Lots of embedded devices use the mac-address of other interface
> > extracted from nvmem cells and increments it by one or two. Add two
> > bindings to integrate this and directly use the right mac-address for
> > the interface. Some example are some routers that use the gmac
> > mac-address stored in the art partition and increments it by one for the
> > wifi. mac-address-increment-byte bindings is used to tell what byte of
> > the mac-address has to be increased (if not defined the last byte is
> > increased) and mac-address-increment tells how much the byte decided
> > early has to be increased.
>
> I'm inclined to say if there's a platform specific way to transform
> MAC addresses, then there should be platform specific code to do that
> which then stuffs the DT using standard properties. Otherwise, we have
> a never ending stream of 'generic' properties to try to handle
> different platforms' cases.
>
> Rob
I agree about the 'never ending stream'... But I think the increment feature
is not that platform specific. I will quote some number by another patch
that tried to implement the same feature in a different way, [1]
* mtd-mac-address used 497 times in 357 device tree files
* mtd-mac-address-increment used 74 times in 58 device tree files
* mtd-mac-address-increment-byte used 1 time in 1 device tree file
The mtd-mac-address is what this patchset is trying to fix with the nvmem
support. The increment is much more than 74 times since it doesn't count
SoC that have wifi integrated (it's common practice for SoC with integrated
wifi to take the switch mac and use it to set the wifi mac)
Actually what is really specific is the increment-byte that can be dropped
if we really want to.
I still think the increment feature would be very useful to add full support
for mac-address extracted from nvmem cell.
[1] https://patchwork.ozlabs.org/project/netdev/patch/1555445100-30936-1-git-send-email-ynezz@true.cz/
Powered by blists - more mailing lists