[PATCH RFC] cmd: fix net list command

Michal Simek michal.simek at xilinx.com
Mon Nov 15 15:57:51 CET 2021

On 11/15/21 15:52, Michael Walle wrote:
> Hi,
> Am 2021-11-15 15:31, schrieb Wolfgang Denk:
>> In message <c0282bc070180d74e055f82b5ecab5b0 at 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.
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.


More information about the U-Boot mailing list