Re: [PATCH net-next v11 2/5] net: phy: introduce PHY_INTERFACE_MODE_REVSGMII

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Sep 26, 2025 at 02:30:25PM +0800, Yangfl wrote:
> On Thu, Sep 25, 2025 at 3:18 AM Russell King (Oracle)
> <linux@armlinux.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.
> 
> So any conclusion? Should I go on with REV*MII, or wait for (or write
> it myself) reverse-mode flag?

Clearly not as there's been no discussion beyond my response to Andrew.
I don't know what to suggest, as whatever decision we make here, we
will have to live with the consequences of it for a very long time.

I suspect no one really knows the answer, so given the lack of
engagement on the issue, my suggestion would be to just press ahead
with your current approach.

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