Re: [PATCH RFC] cmd: fix net list command

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4416 bytes --]

On Mon, Nov 15, 2021 at 03:57:51PM +0100, Michal Simek wrote:
> 
> 
> On 11/15/21 15:52, Michael Walle wrote:
> > Hi,
> > 
> > Am 2021-11-15 15:31, schrieb Wolfgang Denk:
> > > In message <c0282bc070180d74e055f82b5ecab5b0@walle.cc> you wrote:
> > > > 
> > > > And again you're masking the error and possible fixes by linux itself.
> > > > Seems like this isn't an argument.
> > > 
> > > Respecting the explicit will of the user (i. e using what he
> > > configured in U-Boot and passed to the kernel) is not an error.  it
> > > is intended and documented behaviour.
> > 
> > What is the will of the user in this case? It is the will of the
> > developer to make the board more robust. That is, if there is
> > for whatever reason no valid ethernet address found, then there
> > will be one generated. That is the sole purpose of the config
> > option in question (or maybe I used it completely wrong). So from
> > a user perspective, this shouldn't even happen and I doubt he is
> > even aware that there will be a random one. (I saw Tom's mail and
> > I'm not talking about the USB adapters where this might be the
> > normal case.) I might come from a different perspective, but
> > users ususally don't look at the serial output. Instead they
> > look at the kernel log. And there will be not the slightest
> > error, because u-boot will happily fix the missing MAC address
> > with a random one.
> > 
> > > > Sorry, if the original intention was to make "net list" work
> > > > correctly, then why is there now such a huge fuzz around that
> > > > CONFIG_NET_RANDOM_ETHADDR config option and why can't we just
> > > > fix the error with "net list" and leave the behavior like it
> > > > was for years.
> > > 
> > > Maybe you explain what exactly the ``error with "net list"'' is,
> > 
> > Michal mentioned it here [1].
> > 
> > > considering the fact that it is U-Boot which determins the
> > > "correct" MAC address and passes it to Linux.  And if the user
> > > configures U-Boot such that a random MAC address is used, then this
> > > _is_ the correct MAC address, as normally (*) U-Boot is just a tool
> > > that does what the user requests.
> > 
> > Only that the user doesn't do it but the board developer/OEM. I.e.
> > there is no valid MAC address to pass to linux. It is really just
> > for having netconsole running (or maybe you'll need networking for
> > to rescue your failed EEPROM or whatever).
> > 
> > I think, we have to distiguish between two use cases here:
> >   (1) make networking in u-boot work "somehow", to have a last
> >       resort recovery, esp. required for netconsole where
> >       the user cannot set the mac address by hand.
> >   (2) normal use case, where drivers simply doesn't have any
> >       other source for the mac address and need to fall back
> >       to a random one.
> > 
> > I agree, for (2) the mac address should be passed to linux. But for
> > (1) it shouldn't because it will just mask the error and any fall
> > back mechanisms in linux.
> >
> > -michael
> > 
> > [1] https://lore.kernel.org/u-boot/07b688d8-f05f-d11e-5e3e-e5454e1c9af0@xilinx.com/
> 
> As we discussed in previous thread. I think there shouldn't be a problem
> when u-boot passes random mac address (in whatever way) but if Linux driver
> know how to get correct one it should be tried first. If that pass you will
> get new one. If not you will use the one passed from u-boot.

I think part of the problem here is that Linux can be inconsistent with
how it behaves here?  I remember there being some headaches early on
with the TI CPSW driver in Linux being allowed to, or not allowed to,
figure out where the MAC was.  But that was a long time ago now and
things are perhaps different now.

> And it is up to board designer to decide when it is the right time. I can
> imagine that it can be the part of kernel driver or can be purely done in
> user space.

It might also be the case that in U-Boot some systems that are using
NET_RANDOM_ETHADDR that really probably shouldn't?  A quick grep shows
253 platforms enabling it today, which feels high for the number of
boards in the "we'll never have a valid MAC, need a random one"
category.  Thinking out loud, perhaps we need an option for "no possible
valid MAC on board" and a different option for "random MAC for fall-back
only" ?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]