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

[Vladimir Oltean <olteanv@gmail.com>]

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.