netdev - Re: [PATCH net-next] net: pcs: lynx: accept in-band autoneg for 2500base-x

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aSGlSJ1Z_Sjj_Ima@shell.armlinux.org.uk>
Date: Sat, 22 Nov 2025 11:58:00 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Ioana Ciornei <ioana.ciornei@....com>,
	Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Alexander Wilhelm <alexander.wilhelm@...termo.com>
Subject: Re: [PATCH net-next] net: pcs: lynx: accept in-band autoneg for
 2500base-x

On Sat, Nov 22, 2025 at 01:34:33PM +0200, Vladimir Oltean wrote:
> Testing in two circumstances:
> 
> 1. back to back optical SFP+ connection between two LS1028A-QDS ports
>    with the SCH-26908 riser card
> 2. T1042 with on-board AQR115 PHY using "OCSGMII", as per
>    https://lore.kernel.org/lkml/aIuEvaSCIQdJWcZx@FUE-ALEWI-WINX/
> 
> strongly suggests that enabling in-band auto-negotiation is actually
> possible when the lane baud rate is 3.125 Gbps.
> 
> It was previously thought that this would not be the case, because it
> was only tested on 2500base-x links with on-board Aquantia PHYs, where
> it was noticed that MII_LPA is always reported as zero, and it was
> thought that this is because of the PCS.

Yay. 

> 
> Test case #1 above shows it is not, and the configured MII_ADVERTISE on
> system A ends up in the MII_LPA on system B, when in 2500base-x mode
> (IF_MODE=0).
> 
> Test case #2, which uses "SGMII" auto-negotiation (IF_MODE=3) for the
> 3.125 Gbps lane, is actually a misconfiguration, but it is what led to
> the discovery.
> 
> There is actually an old bug in the Lynx PCS driver - it expects all
> register values to contain their default out-of-reset values, as if the
> PCS were initialized by the Reset Configuration Word (RCW) settings.
> There are 2 cases in which this is problematic:
> - if the bootloader (or previous kexec-enabled Linux) wrote a different
>   IF_MODE value
> - if dynamically changing the SerDes protocol from 1000base-x to
>   2500base-x, e.g. by replacing the optical SFP module.
> 
> Specifically in test case #2, an accidental alignment between the
> bootloader configuring the PCS to expect SGMII in-band code words, and
> the AQR115 PHY actually transmitting SGMII in-band code words when
> operating in the "OCSGMII" system interface protocol, led to the PCS
> transmitting replicated symbols at 3.125 Gbps baud rate. This could only
> have happened if the PCS saw and reacted to the SGMII code words in the
> first place.
> 
> Since test #2 is invalid from a protocol perspective (there seems to be
> no standard way of negotiating the data rate of 2500 Mbps with SGMII,
> and the lower data rates should remain 10/100/1000), in-band auto-negotiation
> for 2500base-x effectively means Clause 37 (i.e. IF_MODE=0).
> 
> Make 2500base-x be treated like 1000base-x in this regard, by removing
> all prior limitations and calling lynx_pcs_config_giga().
> 
> This adds a new feature: LINK_INBAND_ENABLE and at the same time fixes
> the Lynx PCS's long standing problem that the registers (specifically
> IF_MODE, but others could be misconfigured as well) are not written by
> the driver to the known valid values for 2500base-x.
> 
> Co-developed-by: Alexander Wilhelm <alexander.wilhelm@...termo.com>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@...termo.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

This looks to be incomplete - if AN is now supported at 2500base-X,
lynx_pcs_get_state_2500basex() is obsolete. As with 1000base-X,
phylink_mii_c22_pcs_get_state() can be called to retrieve the state
and it will do the right thing wrt 2.5G speeds.

Next, please look at whether lynx_pcs_link_up_2500basex() is necessary,
and whether the speed and duplex modes need to also be programmed for
1000base-X when inband is not enabled.

Essentially, by saying that inband is supported at 2.5G speeds as well
as 1G, both 1000base-X and 2500base-X should be treated the same way
by the PCS driver, so the code paths should be the same.

I note that SGMII_SPEED_2500 == SGMII_SPEED_1000, which means the
IF_MODE programming as far as HD+speed should end up being the same
for both these interface modes.

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