On Thu, Nov 04, 2021 at 12:43:11PM +0100, Michal Simek wrote:
On 11/4/21 12:37, Tom Rini wrote:
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).
First of all I didn't know that it was the part of networking pull request because didn't see apply message only reviewed from Ramon.
I would be very surprised this patch to caused your issue. It should be covering something else but that should be debugged.
OK, I don't know why my git bisect run lead to this commit, but I've manually bisected instead this time and found a much more reasonable problematic commit. Sorry for the noise.