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
