Re: [PATCH net-next 0/8] net: stmmac: improve PCS support

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Mar 16, 2026 at 05:15:53AM +0530, Mohd Ayaan Anwar wrote:
> Hi Russell,
> 
> 1. On QCS9100 Ride R3, the mdio subnode is only defined for ethernet0
>    (see lemans-ride-ethernet-aqr115c.dtsi). ethernet1 uses ethernet0's
>    MDIO bus, so plat_dat->mdio_bus_data is NULL for ethernet1. Therefore,
>    we get:
> 	[    9.205979] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
> 	[    9.221071] pc : qcom_ethqos_probe+0xc4/0x478 [dwmac_qcom_ethqos]
> 	[    9.221078] lr : qcom_ethqos_probe+0x7c/0x478 [dwmac_qcom_ethqos]
> 	[    9.221080] sp : ffff800081aa37f0
> 	[    9.221081] x29: ffff800081aa3860 x28: ffffcf84de69cfe8 x27: 0000000000000001
> 	[    9.221084] x26: 0000000000000000 x25: ffff0000b4577c80 x24: ffff0000818fd010
> 	[    9.221087] x23: ffff000ec7057628 x22: 0000000000000000 x21: ffffcf84ca2ce028
> 	[    9.221089] x20: ffff0000818fd000
> 	[    9.236975]  x19: ffff0000b3301740 x18: 00000000ffffffff
> 	[    9.236977] x17: 0000000000000000 x16: ffffcf84dc4a5448 x15: ffff0000b3301ec5
> 	[    9.236980] x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
> 	[    9.236982] x11: 7f7f7f7f7f7f7f7f x10: 00000000001305b0 x9 : 0000000000000000
> 	[    9.236984] x8 : ffff0000b3301780 x7 : 0000000000000000 x6 : 000000000000003f
> 	[    9.236986] x5 : 0000000000000040 x4 : 0000000000000000 x3 : ffff0000818fd210
> 	[    9.236988] x2 : 0000000000000017 x1 : 0000000000000000 x0 : 0000000000000001
> 	[    9.236991] Call trace:
> 	[    9.236991]  qcom_ethqos_probe+0xc4/0x478 [dwmac_qcom_ethqos] (P)
> 	[    9.236994]  platform_probe+0x5c/0xac
> 				...
> 	[    9.343300] Code: 910a7000 f9400b21 f9010320 52800020 (39005420)
> 	[    9.343302] ---[ end trace 0000000000000000 ]---
> 
>    I added the following workaround:
> 	--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> 	+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> 	@@ -765,7 +767,10 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> 			case PHY_INTERFACE_MODE_SGMII:
> 					ethqos->configure_func = ethqos_configure_sgmii;
> 					plat_dat->mac_finish = ethqos_mac_finish_serdes;
> 	-               plat_dat->mdio_bus_data->default_an_inband = true;
> 	+               if (plat_dat->mdio_bus_data)
> 	+                       plat_dat->mdio_bus_data->default_an_inband = true;
> 	+               else
> 	+                       dev_err(dev, "plat_dat->mdio_bus_data is NULL");
> 					break;
> 			default:
> 					dev_err(dev, "Unsupported phy mode %s\n",

This means we need to move default_an_inband out of mdio_bus_data.

> 
> 2. After working around issue 1, I hit the following:
> 	[   27.822907] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> 	[   27.831944] Mem abort info:
> 	[   27.834832]   ESR = 0x0000000086000006
> 	[   27.838693]   EC = 0x21: IABT (current EL), IL = 32 bits
> 	[   27.844163]   SET = 0, FnV = 0
> 	[   27.847320]   EA = 0, S1PTW = 0
> 	[   27.850563]   FSC = 0x06: level 2 translation fault
> 	[   27.855587] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000134b1c000
> 	[   27.862212] [0000000000000000] pgd=080000010185c403, p4d=080000010185c403, pud=0800000134884403, pmd=0000000000000000
> 	[   27.873107] Internal error: Oops: 0000000086000006 [#1]  SMP
> 	[   28.001619] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
> 	[   28.008853] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> 	[   28.016001] pc : 0x0
> 	[   28.018259] lr : phylink_pcs_an_restart+0x50/0x5c
> 	[   28.023092] sp : ffff8000869fb900
> 				...
> 	[   28.185967] ---[ end trace 0000000000000000 ]---
> 
>    This occurs due to pl->pcs->ops->pcs_an_restart being NULL. I added
>    the following workaround:
> 	--- a/drivers/net/phy/phylink.c
> 	+++ b/drivers/net/phy/phylink.c
> 	@@ -1026,7 +1026,8 @@ static void phylink_pcs_an_restart(struct phylink *pl)
> 			if (pl->pcs && linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
> 							 pl->link_config.advertising) &&
> 			    phy_interface_mode_is_8023z(pl->link_config.interface) &&
> 	-		    phylink_autoneg_inband(pl->act_link_an_mode))
> 	+		    phylink_autoneg_inband(pl->act_link_an_mode) &&
> 	+		    pl->pcs->ops->pcs_an_restart)
> 					pl->pcs->ops->pcs_an_restart(pl->pcs);
> 	 }

Gah, should've added a pcs_an_restart() implementation.

> 3. With the recent VLAN filter changes in net-next, ndo_open takes a long
>    time to complete as vlan_restore_hw_rx_fltr() tries to write filters
>    for all 32 indices. This board previously timed out once, but now
>    times out for each index. This is a separate issue unrelated to this
>    series but I added the following workaround to rule out any timing
>    issues.
> 	--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c
> 	+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c
> 	@@ -158,7 +158,8 @@ static void vlan_restore_hw_rx_fltr(struct net_device *dev,
> 
> 			/* Extended Rx VLAN Filter Enable */
> 			for (i = 0; i < hw->num_vlan; i++)
> 	-               vlan_write_filter(dev, hw, i, hw->vlan_filter[i]);
> 	+               if (hw->vlan_filter[i])
> 	+                       vlan_write_filter(dev, hw, i, hw->vlan_filter[i]);
> 	 }
> 
> 	 static void vlan_update_hash(struct mac_device_info *hw, u32 hash,

This problem needs solving, and I suspect we need more than the
loopback here. It needs detailed information about your hardware
design, and comes down to the missing receive clock. stmmac is
unusual that missing clocks affect the accessibility of the host.

> With the above workarounds in place, 2.5G works fine, but 1G (and 100M)
> do not. With the RFC v1 series, only the 2.5G->1G speed change was
> broken. With this series, the link does not come up at 1G at all.

This will be because we're not attaching any PHYs when phylink is
being told to operate in 2500BASE-X with inband, since it thinks
that's the media. That, and, because stmmac has a long history, it
needed a special phylink_expects_phy() check added in stmmac_init_phy()
which his what prevents the PHY being attached.

One workaround for this would be to specify SGMII in DT rather than
2500base-X. However, that's not a solution for mainline.

I'm going to have to have another think about this... stmmac is
beginning to get too painful to solve this problem. As I've said
elsewhere, in hind sight, I wish I had blocked dwmac-qcom-ethqos from
being merged because of it's direct fiddling with the integrated PCS.

I'm beginning to wonder whether stmmac can ever be sorted out, or
whether the driver has gone too far, and the best thing now is to
totally decouple it from phylink.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!