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

[Mohd Ayaan Anwar]

On Mon, Mar 16, 2026 at 01:11:23AM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 16, 2026 at 05:15:53AM +0530, Mohd Ayaan Anwar wrote:
> > 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.

I tried finding more details about the hardware implementation and
it appears that the receive clock is sourced from the SerDes PHY.

As an experiment, the following in __stmmac_open() avoids the issue
on this board:

	qcom_ethqos_set_sgmii_loopback(ethqos, true);
	stmmac_vlan_restore(priv);
	qcom_ethqos_set_sgmii_loopback(ethqos, false);

What would be the correct way to handle this? Right now, SGMII
loopback remains enabled from qcom_ethqos_probe() up to
stmmac_mac_finish().

	Ayaan