Thread (5 messages) 5 messages, 4 authors, 2026-03-05

RE: [PATCH net] net: enetc: fix fallback PHY address handling and do not skip setting for addr 0

From: Wei Fang <wei.fang@nxp.com>
Date: 2026-03-05 02:10:34
Also in: lkml, netdev

On Tue, Mar 03, 2026 at 06:30:47PM +0800, Wei Fang wrote:
quoted
The current netc_get_phy_addr() implementation falls back to PHY address
0 when the "mdio" node or any PHY child node is missing. On i.MX95, this
causes failures when a real PHY is actually assigned address 0 and is
managed through the EMDIO interface, the bit 0 of phy_mask becomes set,
leading imx95_enetc_mdio_phyaddr_config() to return an error, and the
netc_blk_ctrl driver probe subsequently fails. Fix this by returning
-ENODEV when neither an "mdio" node nor any PHY node is present.

Given that some platforms may use PHY address 0 (I suppose the PHY may
not treat address 0 as a broadcast address or default response address).
It is possible for some boards to connect multiple PHYs to a single
ENETC MAC, for example:

  - a SGMII PHY with a non-zero address (selected via DTS_A)
  - a RGMII PHY with address 0 (selected via DTS_B)

For the case where the ENETC port MDIO is used to manage the PHY, when
switching from DTS_A to DTS_B via soft reboot, LaBCR[MDIO_PHYAD_PRTAD]
must be updated to 0 because the NETCMIX block is not reset during soft
reboot. However, the current driver explicitly skips configuring address
0, which leaves the hardware in an inconsistent state.

Therefore, remove the special-case skip of PHY address 0 so that valid
configurations using address 0 are properly supported.
Please can you break this patch up. I've not looked at all the details, but:
quoted
diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
quoted
index 7fd39f895290..92a0f824dae7 100644
--- a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
+++ b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
@@ -333,11 +333,13 @@ static int netc_get_phy_addr(struct device_node
*np)
quoted
 	mdio_node = of_get_child_by_name(np, "mdio");
 	if (!mdio_node)
-		return 0;
+		return -ENODEV;

 	phy_node = of_get_next_child(mdio_node, NULL);
-	if (!phy_node)
+	if (!phy_node) {
+		err = -ENODEV;
 		goto of_put_mdio_node;
+	}
This looks like it could be one patch.
quoted
@@ -423,6 +425,9 @@ static int imx95_enetc_mdio_phyaddr_config(struct
platform_device *pdev)
quoted
 			addr = netc_get_phy_addr(gchild);
 			if (addr < 0) {
+				if (addr == -ENODEV)
+					continue;
+
This seems like a patch when combined with the if (addr < 0) hunk
below.
This change should be included in the same patch as the one mentioned above.
The change above changed the return value, so the call point also needs to be
modified.
quoted
@@ -433,12 +438,6 @@ static int imx95_enetc_mdio_phyaddr_config(struct
platform_device *pdev)
quoted
 				return -EINVAL;
 			}

-			/* The default value of LaBCR[MDIO_PHYAD_PRTAD ] is
-			 * 0, so no need to set the register.
-			 */
-			if (!addr)
-				continue;
-
This can be a patch, along with the same delete in the last section of
this patch.

The point of having lots of small patches is that it makes to find
regressions. If something does break, git bisect will quickly tell you
which patch is was. The less a patch does, the more git bisect is
useful.
Sounds good, I will split this patch into two parts.
 
---
pw-bot: cr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help