public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Wolfgang Denk <wd@denx.de>
Cc: Marek Vasut <marex@denx.de>,
	u-boot@lists.denx.de,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Michal Simek <michal.simek@xilinx.com>,
	fried.dev@gmail.com, joe.hershberger@ni.com, sjg@chromium.org,
	Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH RFC] cmd: fix net list command
Date: Mon, 15 Nov 2021 15:52:51 +0100	[thread overview]
Message-ID: <bf1393770cc04a3fb2b271d25fa6a46c@walle.cc> (raw)
In-Reply-To: <1646331.1636986670@gemini.denx.de>

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/

  reply	other threads:[~2021-11-15 14:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 12:11 [PATCH RFC] cmd: fix net list command Michael Walle
2021-11-15 12:15 ` Marek Vasut
2021-11-15 12:24   ` Michael Walle
2021-11-15 13:17     ` Marek Vasut
2021-11-15 13:46       ` Michael Walle
2021-11-15 14:31         ` Wolfgang Denk
2021-11-15 14:52           ` Michael Walle [this message]
2021-11-15 14:57             ` Michal Simek
2021-11-15 15:07               ` Tom Rini
2021-11-15 15:22                 ` Wolfgang Denk
2021-11-15 15:38                   ` Tom Rini
2021-11-15 15:20               ` Wolfgang Denk
2021-11-15 16:12                 ` Michal Simek
2021-11-16 13:29                   ` Wolfgang Denk
2021-11-15 15:12             ` Tom Rini
2021-11-15 15:15               ` Michael Walle
2021-11-15 15:19                 ` Tom Rini
2021-11-15 15:25                   ` Wolfgang Denk
2021-11-15 15:45                     ` Tom Rini
2021-11-16 13:23                       ` Wolfgang Denk
2021-11-15 15:15             ` Wolfgang Denk
2021-11-15 15:21               ` Michael Walle
2021-11-15 16:45                 ` Marek Vasut
2021-11-16  6:14                   ` Ramon Fried
2021-11-16 13:33                     ` Wolfgang Denk
2021-11-16 14:10                       ` Tom Rini
2021-11-16 14:51                         ` Wolfgang Denk
2021-11-15 13:57     ` Tom Rini
2021-11-15 14:53       ` Michael Walle
2021-11-15 14:53 ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf1393770cc04a3fb2b271d25fa6a46c@walle.cc \
    --to=michael@walle.cc \
    --cc=fried.dev@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=joe.hershberger@ni.com \
    --cc=marex@denx.de \
    --cc=michal.simek@xilinx.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=wd@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox