linux-kernel - Re: [PATCH net v2] net: dsa: b53: bcm531x5: fix cpu rgmii mode interpretation

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: <20251107144515.ybwcfyppzashtc5c@skbuf>
Date: Fri, 7 Nov 2025 16:45:15 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>, Jonas Gorski <jonas.gorski@...il.com>,
	Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Álvaro Fernández Rojas <noltari@...il.com>
Subject: Re: [PATCH net v2] net: dsa: b53: bcm531x5: fix cpu rgmii mode
 interpretation

On Fri, Nov 07, 2025 at 03:07:48PM +0100, Andrew Lunn wrote:
> > There is allwinner/sun7i-a20-lamobo-r1.dts, which uses "rgmii-txid",
> > which is untouched by this patch. The ethernet interface uses "rgmii".
> 
> Which is odd, but lets leave it alone.
> 
> > And there is arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts,
> > where a comment says that it has a BCM53134, but there is no such
> > node. The ethernet node uses "rgmii".
> 
> aspeed pretty much always get phy-mode wrong. So i would not worry too
> much about this.
> 
> > So one doesn't define one, one uses rgmii-id on the switch / phy side
> > and rgmii on the ethernet mac side, and one only defines the ethernet
> > mac side as rgmii.
> 
> That is reasonable. It is a lot less clear what is correct for a
> MAC-MAC connection. For a MAC-PHY connection we do have documentation,
> the preference is that the PHY adds the delays, not the MAC. If the
> switch is playing PHY, then having it add delays is sensible.
> 
> > > I would maybe add a dev_warn() here, saying the DT blob is out of date
> > > and needs fixing. And fix all the in kernel .dts files.
> > 
> > Sure I can add a warning.
> 
> Great, thanks.
> 
> 	Andrew

+Russell

Numerous past discussions seem to suggest that a MAC should treat all
phy-mode RGMII values all the same, as they all mean what the _other_
end of the RGMII link has skewed. To apply RGMII delays on a MAC, the
'rx-internal-delay-ps' and 'tx-internal-delay-ps' properties can be
added to the MAC OF node, which absolutely explicitly refer to what the
MAC does and nothing else.

Various compatibility schemes are implemented by sja1105, qca8k,
Microchip KSZ, rtl8365mb, vsc73xx and most recently Lantiq GSWIP, all in
order to tolerate their old (many times unique) interpretations of
phy-mode, while respecting the delays from the explicit DT bindings if
those exist.

Since there is no 'correct' way to apply RGMII delays on a MAC according
to phy-mode, my advice, if possible, would be to leave sleeping dogs lie
and fix broken setups by adding the explicit device tree properties in
the MAC, and adding driver support for parsing these.