eth_nxp_enet : get mac address from eeprom

[mspeder]

Is your enhancement proposal related to a problem? Please describe. When used in production environment all devices must have different "real" mac addresses. Using a random (or derived from device id) mac address is not acceptable nor is using a common fixed mac supplied by the device tree thru local_mac_address property. It is very common to use an eeprom to provide the mac address.

Describe the solution you'd like We need a way to provide mac address using an eeprom with eth_nxp_enet, like we already have on other ethernet drivers like eth_sam_gmac.

Similar to the eth_sam_gmac, configuration would be controlled by new optional device tree properties : ETH_NXP_ENET_MAC_I2C_EEPROM, ETH_NXP_ENET_MAC_I2C_ADDRESS.

Thanks in advance for your feedback. If that's ok I can submit a PR.

[yuecelm]

did you tried nxp,fused-mac? there is also the option to use nxp,unique-mac in order to get a static mac address:

&enet_mac {
        /delete-property/ zephyr,random-mac-address;
        //nxp,fused-mac; // not working, seems not be available on mimxrt1050_evk board
        nxp,unique-mac;
};

further docs: https://docs.zephyrproject.org/latest/build/dts/api/bindings/ethernet/nxp,enet-mac.html

[yuecelm]

maybe you also need to cherry pick this commit: https://github.com/zephyrproject-rtos/zephyr/commit/931628a78a52ac1d10b562761896cd0aa4bfda8b

[mspeder]

@yuecelm thanks for the feedback. I agree fused mac would have been a good solution, but unfortunately not existing on my MK64 SoC, where there is no such concept of fuses. "unique-mac" is the solution I was referring to when I mentioned "derived from device id". Unfortunately this generates a fake mac using the device id. As mentioned in the doc, while this can be useful for testing or demos, this is not a valid option for production where we need "real" addresses.

[henrikbrixandersen]

Instead of adding Kconfig options for this, I'd like to see Ethernet drivers move towards the devicetree solution outlined here: https://github.com/zephyrproject-rtos/zephyr/pull/74835#discussion_r1651559112

[mspeder]

@henrikbrixandersen thanks for the feedback. I totally agree that a pure device tree solution would be more elegant.

I see two options in the thread you mentioned. 1/ the simple mac-eeprom = <&eeprom 0x00> mentioned by @pdgendt 2/ the more complex with with nvmem-cells

I didn't find any usage of this nvmem-cells approach elsewhere in zephyr. Does it make any assumption on the kind of underlying storage ? Not sure to understand how do I know which api to call to access this (as opposed to the already existing and explicit eeprom api implied by the first syntax) ?

Since this need is going to be replicated in multiple eth drivers, it looks like some standardisation would be beneficial. As I am new to the zephyr community, I am not sure how do we reach some kind of common approach ?

Also adding @decsny to this discussion, since he made most of the recent contributions to this part of the eth_nxp_driver.

[decsny]

"unique-mac" is the solution I was referring to when I mentioned "derived from device id". Unfortunately this generates a fake mac using the device id. As mentioned in the doc, while this can be useful for testing or demos, this is not a valid option for production where we need "real" addresses.

I am glad to know the doc of that property was useful