[PATCH] net: uclass: Save ethernet MAC address when generated

[Wolfgang Denk]

Dear Tom,

In message <20211117123548.GX24579 at 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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The net result is a system that is not only binary  compatible  with
4.3  BSD, but is even bug for bug compatible in almost all features."
- Avadit  Tevanian,  Jr.,  "Architecture-Independent  Virtual  Memory
Management  for  Parallel  and  Distributed  Environments:  The  Mach
Approach"