All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Michal Simek <michal.simek@xilinx.com>
Cc: Michael Walle <michael@walle.cc>,
	rfried.dev@gmail.com, git@xilinx.com, joe.hershberger@ni.com,
	sjg@chromium.org, u-boot@lists.denx.de
Subject: Re: [PATCH] net: uclass: Save ethernet MAC address when generated
Date: Thu, 4 Nov 2021 07:37:47 -0400	[thread overview]
Message-ID: <20211104113747.GI24579@bill-the-cat> (raw)
In-Reply-To: <d21e7ca6-fbb9-becf-ebde-f9ac71e82830@xilinx.com>

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

On Thu, Nov 04, 2021 at 12:18:46PM +0100, Michal Simek wrote:
> 
> 
> On 11/3/21 17:57, Tom Rini wrote:
> > On Tue, Nov 02, 2021 at 11:27:22AM +0100, Michal Simek wrote:
> > > 
> > > 
> > > On 11/2/21 10:00, Michael Walle wrote:
> > > > > On Fri, Oct 29, 2021 at 2:14 PM Michal Simek <michal.simek@xilinx.com> wrote:
> > > > > > 
> > > > > > When MAC address is randomly generated it should be also saved to
> > > > > > variables. This step is there when MAC address is passed via pdata but not
> > > > > > when it is randomly generated.
> > > > > > 
> > > > > > Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> > > > > > ---
> > > > > > 
> > > > > >    net/eth-uclass.c | 2 ++
> > > > > >    1 file changed, 2 insertions(+)
> > > > > > 
> > > > > > diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> > > > > > index 0da0e85be031..58c308f33276 100644
> > > > > > --- a/net/eth-uclass.c
> > > > > > +++ b/net/eth-uclass.c
> > > > > > @@ -583,6 +583,8 @@ static int eth_post_probe(struct udevice *dev)
> > > > > >                   net_random_ethaddr(pdata->enetaddr);
> > > > > >                   printf("\nWarning: %s (eth%d) using random MAC address - %pM\n",
> > > > > >                          dev->name, dev_seq(dev), pdata->enetaddr);
> > > > > > +               eth_env_set_enetaddr_by_index("eth", dev_seq(dev),
> > > > > > +                                             pdata->enetaddr);
> > > > > >    #else
> > > > > >                   printf("\nError: %s address not set.\n",
> > > > > >                          dev->name);
> > > > > > --
> > > > > > 2.33.1
> > > > > > 
> > > > > Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
> > > > 
> > > > Please note, that this will change behavior. Before this commit, the
> > > > random mac address was local to u-boot (at least for most network drivers).
> > > > After this commit, it will also be communicated to linux.
> > > > 
> > > > I'm not sure what to think of this. At the very least, this should be
> > > > documented in the commit message and in the Kconfig help text.
> > > 
> > > Thanks for bringing this up. I have no issue that this address is being
> > > propagated to Linux but others can feel this as an issue.
> > > I can definitely extend commit message to say it.
> > > 
> > > I found this via net list command where you can see controllers but you
> > > can't see their mac addresses which is IMHO wrong.
> > 
> > So, this causes dhcp to simply timeout for me on a pine64_plus board
> > (where yes, I believe we do end up using a random MAC) when running the
> > pytest suite.  I wonder if this particular change messes up the state
> > machine?  Checking the dnsmasq logs it looks like U-Boot keeps asking
> > and getting a reply, over and over.
> 
> It is just saving that values to variables. If you want to propagete that
> values in the stack that's up to your system configuration.
> 
> What state machine are you talking about?

I was just making a guess about state machine, given what I had recalled
of the network stack before.  To be clearer, I bisected down my failure
of 3 tests that run "setenv autoload no ; dhcp" and then dhcp timing
out, to this commit (in the network PR).

-- 
Tom

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

  reply	other threads:[~2021-11-04 11:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 11:14 [PATCH] net: uclass: Save ethernet MAC address when generated Michal Simek
2021-11-01 20:25 ` Ramon Fried
2021-11-02  9:00   ` Michael Walle
2021-11-02 10:27     ` Michal Simek
2021-11-03 16:57       ` Tom Rini
2021-11-04 11:18         ` Michal Simek
2021-11-04 11:37           ` Tom Rini [this message]
2021-11-04 11:43             ` Michal Simek
2021-11-04 12:59               ` Tom Rini
2021-11-04 13:06                 ` Michal Simek
2021-11-04  2:09       ` Grygorii Strashko
2021-11-04 11:16         ` Michal Simek
2021-11-04 12:27           ` Michael Walle
2021-11-04 13:15             ` Michal Simek
2021-11-04 13:40               ` Michael Walle
2021-11-04 21:00                 ` Ramon Fried
2021-11-09 13:55                   ` Michael Walle
2021-11-11  9:10                     ` Michael Walle
2021-11-16 14:18                       ` Tom Rini
2021-11-16 14:56                         ` Wolfgang Denk
2021-11-16 18:41                           ` Tom Rini
2021-11-17  7:44                             ` Wolfgang Denk
2021-11-17 11:50                               ` Tom Rini
2021-11-17 12:24                                 ` Wolfgang Denk
2021-11-17 12:35                                   ` Tom Rini
2021-11-17 15:56                                     ` Wolfgang Denk
2021-11-17 16:15                                       ` Tom Rini
2021-11-18  7:08                                         ` Wolfgang Denk
2021-11-18  9:46                                           ` Wolfgang Denk
2021-11-18 14:51                                             ` Tom Rini
2021-11-18 16:29                                           ` Tom Rini
2021-11-18 19:04                                             ` Wolfgang Denk
2021-11-18 19:54                                               ` Tom Rini
2021-11-19 12:30                                                 ` Michal Simek
2021-11-20 15:56                                                   ` Tom Rini

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=20211104113747.GI24579@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=git@xilinx.com \
    --cc=joe.hershberger@ni.com \
    --cc=michael@walle.cc \
    --cc=michal.simek@xilinx.com \
    --cc=rfried.dev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.