From: Alexander Dahl <ada@thorsis.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] ARM: at91: sama5d27_som1_ek: populate MAC address from EEPROM
Date: Wed, 23 Jun 2021 08:27:50 +0200 [thread overview]
Message-ID: <YNLUZjlRwdpzGXJj@ada.ifak-system.com> (raw)
In-Reply-To: <42009e22-baf5-6b93-88f7-b62eaf4ae604@pengutronix.de>
Hi,
Am Tue, Jun 22, 2021 at 11:07:17AM +0200 schrieb Ahmad Fatoum:
> Hi,
>
> On 22.06.21 10:35, Alexander Dahl wrote:
> > I just had a short look into u-boot for that board, there's the i2c
> > eeprom set in dts only, and dts is still the old u-boot way, not dts
> > from kernel plus fixups in a separate file. The mac is set in
> > board/atmel/sama5d27_som1_ek/sama5d27_som1_ek.c like this:
> >
> > 87 #define MAC24AA_MAC_OFFSET 0xfa
> > 88
> > 89 #ifdef CONFIG_MISC_INIT_R
> > 90 int misc_init_r(void)
> > 91 {
> > 92 #ifdef CONFIG_I2C_EEPROM
> > 93 at91_set_ethaddr(MAC24AA_MAC_OFFSET);
> > 94 #endif
> > 95 return 0;
> > 96 }
> > 97 #endif
> >
> > What would be the right way for kernel, u-boot, and barebox? Have i2c
> > eeprom defined in dts and an nvmem cell on top like you proposed for
> > barebox now?
>
> Many Linux network drivers already call of_get_mac_address and thus would
> read out a NVMEM cell if available. There aren't too many device trees
> making use of it, but that seems the preferred way going forward.
> (MAC addressed fixed up by bootloader is higher priority though).
>
> In general, I think Linux should not rely more than necessary on firmware.
>
> > Not sure if u-boot can do that (already)?
>
> No idea. grepping "mac-address" shows no nvmem related C code though.
FTR: grepping for "nvmem" in u-boot master matches in dts files and
binding docs only. There seems to be currently no code in u-boot
interpreting those dts nodes at all, no nvmem drivers.
> > But it would
> > still work if only Linux and barebox did it that way, right?
>
> So far, either board code set it, similar to your snippet above:
> eth_register_ethaddr(if_index, mac_addr);
>
> Or NVMEM drivers had a barebox,provide-mac-address = <&phandle_to_netdev ...>
> property and they called eth_register_ethaddr.
>
> The NVMEM binding is the upstream way, so after a device tree sync, even existing
> boards may find themselves with the correct address instead of randomization without
> having to do anything (nvmem cells doesn't override other methods, so no brekage).
Makes sense.
Greets
Alex
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2021-06-23 6:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 8:08 Ahmad Fatoum
2021-06-22 8:35 ` Alexander Dahl
2021-06-22 9:07 ` Ahmad Fatoum
2021-06-23 6:27 ` Alexander Dahl [this message]
2021-09-22 10:54 ` Ahmad Fatoum
2021-10-04 13:10 ` 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=YNLUZjlRwdpzGXJj@ada.ifak-system.com \
--to=ada@thorsis.com \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
/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