From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <sha@pengutronix.de>
Cc: barebox@lists.infradead.org,
Alexander Shiyan <eagle.alexander923@gmail.com>
Subject: Re: [PATCH 3/3] net: add generic MAC address derivation from machine ID
Date: Thu, 5 Oct 2023 08:56:25 +0200 [thread overview]
Message-ID: <471fed69-a964-dbce-7883-8c0ccf2d33a0@pengutronix.de> (raw)
In-Reply-To: <87e96b20-ae2c-9679-29e4-1c54ee24948a@pengutronix.de>
Hello Sascha,
On 12.09.23 14:34, Ahmad Fatoum wrote:
> On 12.09.23 12:49, Sascha Hauer wrote:
>> I think this deserves a cleanup before we merge this. The original
>> reason to introduce a postenvironment_initcall() for getting the MAC
>> address from nvmem was:
>>
>>> We do this in a very late initcall, because we don't want to enforce a
>>> probe a probe order between nvmem providers and network devices. We
>>> can't do it at randomization time, because we need to fixup Ethernet mac
>>> addresses, even when barebox itself doesn't ifup the netdev.
>>
>> I think we should have one centralized function that retrieves the MAC
>> address for an ethernet device. That should be called when we actually
>> need that MAC address, so once in net_new() and once at of_fixup time.
>>
>> Right now the behaviour is inconsistent with regard to random MAC
>> addresses. Currently we propagate the random MAC address to the Linux
>> device tree when we use ethernet in barebox, but we don't propagate it
>> when we do not use ethernet in barebox. We should decide what the
>> desired behaviour is and do it consistently regardless if we use
>> ethernet in barebox or not. This could be cleaned up along the way.
>
> Randomized MAC addresses are a necessary evil when barebox needs to do
> networking and doesn't have a stable address. If we have a stable address,
> we shouldn't randomize.
>
> Fixing up a randomized MAC address is a lesser evil than having different
> MAC addresses for barebox and Linux. If we don't need a MAC address in barebox,
> we shouldn't generate a random one just to fix it up.
>
> If we have a stable address, we should tell Linux about it.
>
> That's the logic of the current code and it's sensible to me. Why change it?
We have had two boards trying to add something similar in the last couple of
months. I still need your input here on how to proceed.
Thanks,
Ahmad
>
> Cheers,
> Ahmad
>
>>
>> Sascha
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2023-10-05 6:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 15:59 [PATCH 1/3] common: machine_id: support deriving app specific UUIDs Ahmad Fatoum
2023-09-11 15:59 ` [PATCH 2/3] net: import Linux eth_addr_inc/dec/add helpers Ahmad Fatoum
2023-09-11 15:59 ` [PATCH 3/3] net: add generic MAC address derivation from machine ID Ahmad Fatoum
2023-09-12 10:49 ` Sascha Hauer
2023-09-12 12:34 ` Ahmad Fatoum
2023-10-05 6:56 ` Ahmad Fatoum [this message]
2023-10-06 11:59 ` Sascha Hauer
2023-10-12 14:59 ` Alexander Shiyan
2023-10-13 11:11 ` Sascha Hauer
2023-10-17 9:39 ` Ahmad Fatoum
2023-09-15 15:23 ` Thorsten Scherer
2023-09-21 11:12 ` [PATCH 1/3] common: machine_id: support deriving app specific UUIDs Sascha Hauer
2023-09-22 9:45 ` Sascha Hauer
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=471fed69-a964-dbce-7883-8c0ccf2d33a0@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=eagle.alexander923@gmail.com \
--cc=sha@pengutronix.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