[PATCH] ARM: at91: sama5d27_som1_ek: populate MAC address from EEPROM

[Alexander Dahl]

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