Message ID | 20240628080146.49545-1-andrei.simion@microchip.com (mailing list archive) |
---|---|
Headers | show |
Series | Read MAC address through NVMEM for sama7g5ek | expand |
On Fri, Jun 28, 2024, at 10:01, Andrei Simion wrote: > This series proposes to add EEPROM support and reading MAC addresses > through NVMEM (via Devicetree) for sama7g5ek: > - Add in DT bindings document the EEPROM compatibles : > "microchip,24aa025e48" and "microchip,24aa025e64" > - Update to the driver to support "microchip,24aa025e48" and > "microchip,24aa025e64" and adjusting offset for those 24AA025E{48, 64}. > - Added the nodes in devicetree for eeproms where are stored EUI-48 MAC, > and update gmac nodes to read the MAC via devicetree through NVMEM. Can you add an explanation about what this is good for? Do you need to work around broken boot loaders that cannot be updated and that happen to store the MAC address in the EEPROM, or are you proposing this as a generic solution that board developers should actually use? As far as I can tell, even with this logic in place, users are better off just having the boot loader read the EEPROM and storing the MAC address in the in-memory dtb as we do on other platforms. Arnd
On 28.06.2024 11:29, Arnd Bergmann wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Fri, Jun 28, 2024, at 10:01, Andrei Simion wrote: >> This series proposes to add EEPROM support and reading MAC addresses >> through NVMEM (via Devicetree) for sama7g5ek: >> - Add in DT bindings document the EEPROM compatibles : >> "microchip,24aa025e48" and "microchip,24aa025e64" >> - Update to the driver to support "microchip,24aa025e48" and >> "microchip,24aa025e64" and adjusting offset for those 24AA025E{48, 64}. >> - Added the nodes in devicetree for eeproms where are stored EUI-48 MAC, >> and update gmac nodes to read the MAC via devicetree through NVMEM. > > Can you add an explanation about what this is good for? > > Do you need to work around broken boot loaders that cannot be > updated and that happen to store the MAC address in the EEPROM, > or are you proposing this as a generic solution that board > developers should actually use? > > As far as I can tell, even with this logic in place, users > are better off just having the boot loader read the EEPROM > and storing the MAC address in the in-memory dtb as we do > on other platforms. > > Arnd Our boot chain is ROM BOOT -> AT91Bootstrap -> U-Boot -> Linux Kernel. U-Boot is the stage where we set up the MAC address. We can skip U-Boot and use the following boot chain ROM BOOT -> AT91Boostrap -> Linux Kernel. This patch set is useful for this scenario and also for redundancy (if something related with NET/EEPROM fails in U-Boot). Best Regards, Andrei Simion
On Fri, Jun 28, 2024, at 16:06, Andrei.Simion@microchip.com wrote: > On 28.06.2024 11:29, Arnd Bergmann wrote: >> >> As far as I can tell, even with this logic in place, users >> are better off just having the boot loader read the EEPROM >> and storing the MAC address in the in-memory dtb as we do >> on other platforms. > > Our boot chain is ROM BOOT -> AT91Bootstrap -> U-Boot -> Linux Kernel. > U-Boot is the stage where we set up the MAC address. > We can skip U-Boot and use the following boot chain ROM BOOT -> > AT91Boostrap -> Linux Kernel. Right, I can see how that is useful. Can you add that description in the patch? > This patch set is useful for this scenario and also for redundancy (if > something related with NET/EEPROM fails in U-Boot). Not sure if redundancy is what we want the boot loader level ;-) Arnd