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@xxxxxxxxxx> 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
