Dear Tom,
In message 20211117123548.GX24579@bill-the-cat you wrote:
Why would you expect any "do not use" note? Locally adminitered MAC addresses (even when randomly chosen) have been created for good reason, so they should be usable.
Because as been noted in either this thread, or the other long thread, the user does not want to confuse Linux with this emergency random MAC?
Classical answer: Don't do it, then.
If the user does not want to pass a MAC address to Linux, he should simply not do it. Deleting "ethaddr" from the environment should be all that's needed. [And if this does not work, then I consider this a bug that should be fixed.]
I'm afraid I do not understand what exactly you are proposing here?
I'm objecting to changing our long standing behavior of NOT automatically passing the random MAC to the OS. That has always been user opt-in by using tools/gen_eth_addr and "setenv ethaddr ... ; saveenv". Especially since I don't know how many of those 200+ boards that enable CONFIG_NET_RANDOM_ETHADDR today are "enabled, but never used" vs "enabled, random MAC in U-Boot since we don't care/didn't notice, real MAC in Linux". So yes, another worry is that we have a class of boards in U-Boot where a random MAC is fine enough since it's rarely used/needed, but Linux can get the real MAC and now we'll be blowing that away. Or maybe we just have a ton of boards that copypasta'd that option in and didn't really think why.
Unfortunately we can only speculate about that [my guess is that most of them are just copy/paste while brain in low power mode].
But I object to using a MAC address in U-Boot in a way that makes it invisible to the user who uses documented APIs ("printenv ethaddr").
Well, that's the API we've had for over 10 years, and it was a common problem in those earlier days with lots of SBCs where it was cheap to toss in a USB eth controller that didn't store a MAC anywhere. Now we're I believe hitting this due to FPGA stuff.
CONFIG_NET_RANDOM_ETHADDR has been added in 2015 with commit bef1014 "net: Implement random ethaddr fallback in eth.c"; from the changes then I'm not sure if this was even USB related.
If we use some MAC address, it shall be possible to read it using "printenv ethaddr" and to set it using "setenv ethaddr". Anything else is inconsistent crap.
Well, we've been inconsistent about the former for forever and there's a lot of implications to changing it now.
Yes. However, being bug-compatible is something we should not rate too high.
[non-random signature used]
Best regards,
Wolfgang Denk