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

Message-ID: <CAOiHx=mBPUg-a=_PgdrOD25A=Gz8gEkG9Z+JkNkCv8u1zoLpVw@mail.gmail.com>
Date: Sat, 8 Nov 2025 12:31:02 +0100
From: Jonas Gorski <jonas.gorski@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>, 
	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 7, 2025 at 4:33 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Fri, Nov 07, 2025 at 04:45:15PM +0200, Vladimir Oltean wrote:
> > 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
>
> As this is discussing the applicability of RGMII delays for DSA
> switches, I've long held out that the situation is a mess, and
> diverges from what we decide to do for MACs - so I'd prefer not
> to get involved in this, except to say...
>
> > 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.
>
> Indeed - let's not break existing working setups. If there is a
> problem with them, then that's the time to start thinking about
> changing them.

I completely understand the reluctance to change anything, and I'm
trying my best to not break anything:

The only mode used by in-tree device trees is "rgmii-txid". This
already behaved as it would for a PHY, and I did not change the
behavior.
As you probably know "rgmii" is often wrongly used, and the old
behavior was to enable delays in both directions in this case. I did
not change the behavior here either.

So for the known cases, and the suspected "wrong" usages, I did not
change anything, so these will continue working as expected.

My interpretation here so far was/is, and what I'm trying to follow here is:

if this is the CPU port that is connected to a different MAC (that is
controlled by the host), then on that port the switch is the "PHY", so
it is responsible for the delays according to phy-mode, as the other
MAC is supposed to not enable any (and doesn't know that there is a
DSA switch on the other side, unless it also is a DSA switch).

In any other case, don't apply any delays, because here the switch is
the MAC, and the other side is a PHY (or "PHY") and therefore
responsible for any delays that are needed.

Having an external b53 switch connected via its CPU port to an
internal b53 switch is a common setup on BCM63XX, so here b53 must
enable delays on one side, and currently it does not enable them on
either side.

Currently, the only way to configure this is by using the definitely
wrong "rgmii" phy-mode. Anyone writing a new board will just use it,
because it works, and we can't prevent it. I want to give the option
of using the less wrong "rgmii-id" value, which at least (in my
interpretation) matches the spirit of phy-mode.

Would it ease your concerns if I guard enabling delays with
dsa_port_is_cpu())? To make clear that we don't enable delays on any
user/dsa ports, and only the one that goes in the direction of the
kernel/host (the "root" of the DSA tree).

Best regards,
Jonas