eth_nxp_enet_qos_mac: implement the nxp,unique-mac address feature

[theadib]

This implements to generate the MAC address of the device UUID. The UUID is hashed to reduce the size to 3 bytes.
Ideas taken from eth_nxp_enet.c
It does not implement fused MAC address.
Adding dependencies on: HWInfo and CRC

Help needed:
currently I do not know how to register the dependencies in the driver.
That will cause to fail compilation without adding HWInfo and CRC manually.

Adib.

[theadib]

I found the Kconfig where to setup the dependencies.
Should compile without issues now.

[decsny]

could add default y and depends on $(dt_compat_any_has_prop,<compatible string>,<prop>[,<value>])

[pdgendt]

Or maybe default y if $(dt_compat_any_has_prop,<compatible string>,<prop>[,<value>])

[theadib]

Hi, I can make it default "Y" but I struggle to depend on property "nxp,unique-mac" because it parses this as two arguments (the property and the value),
default y if $(dt_compat_any_has_prop,$(DT_COMPAT_NXP_ENET_QOS_MAC),nxp,unique-mac)
This never evaluates to true.

I searched all Kconfig for samples but there is none "grep has_prop Kconfig"

Any advice?
I would just prefer to make default y unconditionally so it can be removed on demand.

[theadib]

I also tested:

DT_PROP_NXP_ENET_QOS_MAC_UNIQUE_MAC := nxp,unique-mac

config ETH_NXP_ENET_QOS_MAC_UNIQUE_MAC_ADDRESS
	bool "Unique MAC address support"
	default y if $(dt_compat_any_has_prop,$(DT_COMPAT_NXP_ENET_QOS_MAC),$(DT_PROP_NXP_ENET_QOS_MAC_UNIQUE_MAC))

which always evaluates to true. :-O

[decsny]

you are closer with the more recent comment, the issue is you need to give the value argument (for a boolean if the value is false the property is still present just invisible). If you are just checking if the property exists and not that it has a certain value, then for a boolean property it will always be true that it exists.

[theadib]

Hello @decsny the value thing is doing the trick. Thanks for pointing out.

DT_PROP_NXP_ENET_QOS_MAC_UNIQUE_MAC := nxp,unique-mac

config ETH_NXP_ENET_QOS_MAC_UNIQUE_MAC_ADDRESS
	bool "Unique MAC address support"
	default y if $(dt_compat_any_has_prop,$(DT_COMPAT_NXP_ENET_QOS_MAC),$(DT_PROP_NXP_ENET_QOS_MAC_UNIQUE_MAC),True)

[dleach02]

when or how does the fused option get used?

[theadib]

I was hoping that NXP has an predefined position in the "OTP" space.
Derek.Snell in discord answered "No" meanwhile (for the MCXN).
"Fused" will fall back to "random" address.
I am not sure if other MCU that use that driver module have such predefined space.

[theadib]

should I remove it then?

[maass-hamburg]

as the enum is only used internally by this driver, it should be removed, can be added if needed later.
You may also want to consider renaming the enum to something with a prefix of the driver like the other structs in that file.

[theadib]

I have done so.

[decsny]

nit, prefer to #else #define nxp_enet_unique_mac(...) as an empty macro above and remove this inline #if from this spot, if that makes sense

[theadib]

I would prefer to keep a nondestructive fallback rather than generate an all zero MAC ADDRESS as in the eth_nxp_enet.c driver.
Even this is not what the user has asked for.
If you agree ...

[decsny]

well, if I understand correctly, this code would never be reached in the case that there is no "unique" address option in the DT. If you are really concern about it maybe the alternative definition would return an error, but that will add an instruction or two to image, but which is fine to me. I found over many cases that having inline #if tends to cause configuration and dependency problems down the line when maintaining the files, and makes it harder to read, that's why I want to avoid it

[theadib]

ok. implemented as empty macro causing lesser #if defined() in the code.