netdev - 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: <f7d78131-7425-487f-a8bb-ed747dd9a194@lunn.ch>
Date: Fri, 26 Sep 2025 18:09:10 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Yangfl <mmyangfl@...il.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, 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

> > > 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?

Sorry, i'm missing some context here.

Why do you actually need REVSGMII, or at least the concept?

REVMII is used when you connect one MAC to another. You need to
indicate one ends needs to play the PHY role. This is generally when
you connect a host MAC to an Ethernet switch, and you want the switch
to play the PHY role.

Now consider SGMII, when connecting a host MAC to a switch. Why would
you even use SGMII, 1000BaseX is the more logical choice. You don't
want the link to run at 100Mbps, or 10Mbps. The link between the host
and the switch should run as fast as possible. And 1000BaseX is
symmetrical, you don't need a REV concept.

Also, in these cases, stmmmac is on the host, not the switch, so it
will have the host role, leaving the switch to play 'PHY'. I'm not
sure you could even embedded stmmac in a switch, where it might want
to play 'PHY', because stmmac is software driven, where as a switch is
all hardware.

So the hardware supports reverse SGMII, but it is not clear to me why
you would want to use it.

	Andrew