[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXsLyb+x76/WaXcs@oss.qualcomm.com>
Date: Thu, 29 Jan 2026 12:57:05 +0530
From: Mohd Ayaan Anwar <mohd.anwar@....qualcomm.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
linux-phy@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Neil Armstrong <neil.armstrong@...aro.org>, netdev@...r.kernel.org,
Paolo Abeni <pabeni@...hat.com>, Vinod Koul <vkoul@...nel.org>
Subject: Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and
inband goodies
On Tue, Jan 27, 2026 at 03:42:57PM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 27, 2026 at 08:27:50PM +0530, Mohd Ayaan Anwar wrote:
> > During pcs_init, BIT(8) of GMAC_AN_STATUS is 0:
> > [ 7.985913] [DBG] GMAC_AN_STATUS = 8
>
> Hmm. This means that your hardware doesn't support TBI or RTBI modes
> (which is what the dwmac core uses for BASE-X) and what it's actually
> offering is an up-clocked Cisco SGMII implementation.
>
> With AN disabled, this is compatible with 2500BASE-X implementations
> that do not require AN.
Yes, this hardware implements what some vendors call OCSGMII (i.e.
2500BASE-X without in-band signalling).
> > I also tried enabling comma detect during dwmac_integrated_pcs_config,
> > but I am still seeing the Tx timeouts. I remember that when I had
> > tested the patches in October (without the SerDes driver changes),
> > the link state used to flap, but the data path became functional
> > after the link stabilized.
>
> I wonder whether the SerDes needs to be calibrated after the link has
> come up and the clocks configured. phy_calibdate() will re-invoke the
> programming of the SerDes, so you could try adding that at the bottom
> of ethqos_configure_sgmii():
>
> return phy_calibrate(priv->plat->serdes);
>
> which will do the calibration after the clocks have been set, and see
> whether that stabilises the link.
Somehow booting up with a 2.5G link is more unstable after adding this.
Behaviour at 1G is pretty similar. I kept comma detection disabled
during these tests.
I was thinking about the "good" sequence (i.e., the current net-next
tree):
-> phylink_up
-> mac_link_up
-> fix_mac_speed
-> SerDes configured via phy_set_speed
-> stmmac_pcs_ctrl_ane(priv, enable/disable, 0)
Please let me know if you want me to try any other experiments.
Maybe I need to do some more testing after playing around with the
sequence followed by this series?
Ayaan
Powered by blists - more mailing lists