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

[Quentin Schulz]

Hi Micha,

On 6/18/25 6:24 PM, MichaIng wrote:
> Hi Quentin,
> 
>  > Please keep the ML in Cc.
> 
> Was too late for me yesterday :).
> 
>  > We currently have 137 defconfigs for Rockchip boards (git grep -l
>  > ARCH_ROCKCHIP configs/ | wc -l), so not sure 3 is a reasonable 
> threshold :)
> 
> I mean just for us/me, coding efforts and maintaining a patch, it is 
> easier to do it right there, where it is done right now for ethaddr and 
> eth1addr already for all Rockchip boards, instead of creating overrides 
> for 3 particular boards. I hope an additional eth2addr is fine for now, 
> until we found a better/more generic solution.
> 

Up to Kever, no strong opinion on this.

[...]

>  > Not sure to understand what you want to do here or what's the issue 
> sorry.
>  >
>  > You need also eth*addr for use in U-Boot (if you do PXE, TFTP, ping,
>  > whatever involving networking) so it makes sense to have them in U-Boot
>  > DT as well.
> 
> U-Boot assigns those variables to ethernet aliases on its own device 
> tree as well? Would be reasonable, but for me this is minor. At least I 

If DM_SEQ_ALIAS is enabled, I believe so.

> did not hear from a case where someone was complaining about a random 
> MAC address for network boot.
> 

I would imagine people be surprised if the same device operates under 
two different MAC addresses depending on which SW is running at the 
moment (U-Boot or Linux for example).

> What I aim for is U-Boot assigning static MAC addresses to ethernet 
> aliases defined in/for the kernel device tree, better in a more generic 
> than specific way, so it does not need to be changed again each time a 
> new SBC (with new SoC) with multiple onboard Ethernet adapters arrives. 
> Adding the aliases to the kernel device tree is then a different topic, 
> not related to U-Boot, which I however aim to achieve upstream as well. 
> If U-Boot syncs these back, it allows static MAC addresses for related 
> adapters in U-Boot phase as well, of course.
> 
>  > U-Boot may point to ethernet1 in kernel for example, in which case MAC
>  > addresses may all get swapped between U-Boot and kernel. This is
>  > theoretically possible, not sure how likely it is to happen though.
> 
> That could happpen already now with the often at least 2 aliases 
> defined. I wonder whether it can cause issues with PXE boot etc. In the 
> cases I know, a dedicated dtb is shipped as well, and I am not even sure 
> whether the network connection remains the same between U-Boot phase and 
> kernel phase? In any case, as long as any new generic MAC assignment 

I would assume the kernel to be reconfiguring the network stack while 
booting anyway, with renegotiation and all, but just a gut feeling, 
nothing to back this up.

To sum up, not much against this patch except that it's not ideal to add 
an environment variable most boards don't have a use for (but probably 
so is eth1addr :) ), and I think we would benefit from some generic 
implementation to set random Ethernet MAC addresses based on ethernet 
aliases in DT.

Cheers,
Quentin