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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAXyoMPmwvxsk0vMD5aUvx9ajbeAENtengzUgBteV_CFJoqXWg@mail.gmail.com>
Date: Fri, 26 Sep 2025 14:30:25 +0800
From: Yangfl <mmyangfl@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, 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 Thu, Sep 25, 2025 at 3:18 AM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> 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!

So any conclusion? Should I go on with REV*MII, or wait for (or write
it myself) reverse-mode flag?