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: <CAAXyoMM3QG+zWJQ8tAgZfb4R62APgBaqaKDR=151R7+rzzakCw@mail.gmail.com>
Date: Sat, 27 Sep 2025 00:28:05 +0800
From: Yangfl <mmyangfl@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

On Sat, Sep 27, 2025 at 12:09 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > > 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
>

Cause I couldn't make 1000BaseX work with qca-ssdk, so I can only
confirm and test REVSGMII mode on my device.