[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOiHx=kt+pMVJ+MCUKC3M6QeMg+gamYsnhBAHkG3b6SGEknOuw@mail.gmail.com>
Date: Fri, 7 Nov 2025 14:52:02 +0100
From: Jonas Gorski <jonas.gorski@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, 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>,
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
Hi,
On Fri, Nov 7, 2025 at 2:20 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > + /* Older driver versions incorrectly applied delays in
> > + * PHY_INTERFACE_MODE_RGMII mode. In order to not break old users, keep
> > + * interpreting RGMII as RGMII-ID.
> > + */
> > + if (interface == PHY_INTERFACE_MODE_RGMII)
> > + interface = PHY_INTERFACE_MODE_RGMII_ID;
>
> Did you look through the in kernel .dts files? How many systems does
> this effect?
I did, and the answer is 0, at least if looking at the cpu port node.
If also looking at the ethernet nodes where it is connected to it
becomes a bit unclear to me.
There is broadcom/bcm53573.dtsi defines a switch node in disabled
without any phy-mode, and all includers either delete the switch node,
or do not define any phy-mode (or phy-connection-type) either. The
ethernet node itself uses "internal".
There is allwinner/sun7i-a20-lamobo-r1.dts, which uses "rgmii-txid",
which is untouched by this patch. The ethernet interface uses "rgmii".
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".
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.
Not sure what the correct move here is for the latter two, especially
since I have no hardware to test.
> 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.
Best regards,
Jonas
Powered by blists - more mailing lists