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