On Tue, Dec 31, 2024 at 2:35 PM Rob Herring [off-list ref] wrote:

On Fri, Dec 20, 2024 at 08:17:06PM +0100, Linus Walleij wrote:

quoted

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.

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
}

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

Yours,
Linus Walleij