-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dts: ethernet: rework how we deal with mac-address setting #24651
Conversation
All checks passed. checkpatch (informational only, not a failure)
Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
mac_addr[3] = entropy >> 8; | ||
mac_addr[4] = entropy >> 16; | ||
/* Locally administered, unicast */ | ||
mac_addr[5] = ((entropy >> 0) & 0xfc) | 0x02; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The liteeth driver seems to have set the LAA bit to wrong byte earlier.
drivers/ethernet/eth_mcux.c
Outdated
#if defined(CONFIG_ETH_MCUX_0_UNIQUE_MAC) || \ | ||
defined(CONFIG_ETH_MCUX_1_UNIQUE_MAC) | ||
#if !DT_INST_NODE_HAS_PROP(0, local_mac_address) || \ | ||
DT_HAS_NODE(DT_DRV_INST(1)) && !DT_INST_NODE_HAS_PROP(1, local_mac_address) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does generating eth0 depend on instance 1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because generate_eth1_unique_mac calls generate_eth0_unique_mac. And we technically could have a case in which local-mac-address is set on inst0 and not on inst1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments that I'd like considered. If they don't make sense I'll remove the request changes, though I am specifically concerned about a change in behavior to local-mac-address = [000000000000]
in existing overlays.
Rather than having each driver have its own slightly different way of generating a random mac address, add a helper function that they all can call so we do it one way. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add definition of zephyr,random-mac-address property that conveys to a driver to utilize a random MAC address if the driver supports this feature. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Utilize the devicetree property "zephyr,random-mac-address" to determine if a driver should use a random mac address and remove the associated Kconfig options that enabled this feature. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Move from a Kconfig to select/initialize the MAC address to using the "local-mac-address" property in devicetree. If the property is set the drivers will initialize the mac-address from the devicetree (unless the mac address is all 0's). The MAC address might get overwritten by either a driver specific means or by the setting of "zephyr,random-mac-address" in the devicetree. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Instead of having a Kconfig property, if there is no local-mac-address property in the devicetree than we'll generate a unique MAC address based on unique ID registers on the SoC. We remove the local-mac-address properties in the SoC dtsi files to match the default behavior that existed before (ie, unique MAC address) Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Rework the ethernet drivers to determine how they set the mac-address. In the majority of cases with just utilize devicetree and a combination of 'local-mac-address' property and 'zephyr,random-mac-address' property.