netdev - Re: [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay on bcm63xx

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: <a1197a9b-48c3-4dce-866e-287f5cd30865@lunn.ch>
Date: Fri, 23 May 2025 15:24:03 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jonas Gorski <jonas.gorski@...il.com>
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>,
	Vivien Didelot <vivien.didelot@...il.com>,
	Álvaro Fernández Rojas <noltari@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 2/3] net: dsa: b53: fix configuring RGMII delay on
 bcm63xx

On Fri, May 23, 2025 at 11:08:55AM +0200, Jonas Gorski wrote:
> On Tue, May 20, 2025 at 2:15 AM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > Without this change no mode/port works, since there is always either a
> > > 0 ns delay or a 4 ns delay in the rx/tx paths (I assume, I have no
> > > equipment to measure).
> > >
> > > With this change all modes/ports work.
> >
> > Which is wrong.
> >
> > > With "rgmii-id" the mac doesn't
> > > configure any delays (and the phy does instead), with "rgmii" it's
> > > vice versa, so there is always the expected 2 ns delay. Same for rxid
> > > and txid.
> >
> > If you read the description of what these four modes mean, you should
> > understand why only one should work. And given the most likely PCB
> > design, the only mode that should work is rgmii-id. You would have to
> > change the PCB design, to make the other modes work.
> 
> Since I also have BCM6368 with a BCM53115 connected to one of the
> RGMII ports lying around, I played around with it, and it was
> surprisingly hard to make it *not* work. Only if I enabled delay on
> *both* sides it stopped working, no delay or delay only on one side
> continued working (and I used iperf to try if larger amounts of
> traffic break it).

Interesting. You see the Rockchip people insisting their devices need
fine tuning, 2ns is not good enough, it needs to be 1.9ns. And then
they end up in a mess with interpreting what phy-mode actually means.

In some ways, this just as bad. You can get away with using 'rgmii'
which is wrong, when it should be 'rgmii-id'. It would be better if
only just one mode worked, then DT developers would get it correct.

	Andrew