Am 2021-11-15 14:17, schrieb Marek Vasut:
On 11/15/21 1:24 PM, Michael Walle wrote:
Am 2021-11-15 13:15, schrieb Marek Vasut:
On 11/15/21 1:11 PM, Michael Walle wrote:
Don't get the MAC address by the environment, but by the platform
data
of the udevice. This will fix "net list" if the MAC address is
randomly
generated and won't change behavior when linux is booted.
Signed-off-by: Michael Walle <mich...@walle.cc>
---
Hi,
this is a proposal to fix the "net list" in a way that linux still
can have
its own fallback mechanism of MAC addresses even if the bootloader
has
CONFIG_NET_RANDOM_ETHADDR enabled.
The intention is to replace [1], where if I understood correctly,
the
intention was to fix "net list".
[1]
https://lore.kernel.org/u-boot/3996ba2ee4e6ac136c0802dc0df4ef9b1750157c.1635506067.git.michal.si...@xilinx.com/
Does that mean U-Boot and Linux will possibly each have different MAC
address on the same device ? That is clearly wrong and not how it is
supposed to work, U-Boot passes its ethaddr/ethNaddr settings to
Linux
so that they would have the same MAC address on the same device.
Yes they have different ones, but having a random mac address is
wrong
in the first place. So IMHO it is more useful to dectect that in
linux,
(and there was a good point that usually a user will look at dmesg and
not some u-boot output) than having two different random MAC
addresses,
one for u-boot and one for linux.
Currently U-Boot passes MAC address stored in ethaddr/ethNaddr
variable to Linux by patching it into DT, so Linux has the same MAC
address, that is the correct behavior.
If U-Boot generates random MAC address for some reason, then the same
random MAC address is also passed to Linux.
So, then why does linux have some other means to fix that? Which are
now not available anymore (or doesn't get triggered).
The argument that user cannot be bothered to look at U-Boot console
when debugging a problem with random MAC address being passed to Linux
is bogus, sorry. This is exactly where the user should look and fix
the problem.
Are you by any chance trying to work around some bug on your system,
where U-Boot is unable to obtain the correct MAC address from OTP and
pass that to Linux, so by ignoring the "ethaddr" variable here, you in
fact avoid passing that U-Boot MAC address to Linux and Linux uses
some internal fallback and picks MAC address from OTP itself ?
No I'm not, I try to preserve the initial intention of that random
ethernet address. But anyway. Take this patch or leave it. I'll turn
this option off and open code it into my board file (or just disable
it because I don't actually need it).
Initially that random MAC address thing was supposed to get networking
running in u-boot if there is no ethaddr at all, eg. for network
console.
Now we are passing this made up network address to linux, too. Why?
We are passing the MAC address used by U-Boot to Linux, it doesn't
matter whether it is random or not.
And again you're masking the error and possible fixes by linux itself.
Seems like this isn't an argument.
Just
because it is wrong to have two different mac addresses? Some drivers
doesn't even probe without one. And we are just masking away this
error.
You get this "two different mac addresses" between reboots. Which is
also
wrong. This actually strenghten my opinion that this "feature" should
be an u-boot only thing.
Maybe it would make sense to have U-Boot obtain the correct MAC
address on your machine first, and then pass that same correct MAC
address to Linux ?
Eh? I don't get it. That is the only reason to have this option.
Again, this has nothing to do with my board which doesn't have a
MAC address and cannot read it for now (because for now, the user
is expected to set it via the environment). It's about the correct
behavior of the said config option.
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.
-michael
