[PATCH net-next v2 0/2] net: ethernet: ti: am65-cpsw: Fix MAC address fetching

[PATCH net-next v2 0/2] net: ethernet: ti: am65-cpsw: Fix MAC address fetching

[Michael Walle]

MAC addresses can be fetched from a NVMEM device. of_get_mac_address()
will return EPROBE_DEFER if that device is not available yet. That
isn't handled correctly by the driver and it will always fall back
to either a random MAC address or it's own "fetch by fuse" method.

Also, if the ethernet (sub)node has a link to the nvmem device,
it will fail to create a device link as the fwnode parameter isn't
populated. That's fixed in the first patch.

Michael Walle (2):
  net: ethernet: ti: am65-cpsw: set fwnode for ports
  net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER

 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 26 +++++++++++++-----------
 1 file changed, 14 insertions(+), 12 deletions(-)

-- 
2.39.5

[PATCH net-next v2 1/2] net: ethernet: ti: am65-cpsw: set fwnode for ports

[Michael Walle]

fwnode needs to be set for a device for fw_devlink to be able to
track/enforce its dependencies correctly. Without this, you'll see error
messages like this when the supplier has probed and tries to make sure
all its fwnode consumers are linked to it using device links:

am65-cpsw-nuss 8000000.ethernet: Failed to create device link (0x180) with supplier ..

Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
---

v2:
 - move of_node_get() into own fixes patch:
   https://lore.kernel.org/netdev/20250414083942.4015060-1-mwalle@kernel.org/

 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 636f4cb66aa1..55a0c37da54c 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2760,7 +2760,7 @@ am65_cpsw_nuss_init_port_ndev(struct am65_cpsw_common *common, u32 port_idx)
 	mutex_init(&ndev_priv->mm_lock);
 	port->qos.link_speed = SPEED_UNKNOWN;
 	SET_NETDEV_DEV(port->ndev, dev);
-	port->ndev->dev.of_node = port->slave.port_np;
+	device_set_node(&port->ndev->dev, of_fwnode_handle(port->slave.port_np));
 
 	eth_hw_addr_set(port->ndev, port->slave.mac_addr);
 
-- 
2.39.5

[PATCH net-next v2 2/2] net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER

[Michael Walle]

of_get_mac_address() might fetch the MAC address from NVMEM and that
driver might not have been loaded. In that case, -EPROBE_DEFER is
returned. Right now, this will trigger an immediate fallback to
am65_cpsw_am654_get_efuse_macid() possibly resulting in a random MAC
address although the MAC address is stored in the referenced NVMEM.

Fix it by handling the -EPROBE_DEFER return code correctly. This also
means that the creation of the MDIO device has to be moved to a later
stage as -EPROBE_DEFER must not be returned after child devices are
created.

Signed-off-by: Michael Walle <mwalle@kernel.org>
---

v2:
 - none

 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 55a0c37da54c..988ce9119306 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2679,7 +2679,9 @@ static int am65_cpsw_nuss_init_slave_ports(struct am65_cpsw_common *common)
 			goto of_node_put;
 
 		ret = of_get_mac_address(port_np, port->slave.mac_addr);
-		if (ret) {
+		if (ret == -EPROBE_DEFER) {
+			goto of_node_put;
+		} else if (ret) {
 			am65_cpsw_am654_get_efuse_macid(port_np,
 							port->port_id,
 							port->slave.mac_addr);
@@ -3561,6 +3563,16 @@ static int am65_cpsw_nuss_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	am65_cpsw_nuss_get_ver(common);
+
+	ret = am65_cpsw_nuss_init_host_p(common);
+	if (ret)
+		goto err_pm_clear;
+
+	ret = am65_cpsw_nuss_init_slave_ports(common);
+	if (ret)
+		goto err_pm_clear;
+
 	node = of_get_child_by_name(dev->of_node, "mdio");
 	if (!node) {
 		dev_warn(dev, "MDIO node not found\n");
@@ -3577,16 +3589,6 @@ static int am65_cpsw_nuss_probe(struct platform_device *pdev)
 	}
 	of_node_put(node);
 
-	am65_cpsw_nuss_get_ver(common);
-
-	ret = am65_cpsw_nuss_init_host_p(common);
-	if (ret)
-		goto err_of_clear;
-
-	ret = am65_cpsw_nuss_init_slave_ports(common);
-	if (ret)
-		goto err_of_clear;
-
 	/* init common data */
 	ale_params.dev = dev;
 	ale_params.ale_ageout = AM65_CPSW_ALE_AGEOUT_DEFAULT;
-- 
2.39.5

Re: [PATCH net-next v2 2/2] net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER

[Andrew Lunn]

> Fix it by handling the -EPROBE_DEFER return code correctly. This also
> means that the creation of the MDIO device has to be moved to a later
> stage as -EPROBE_DEFER must not be returned after child devices are
> created.

I probably would of done this as two patches, but it is O.K. the way
it is.

> 
> Signed-off-by: Michael Walle <mwalle@kernel.org>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net-next v2 0/2] net: ethernet: ti: am65-cpsw: Fix MAC address fetching

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 14 Apr 2025 10:43:34 +0200 you wrote:
> MAC addresses can be fetched from a NVMEM device. of_get_mac_address()
> will return EPROBE_DEFER if that device is not available yet. That
> isn't handled correctly by the driver and it will always fall back
> to either a random MAC address or it's own "fetch by fuse" method.
> 
> Also, if the ethernet (sub)node has a link to the nvmem device,
> it will fail to create a device link as the fwnode parameter isn't
> populated. That's fixed in the first patch.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,1/2] net: ethernet: ti: am65-cpsw: set fwnode for ports
    https://git.kernel.org/netdev/net-next/c/1a377f142e6e
  - [net-next,v2,2/2] net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER
    https://git.kernel.org/netdev/net-next/c/09737cb80b86

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html