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] [day] [month] [year] [list]

Message-ID: <aNbWEdabqXIaoo2T@shell.armlinux.org.uk>
Date: Fri, 26 Sep 2025 19:06:09 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Yangfl <mmyangfl@...il.com>
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 Sat, Sep 27, 2025 at 12:28:05AM +0800, Yangfl wrote:
> 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.

I think it would help if you could show what you tried for 1000base-X
in terms of dts fragments for both ends.

Marvell DSA switches support 1000base-X, but it defaults to link-down
and without AN, so expecting in-band to work with it doesn't result
in a working link, but using fixed-link on both ends does.

Maybe qca-ssdk needs that as well? Is that what you tried?

It could also be a buggy MAC driver that doesn't disable in-band AN
for 1000base-X in fixed link mode.

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