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

[Tom Rini]

On Wed, Nov 17, 2021 at 01:24:58PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20211117115025.GV24579 at bill-the-cat> you wrote:
> > 
> > > If the MAC address is not placed in the environment, then how can a
> > > user query the currently used MAC address?  All documentation says
> > > basically: run "printenv ethaddr".
> >
> > Update the documentation and say to use "net list" or read the previous
> > part of console log that says we're using a random mac in this case?
> > The more I look here the more I see we're changing part of the API with
> > the OS, and it's not something that should be done without consulting
> > the consumers too.
> 
> Well... "printenv ethaddr" has been here ever since U-Boot (or
> PPCBoot, as it was still called at that time) got network support.
> i. e. more than 21 years ago.
> 
> "net list: has only been added very recently, just 5 months ago in
> commit 8a3987f47 "cmd: net: add a 'net list' command to list network
> devs".

OK, so "net list" hasn't been broken that long, good.

> I bet that an overwhelming majority of users would use "printenv
> ethaddr" when asked to check the MAC address of a system.

And it's not shown the randomly generated one for that long either.

> > Next, pulling up
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet-c=
> > ontroller.yaml
> > there's two important things.  First, there's no way to flag "this is a
> > random MAC, do not use" (if after all, that's what the user wants, such
> > as in Michael's case).  And second, yes we probably ought to have
> > enforced "mac-address" being the random one we had been using, all
> > along.
> 
> 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?

> > So no, in sum, I'm not convinced that the best path forward right here
> > and now is to put the random MAC in the environment, not correct the now
> > incorrect help text and not even poke the binding maintainer nor
> > relevant lists to see how exactly they think it would be best to handle
> > a locally administered MAC being used as there are both valid use cases
> > for "use this in the kernel" and "disregard this in the kernel".
> 
> 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.

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

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211117/5f74295f/attachment.sig>