[PATCH] net: uclass: Save ethernet MAC address when generated
Michal Simek
michal.simek at xilinx.com
Thu Nov 4 12:18:46 CET 2021
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 at 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 at 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 at 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?
Thanks,
Michal
More information about the U-Boot
mailing list