Re: [PATCH RFC net-next v2 0/7] net: stmmac: improve PCS support

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

On Fri, Mar 06, 2026 at 01:16:47AM +0530, Mohd Ayaan Anwar wrote:
> Hi Russell,
> On Wed, Mar 04, 2026 at 08:47:36AM +0000, Russell King (Oracle) wrote:
> > Resending this as the original RFC now conflicts with net-next.
> > 
> > This series is the next of the three part series sorting out the PCS
> > support in stmmac, building on part 2, which was posted yesterday:
> > 
> > 	net: stmmac: qcom-ethqos: further serdes reorganisation
> > 
> > Similar patches have been posted previously. This series does away with
> > the common SerDes PHY support, instead using a flag to indicate whether
> > 2500Mbps mode is supported (STMMAC_FLAG_SERDES_SUPPORTS_2500M.) At this
> > time, I have no plans to resurect the common SerDes PHY support - the
> > generic PHY layer implementations are just too random to consider that,
> > and I certainly do not want the extra work of fixing that.
> > 
> > I've also changed the last patch which prints warnings when qcom-ethqos
> > changes the PCS state - this will now indicate in a readable form
> > whether the ANE or SGMRAL bits have changed state, rather than having
> > to refer back to the definitions in the code or the databook.
> > 
> > I am hoping that - subject to this working for qcom-ethqos - we can
> > drop this last patch in the final submission, along with the
> > dwmac_ctrl_ane() and ethqos_pcs_set_inband() functions and associated
> > definitions. This will also mean that stmmac will finally be driving
> > the PCS correctly from a phylink point of view.
> > 
> 
> Apologies for the delay in sharing test results. I had some board issues
> to work through.
> 
> I applied your previous RFC series on top of the two qcom-ethqos/serdes
> cleanup series and have the following results to report for the QCS9100
> Ride R3 board (AQR115C PHY):
> 
>   - Link up at 2.5G, 1G, and 100M is fine (phylink logs below). The PCS
>     link takes a moment to stabilize, but after that it's stable.

Has it always taken a moment to stabilise? Note that the ANE changes
will trigger a re-exchange of SGMII in-band, which is why you see
the PCS link go down and back up after the "ANE 0->1" message.

I do notice:

	qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter

which is a symptom that a clock is missing. There's been some recent
patches merged into net-next which changes this:

2cd70e3968f5 net: stmmac: Defer VLAN HW configuration when interface is down
bd7ad51253a7 net: stmmac: Fix VLAN HW state restore
e38200e361cb net: stmmac: Improve double VLAN handling
35dfedce442c net: stmmac: Fix error handling in VLAN add and delete paths

please indicate whether you have these applied.

>   - No data path issues at these speeds either.

Great.

>   - The warning ("PCS configuration changed from phylink by glue;
>     ANE 0 -> 1") is observed when the link comes up at 1G/100M.

That's currently expected, because phylink thinks we're using PHY
mode (where it's in charge of reading the PHY and telling the MAC
what's going on) rather than using inband. This is something that
will need to be addressed later.

>   - I did find one issue: the data path breaks when the link speed
>     changes from 2.5G to 1G or 100M. Notably, this is not consistently
>     reproducible, and the issue persists even after *dropping* this
>     series and the two qcom-ethqos/serdes cleanup series, so it appears
>     to be pre-existing. I am trying to debug this separately.

I think you added some debug between the logs that you've provided
below, which I'll take as not significant.

I think what's happening is the PHY's SGMII exchange times out, but
because you're enabling SGMII with AN at the PCS, the PCS is wanting
that to complete, and that never happens. I suspect if you unplug and
replug the cable after its switched into 1G mode, it may work. However,
I need to check whether AQR115C does this "AN bypass" thing.

That said, as we're using outband mode, phylink will call
phy_config_inband() with LINK_INBAND_DISABLE. This should disable
inband mode at the PHY, but from your logs I see evidence that it
hasn't. I think that may be because the AQR needs something more than
writing the VEND1_GLOBAL_CFG_* registers for that to take effect.

One of the hacks I have locally for an AQR113C on a SFP module which
uses 10GBASE-R with rate matching is the following in
aqr_gen4_config_init() to allow it to work with MACs that only support
up to 2.5G:

        phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, MDIO_CTRL1, MDIO_CTRL1_LPOWER);
        mdelay(10);
        phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x31a, 2);
        phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CFG_10M,
                      VEND1_GLOBAL_CFG_AUTONEG_ENA |
                      VEND1_GLOBAL_CFG_SERDES_MODE_SGMII);
        phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CFG_100M,
                      VEND1_GLOBAL_CFG_AUTONEG_ENA |
                      VEND1_GLOBAL_CFG_SERDES_MODE_SGMII);
        phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CFG_1G,
                      VEND1_GLOBAL_CFG_AUTONEG_ENA |
                      VEND1_GLOBAL_CFG_SERDES_MODE_SGMII);
        phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_CFG_2_5G,
                      VEND1_GLOBAL_CFG_AUTONEG_ENA |
                      VEND1_GLOBAL_CFG_SERDES_MODE_OCSGMII);
        phy_clear_bits_mmd(phydev, MDIO_MMD_VEND1, MDIO_CTRL1,
                           MDIO_CTRL1_LPOWER);

I have this immediately after "priv->wait_on_global_cfg = true;"

This reprograms the vendor provisioning so that we use 2500BASE-X
for 2.5G and SGMII for 1G and below with AN enabled. Note placing
the PHY into low-power mode while doing this - this causes firmware
to re-read when exiting low-power mode. I wonder if that's required
in aqr_gen2_config_inband() - but that will cause the link to go
down.

Note that VEND1_GLOBAL_CFG_AUTONEG_ENA enables inband signalling on
the link.

With the above, you should be able to test various scenarios with
the PHY - and changing your provisioned 10M configuration will likely
get 10M speeds working.

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