[PATCH net] net: stmmac: Skip PHY attach if custom PCS is in use

[PATCH net] net: stmmac: Skip PHY attach if custom PCS is in use

[Zxyan Zhu]

When a platform provides a custom PCS via the pcs_init callback
(e.g., for USXGMII with in-band autoneg), the MAC's phylink_pcs
is already configured. In this case, phylink validates against
the PCS's supported interfaces and manages link state through
the PCS, so no traditional PHY device is needed.

Without this, stmmac_init_phy() falls through to the
no-phy-node path and errors out with "no phy found" when
the DT has no phy-handle for such interfaces.

Skip the PHY attach when priv->hw->phylink_pcs is already set
and no phy-handle is specified in the device tree, allowing
platform PCS implementations to handle the link autonomously.

Fixes: f0ef433fc264 ("net: stmmac: introduce pcs_init/pcs_exit stmmac operations")
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..54c5281e91ab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1346,6 +1346,10 @@ static int stmmac_init_phy(struct net_device *dev)
 		int addr = priv->plat->phy_addr;
 		struct phy_device *phydev;
 
+		/* If a custom PCS is in use, no PHY is needed */
+		if (priv->hw->phylink_pcs)
+			return 0;
+
 		if (addr < 0) {
 			netdev_err(priv->dev, "no phy found\n");
 			return -ENODEV;
-- 
2.34.1

Re: [PATCH net] net: stmmac: Skip PHY attach if custom PCS is in use

[Maxime Chevallier]

Hi,

+Mohd

On 7/22/26 15:19, Zxyan Zhu wrote:
> When a platform provides a custom PCS via the pcs_init callback
> (e.g., for USXGMII with in-band autoneg), the MAC's phylink_pcs
> is already configured. In this case, phylink validates against
> the PCS's supported interfaces and manages link state through
> the PCS, so no traditional PHY device is needed.
> 
> Without this, stmmac_init_phy() falls through to the
> no-phy-node path and errors out with "no phy found" when
> the DT has no phy-handle for such interfaces.
> 
> Skip the PHY attach when priv->hw->phylink_pcs is already set
> and no phy-handle is specified in the device tree, allowing
> platform PCS implementations to handle the link autonomously.

Hmpf this bug again...

There have been multiple attempts at solving this, cf this thread :

https://lore.kernel.org/netdev/E1w66jW-0000000E3qS-23fW@rmk-PC.armlinux.org.uk/

Now, there wasn't any conclusion on that, but I _think_ the proper
solution is to re-apply Russell's original patch (the one in the link above)
and to add this current patch on top of it.

Russell states that this may (will ?) break qcom-ethqos, but OTOH
we're in need for a solution here, and with the pace of PCS-related
work that impacts stmmac, there's going to be a point where we may
need to think about compatibility.

TBF I don't understand the qcom-ethqos issue, maybe Mohd can help
with testing here ?

Maxime

Re: [PATCH net] net: stmmac: Skip PHY attach if custom PCS is in use

[Mohd Ayaan Anwar]

On Wed, Jul 22, 2026 at 03:40:08PM +0200, Maxime Chevallier wrote:
> Hi,
> 
> +Mohd
> 
> On 7/22/26 15:19, Zxyan Zhu wrote:
> > When a platform provides a custom PCS via the pcs_init callback
> > (e.g., for USXGMII with in-band autoneg), the MAC's phylink_pcs
> > is already configured. In this case, phylink validates against
> > the PCS's supported interfaces and manages link state through
> > the PCS, so no traditional PHY device is needed.
> > 
> > Without this, stmmac_init_phy() falls through to the
> > no-phy-node path and errors out with "no phy found" when
> > the DT has no phy-handle for such interfaces.
> > 
> > Skip the PHY attach when priv->hw->phylink_pcs is already set
> > and no phy-handle is specified in the device tree, allowing
> > platform PCS implementations to handle the link autonomously.
> 
> Hmpf this bug again...
> 
> There have been multiple attempts at solving this, cf this thread :
> 
> https://lore.kernel.org/netdev/E1w66jW-0000000E3qS-23fW@rmk-PC.armlinux.org.uk/
> 
> Now, there wasn't any conclusion on that, but I _think_ the proper
> solution is to re-apply Russell's original patch (the one in the link above)
> and to add this current patch on top of it.
> 
> Russell states that this may (will ?) break qcom-ethqos, but OTOH
> we're in need for a solution here, and with the pace of PCS-related
> work that impacts stmmac, there's going to be a point where we may
> need to think about compatibility.
> 
> TBF I don't understand the qcom-ethqos issue, maybe Mohd can help
> with testing here ?
> 

Sure, I can help test out qcom-ethqos and see if and where it breaks.

We could not arrive at a conclusion the last time because I ran out of
options to try and find a proper solution. So if it still breaks, I will
spend some time and brainstorm qcom-ethqos's interaction with the
integrated PCS, again.

	Ayaan