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

[Jonas Karlman]

Hi,

On 2025-06-27 16:49, Quentin Schulz wrote:
> 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.
>>

I cannot find any rockchip board in U-Boot or Linux that currently use a
ethernet2 alias, have you sent a Linux patch that I have missed?

The addition of eth1addr was done because there are and was in-tree
boards that have use for both ethaddr and eth1addr.

Suggest you send a Linux patch that adds or updates a rockchip dts to
include an ethernet2 alias before this is applied.

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

I fully agree, adding a new environment variable for all boards when
there is currently no upstream use for it does not seem very practical
and such proper solution should probably be worked on.

Regards,
Jonas

> 
> Cheers,
> Quentin