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

From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: Ramon Fried <rfried.dev@gmail.com>,
	Michael Walle <michael@walle.cc>,
	Michal Simek <michal.simek@xilinx.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	git <git@xilinx.com>, Joe Hershberger <joe.hershberger@ni.com>,
	Simon Glass <sjg@chromium.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH] net: uclass: Save ethernet MAC address when generated
Date: Wed, 17 Nov 2021 13:24:58 +0100	[thread overview]
Message-ID: <1820750.1637151898@gemini.denx.de> (raw)
In-Reply-To: <20211117115025.GV24579@bill-the-cat>

Dear Tom,

In message <20211117115025.GV24579@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".

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

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

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

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

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.

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@denx.de
Success in marriage is not so much finding the right person as it  is
being the right person.