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

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

[Wei Fang]

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.

Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Closes: https://lore.kernel.org/all/7825188.GXAFRqVoOG@steina-w
Fixes: 6633df05f3ad ("net: enetc: set the external PHY address in IERB for port MDIO usage")
Fixes: 50bfd9c06f0f ("net: enetc: set external PHY address in IERB for i.MX94 ENETC")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 .../ethernet/freescale/enetc/netc_blk_ctrl.c  | 24 ++++++++-----------
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
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)
 
 	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;
+	}
 
 	err = of_property_read_u32(phy_node, "reg", &addr);
 	if (err)
@@ -423,6 +425,9 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
 
 			addr = netc_get_phy_addr(gchild);
 			if (addr < 0) {
+				if (addr == -ENODEV)
+					continue;
+
 				dev_err(dev, "Failed to get PHY address\n");
 				return addr;
 			}
@@ -433,12 +438,6 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
 				return -EINVAL;
 			}
 
-			/* The default value of LaBCR[MDIO_PHYAD_PRTAD ] is
-			 * 0, so no need to set the register.
-			 */
-			if (!addr)
-				continue;
-
 			switch (bus_devfn) {
 			case IMX95_ENETC0_BUS_DEVFN:
 				netc_reg_write(priv->ierb, IERB_LBCR(0),
@@ -578,16 +577,13 @@ static int imx94_enetc_mdio_phyaddr_config(struct netc_blk_ctrl *priv,
 
 	addr = netc_get_phy_addr(np);
 	if (addr < 0) {
+		if (addr == -ENODEV)
+			return 0;
+
 		dev_err(dev, "Failed to get PHY address\n");
 		return addr;
 	}
 
-	/* The default value of LaBCR[MDIO_PHYAD_PRTAD] is 0,
-	 * so no need to set the register.
-	 */
-	if (!addr)
-		return 0;
-
 	if (phy_mask & BIT(addr)) {
 		dev_err(dev,
 			"Find same PHY address in EMDIO and ENETC node\n");
-- 
2.34.1

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

[Clark Wang]

> 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.
> 
> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Closes: https://lore.kernel.org/all/7825188.GXAFRqVoOG@steina-w
> Fixes: 6633df05f3ad ("net: enetc: set the external PHY address in IERB for
> port MDIO usage")
> Fixes: 50bfd9c06f0f ("net: enetc: set external PHY address in IERB for i.MX94
> ENETC")
> Signed-off-by: Wei Fang <wei.fang@nxp.com>

Reviewed-by: Clark Wang <xiaoning.wang@nxp.com>

Thanks!
Clark Wang

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

[Alexander Stein]

Am Dienstag, 3. März 2026, 11:30:47 CET schrieb Wei Fang:
> 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.
> 
> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Closes: https://lore.kernel.org/all/7825188.GXAFRqVoOG@steina-w
> Fixes: 6633df05f3ad ("net: enetc: set the external PHY address in IERB for port MDIO usage")
> Fixes: 50bfd9c06f0f ("net: enetc: set external PHY address in IERB for i.MX94 ENETC")
> Signed-off-by: Wei Fang <wei.fang@nxp.com>

Thanks,
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>

> ---
>  .../ethernet/freescale/enetc/netc_blk_ctrl.c  | 24 ++++++++-----------
>  1 file changed, 10 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
> 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)
>  
>  	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;
> +	}
>  
>  	err = of_property_read_u32(phy_node, "reg", &addr);
>  	if (err)
> @@ -423,6 +425,9 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
>  
>  			addr = netc_get_phy_addr(gchild);
>  			if (addr < 0) {
> +				if (addr == -ENODEV)
> +					continue;
> +
>  				dev_err(dev, "Failed to get PHY address\n");
>  				return addr;
>  			}
> @@ -433,12 +438,6 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
>  				return -EINVAL;
>  			}
>  
> -			/* The default value of LaBCR[MDIO_PHYAD_PRTAD ] is
> -			 * 0, so no need to set the register.
> -			 */
> -			if (!addr)
> -				continue;
> -
>  			switch (bus_devfn) {
>  			case IMX95_ENETC0_BUS_DEVFN:
>  				netc_reg_write(priv->ierb, IERB_LBCR(0),
> @@ -578,16 +577,13 @@ static int imx94_enetc_mdio_phyaddr_config(struct netc_blk_ctrl *priv,
>  
>  	addr = netc_get_phy_addr(np);
>  	if (addr < 0) {
> +		if (addr == -ENODEV)
> +			return 0;
> +
>  		dev_err(dev, "Failed to get PHY address\n");
>  		return addr;
>  	}
>  
> -	/* The default value of LaBCR[MDIO_PHYAD_PRTAD] is 0,
> -	 * so no need to set the register.
> -	 */
> -	if (!addr)
> -		return 0;
> -
>  	if (phy_mask & BIT(addr)) {
>  		dev_err(dev,
>  			"Find same PHY address in EMDIO and ENETC node\n");
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

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

[Andrew Lunn]

On Tue, Mar 03, 2026 at 06:30:47PM +0800, Wei Fang wrote:
> 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:

> diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
> 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)
>  
>  	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.

> @@ -423,6 +425,9 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
>  
>  			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.

> @@ -433,12 +438,6 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
>  				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.

    Andrew

---
pw-bot: cr

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

[Wei Fang]

> On Tue, Mar 03, 2026 at 06:30:47PM +0800, Wei Fang wrote:
> > 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:
> 
> > diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
> b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
> > 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)
> >
> >  	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.
> 
> > @@ -423,6 +425,9 @@ static int imx95_enetc_mdio_phyaddr_config(struct
> platform_device *pdev)
> >
> >  			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.

> 
> > @@ -433,12 +438,6 @@ static int imx95_enetc_mdio_phyaddr_config(struct
> platform_device *pdev)
> >  				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