netdev - Re: [PATCH 1/2] dt-bindings: net: ethernet-controller: Add mac offset option

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] [day] [month] [year] [list]

Message-ID: <20250114194751.GA1601275-robh@kernel.org>
Date: Tue, 14 Jan 2025 13:47:51 -0600
From: Rob Herring <robh@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: net: ethernet-controller: Add mac
 offset option

On Mon, Jan 13, 2025 at 03:59:24PM +0100, Linus Walleij wrote:
> On Tue, Dec 31, 2024 at 2:35 PM Rob Herring <robh@...nel.org> wrote:
> > On Fri, Dec 20, 2024 at 08:17:06PM +0100, Linus Walleij wrote:
> 
> > > In practice (as found in the OpenWrt project) many devices
> > > with multiple ethernet interfaces just store a base MAC
> > > address in NVMEM and increase the lowermost byte with one for
> > > each interface, so as to occupy less NVMEM.
> > >
> > > Support this with a per-interface offset so we can encode
> > > this in a predictable way for each interface sharing the
> > > same NVMEM cell.
> >
> > This has come up several times before[1][2][3]. Based on those I know
> > this is not sufficient with the different variations of how MAC
> > addresses are shared. OTOH, I don't think a bunch of properties to deal
> > with all the possible transforms works either. It will be one of those
> > cases of properties added one-by-one where we end up with something
> > poorly designed. I think probably we want to just enumerate different
> > schemes and leave it to code to deal with each scheme.
> 
> The problem here is that the code needs some handle on which
> ethernet instance we are dealing with so the bindings need some
> way to pass that along from the consumer.
> 
> What about a third, implementation-defined nvmem cell?
> #mac-index-cells = <1>; or however we best deal with
> this.

We have #nvmem-cells-cells, doesn't that work?

> If it really is per-machine then maybe this is simply one of those
> cases where the kernel should:
> 
> if (IS_ENABLED(CONFIG_ARCH_FOO) &&
>    of_machine_is_compatible("foo,bar-machine)) {
>     // Read third cell if present
>     // Add to minor mac address
> }

Where would that go? I think it needs to be in the nvmem driver because 
that is what knows the format of the data and the transform needed.

> 
> > Or we could just say it is the bootloader's problem to figure this out
> > and populate the DT using the existing properties for MAC addresses.
> > Though bootloaders want to use DT too...
> 
> In my current case it's so fantastically organized that if the bootloader
> goes into TFTP boot it will use *another* unique MAC address.
> (Yes, it's fantastic.)

Fun.

Rob