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: <20241231133533.GA50130-robh@kernel.org>
Date: Tue, 31 Dec 2024 07:35:33 -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 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.

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

Rob

[1] https://lore.kernel.org/linux-devicetree/20230509143504.30382-4-fr0st61te@gmail.com/
[2] https://lore.kernel.org/linux-devicetree/20211123134425.3875656-1-michael@walle.cc/
[3] https://lore.kernel.org/linux-devicetree/20200919214941.8038-5-ansuelsmth@gmail.com/