lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ