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.si...@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.si...@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....@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.
Thanks,
Michal
