linux-kernel - Re: [PATCH net-next v11 2/5] net: phy: introduce PHY_INTERFACE_MODE

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: <aNREByX9-8VtbH0n@shell.armlinux.org.uk>
Date: Wed, 24 Sep 2025 20:18:31 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: David Yang <mmyangfl@...il.com>, netdev@...r.kernel.org,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Simon Horman <horms@...nel.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v11 2/5] net: phy: introduce
 PHY_INTERFACE_MODE_REVSGMII

On Wed, Sep 24, 2025 at 08:41:06PM +0200, Andrew Lunn wrote:
> In theory, {R}GMII does have inband signalling, but it is pretty much
> never used. REV for GMII could thus indicate what role the device is
> playing in this in-band signalling?

For RGMII, as you say, the in-band signalling is pretty much never used.
The stmmac code as it stands today does have support for using it, but
the code has been broken for longer than six years:

1. the longest historical breakage, it's conditional on the hardware
   reporting that it has a PCS integrated into the design, but a PCS
   won't be integrated into the design for RGMII-only cases.

2. even if (1) was fixed, that would result in the driver manipulating
   the netif carrier state from interrupt context, always beating
   phylink's resolve worker, meaning that mac_link_(down|up) never get
   called. This results in no traffic flow and a non-functional
   interface.

So, maybe we should just ignore the RGMII in-band signalling until
someone pops up with a hard and fast requirement for it.

> For any SERDES based links likes like SGMII, 1000Base-X and above,
> clocking is part of the SERDES, so symmetrical. There clearly is
> inband signalling, mostly, when it is not broken because of
> overclocked SGMII. But we have never needed to specify what role each
> end needs to play.

100base-X is intentionally symmetric, and designed for:

	MAC----PCS---- some kind of link ----PCS----MAC

where "some kind of link" is fibre or copper. There is no reverse mode
possible there, because "reverse" is just the same as "normal".

For SGMII though, it's a different matter. The PHY-like end transmits
the link configuration. The MAC-like end receives the link
configuration and configures itself to it - and never sends a link
configuration back.

So, the formats of the in-band tx_config_reg[15:0] are different
depending on the role each end is in.

In order for a SGMII link with in-band signalling to work, one end
has to assume the MAC-like role and the other a PHY-like role.

PHY_INTERFACE_MODE_SGMII generally means that the MAC is acting in a
MAC-like role. However, stmmac had the intention (but broken) idea
that setting the DT snps,ps-speed property would configure it into a
PHY-like role. It almost does... but instead of setting the "transmit
configuration" (TC) bit, someone typo'd and instead set the "transmit
enable" (TE) bit. So no one has actually had their stmmac-based
device operating in a PHY-like role, even if they _thought_ it was!

> > However, stmmac hardware supports "reverse" mode for more than just
> > SGMII, also RGMII and SMII.
> 
> How does the databook describe reverse SGMII? How does it differ from
> SGMII?

It doesn't describe "reverse SGMII". Instead, it describes:

1. The TC bit in the MAC configuration register, which makes the block
   transmit the speed and duplex from the MAC configuration register
   over RGMII, SGMII or SMII links (only, not 1000base-X.)

2. The SGMIIRAL bit in the PCS control register, which switches where
   the SGMII rate adapter layer takes its speed configuration from -
   either the incoming in-band tx_config_reg[15:0] word, or from the
   MAC configuration register. It is explicitly stated for this bit
   that it is for back-to-back MAC links, and as it's specific to
   SGMII, that means a back-to-back SGMII MAC link.

Set both these bits while the MAC is configured for SGMII mode, and
you have a stmmac MAC which immitates a SGMII PHY as far as the
in-band tx_config_reg[15:0] word is concerned.

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