[PATCH] rockchip: board: assign up to 3 static Ethernet MAC addresses

[MichaIng]

Hi Quentin,

thanks for the review!

 > You could set the eth2addr in your board file if you wanted instead of
 > setting it for everybody.

We provide OS images for everyone, and our users complained about the 
changing MAC addresses. I agree with them that generally the exception 
is that MAC addresses are static by default, and randomising them being 
an optional privacy feature when connecting to untrusted networks, like 
a WiFi hotspot with a mobile phone. Setting eth2addr in boot 
script/environment would require a random MAC address generation our end 
on first boot or so on each system, to rule out collisions. Since U-Boot 
has the feature implemented already, it just makes sense to make use of 
it and extend it for the affected Rockchip builds, also to have the 
somewhat nicely aligned with the last digit deferring only. So we 
currently patch our sources.

 > What's the number when we'll decide this is too many? I have a board
 > with 5 Ethernet ports for example :)

Good question. In Germany we say "Aller guten Dinge sind drei" (All good 
things come in threes). Jokes aside: not sure whether there are Rockchip 
SoC boards which provide more Ethernet NICs, but I have 3 with 3 ones 
(in one case provided by an official expansion board), all RK3588 with 
two onboard PCIe adapters. There is another PCIe bus, but commonly used 
for an M.2 socket, not sure whether it could theoretically provide a 4th 
Ethernet adapter. I don't know the background about why the Ethernet 
driver/firmware is not able to read/assign the hardware MAC, or why 
there is no hardware MAC, as I understand that this is an IEEE 
requirement. So what U-Boot does seems a workaround, and I agree that, 
if there is no generic approach, it has limits.

 > I don't know how far we want to go to avoid defining unused ethXaddr
 > variables in the environment? We could use of_alias_get_highest_id for
 > example and generate enough environment variables based on that info?

This sounds reasonable. But are ethXaddr variables not generated before 
boot scripts are called, when the number of alias IDs cannot be known 
yet, and MAC addresses assigned afterwards, when the OS device tree was 
loaded? When generating the variables afterwards, all good, but then 
existing values assigned by boot script/env should not be overwritten, 
of course. Then a generic approach would be possible, incrementing the 
bit mask by one each loop, to assign up to a quite large number of MAC 
addresses to ethernet aliases.

Best regards,

Micha (aka MichaIng)
DietPi project lead