Re: [PATCH net 2/2] net: stmmac: qcom-ethqos: advertise supported SerDes interfaces

[Mohd Ayaan Anwar]

On Fri, Sep 18, 2026 at 02:36:04PM +1000, Thomas Karpiniec wrote:
> On 17/09/2026 6:21 pm, Coia Prant wrote:
> > Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> 于2026年9月17日周四 13:36写道：
> > > On 9/17/26 06:29, Thomas Karpiniec wrote:
> > > > I tested setting STMMAC_FLAG_SERDES_SUPPORTS_2500M on hardware and unfortunately the flag alone doesn't solve the problem.
> > > 
> > > Yeah, but it's still the right first move. Russell planned to do that as well
> 
> > > > I think there are a couple of things missing. stmmac_phylink_setup doesn't use the integrated PCS bitmap to populate config->supported_interfaces, so SGMII is still not advertised to phylink as a usable host interface. Also stmmac_integrated_pcs_init is adding 1000BASE-X unconditionally, which wouldn't be appropriate here.
> > > 
> > > Ok so, the missing bit seems to be that priv->integrated_pcs isn't taken
> > > into account in stmmac_phylink_setup(). This needs to be added then :)
> > > 
> > > Looks like there's also the inband support that needs addressing
> 
> > On the qcom issue: the missing bit seems to be that
> > stmmac_phylink_setup() only looks at priv->hw->xpcs and
> > priv->hw->phylink_pcs, not priv->integrated_pcs. Extending the existing
> > OR to cover the integrated PCS would let qcom-ethqos work without a
> > new get_interfaces() callback.
> Thanks all for the feedback! Including the integrated PCS in
> stmmac_phylink_setup makes sense and I've now confirmed that this works
> end-to-end on my QCA8081 board.
> 
> I've prepared a v2 that replaces the get_interfaces change with two commits:
> one to set STMMAC_FLAG_SERDES_SUPPORTS_2500M in qcom-ethqos, and one to
> include the integrated PCS in config->supported_interfaces
> 
> I reviewed the work that Russell was doing and I see the problem. Both the
> integrated PCS and the ethqos code are configuring in-band negotiation. On
> SGMII this occurs twice - both turn it on - and on 2500BASE-X the PCS
> briefly turns it on before ethqos turns it off. On my board, it finishes in
> the correct state.

Right, I think that was the primary concern at the time. Ideally, ethqos
shouldn't have to touch any PCS setting.

> 
> I have tested cold boot connected at both 1 Gbps and 2.5 Gbps, and
> transitions in both directions. However, this is a slow transition where I
> am physically unplugging the cable.
> 
> I attached kprobes to dwmac_integrated_pcs_config and
> ethqos_fix_mac_speed_sgmii, which are the generic and Qualcomm functions
> leading to ANE configuration. We see this on 1 -> 2.5 Gbps:
> 
> 464.233469 integrated_pcs_config interface=2500BASE-X neg_mode=OUTBAND
> 464.234778 fix_speed interface=2500BASE-X speed=2500
> 
> 2.5 Gbps -> 1 Gbps:
> 
> 279.018122 integrated_pcs_config interface=SGMII neg_mode=OUTBAND
> 279.019708 fix_speed interface=SGMII speed=1000
> 
> During the cable swaps, Linux briefly reasserted carrier at the previous
> speed before the link went down again and came up at the new speed. The log
> contained several PCS Link Down/Up and ANE-complete interrupts. I'm not
> seeing any evidence of churn or link instability once connected.
> 
> Russell's wider change is compelling but affects a much wider range of
> hardware. I believe this targeted fix can work separately.
> 
> I'll post the updated version shortly. Thanks for your time.
> 

Sure, I will share some test results of my own (with v2) in a couple of
days.

	Ayaan