[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXjdAZeUl2Dsu4mE@shell.armlinux.org.uk>
Date: Tue, 27 Jan 2026 15:42:57 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Mohd Ayaan Anwar <mohd.anwar@....qualcomm.com>
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 08:27:50PM +0530, Mohd Ayaan Anwar wrote:
> It is using the same SerDes PHY (qcom_dwmac_sgmii_phy_driver).
>
> I added additional debug prints, and I think the crash is due to
> BMSR_ESTATEN not being set in GMAC_AN_STATUS.
I'm going to submit a patch which fixes the phylink crash - it should
be able to cope with pcs being NULL at the oops site.
> 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.
> Therefore, this check:
> if (readl(spcs->base + GMAC_AN_STATUS) & BMSR_ESTATEN) {
> __set_bit(PHY_INTERFACE_MODE_1000BASEX,
> spcs->pcs.supported_interfaces);
>
> /* Only allow 2500Base-X if the SerDes has support. */
> ret = dwmac_serdes_validate(priv, PHY_INTERFACE_MODE_2500BASEX);
> if (ret == 0)
> __set_bit(PHY_INTERFACE_MODE_2500BASEX,
> spcs->pcs.supported_interfaces);
> }
> fails, and PHY_INTERFACE_MODE_2500BASEX never gets set in
> pcs.supported_interfaces. Pardon my naivete, but does the
> BMSR_ESTATEN bit not being set break some standard?
BMSR_ESTATEN means that the PHY supports register 15, MII_ESTATUS.
This register indicates, for 1G speeds, which medium (BASE-T or BASE-X)
and duplexes are supported by the PHY.
Given that SGMII isn't an 802.3 standard, but an extension to BASE-X,
technically it should still, but given that these are not actually a
PHY, it's not a big problem.
However, what it does mean is that we could handle this differently.
We could remove the check here, and set 1000BASE-X and, if the SerDes
supports it, 2500BASE-X, but we would need
dwmac_integrated_pcs_inband_caps() to indicate that inband is not
supported in these unless ESTATEN is set.
> 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.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists