
On 6/11/23 David Antliff wrote:
On 6/11/23 Sean Anderson wrote: > On 6/11/23 23:25, David Antliff wrote: > > On 11/23/22 Sean Anderson wrote: > >> On 11/22/22 20:23, David Antliff wrote:
[snip]
> > From a little debugging, I see that the call in eth-uclass.c around line 515 returns a null pointer: > > > > p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN); > > This is expected. If (local-)mac-address is defined then nvmem_cell_get_by_name/nvmem_cell_read will not be used.
This was the hint I needed to solve this - thank you.
Turns out that PetaLinux (sigh) was injecting the ff:ff:ff... MAC address into the device-tree build, which is where local-mac-address was coming from. As you mentioned, and as I can now see in eth-uclass.c, the NVMEM subsystem isn't used if either of these nodes are defined.
Although PetaLinux's own config insists on setting a MAC address, I was able to set it to a blank string which results in a DT node, but with no value. This seems sufficient to get past the checks for "{local-,}mac-address" and call the NVMEM functions instead.
project-spec/configs/config:
CONFIG_SUBSYSTEM_ETHERNET_PSU_ETHERNET_3_MAC=""
For anyone else coming across this, here's my final DT snippet:
axi { i2c@ff030000 { i2c-mux@74 { i2c@0 { eeprom@54 { #address-cells = <1>; #size-cells = <1>; compatible = "atmel,24c128"; reg = <0x54>;
mac_address: mac-address@23 { reg = <0x23 6>; }; }; }; }; };
ethernet@ff0e0000 { nvmem-cells = <&mac_address>; nvmem-cell-names = "mac-address"; }; };
Also, it appears that 'compatible = ... , "nvmem-cells";' on the EEPROM node is not required.
Thank you for the hints!
-- David.