Hi,
Am 2021-11-15 15:31, schrieb Wolfgang Denk:
In message <c0282bc070180d74e055f82b5ecab...@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-e5454e1c9...@xilinx.com/
