public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Michael Walle <michael@walle.cc>
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
Subject: Re: [PATCH RFC] cmd: fix net list command
Date: Mon, 15 Nov 2021 08:57:56 -0500	[thread overview]
Message-ID: <20211115135756.GD24579@bill-the-cat> (raw)
In-Reply-To: <df8fde785ddb250b51620448226c3ff4@walle.cc>

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

On Mon, Nov 15, 2021 at 01:24:34PM +0100, 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 <michael@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.simek@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.
> 
> 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? 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.

Do you have some link explaining this use case more clearly, ie why
U-Boot is using a random MAC being wrong?  We have a number of long
standing use cases today where U-Boot generates and uses the random MAC
and passes it to Linux and Linux would generate another random MAC, so
we avoid that mismatch by making sure Linux does get the random MAC we
generate.  The BeagleBoard xM is the first one that pops to mind for me,
but I believe it's typical on some classes of USB ethernet adapters.

-- 
Tom

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

  parent reply	other threads:[~2021-11-15 13:58 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
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 [this message]
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=20211115135756.GD24579@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=fried.dev@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=joe.hershberger@ni.com \
    --cc=marex@denx.de \
    --cc=michael@walle.cc \
    --cc=michal.simek@xilinx.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.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