Message-ID: <e08888ab-d190-4829-9aef-a8adef63b968@lunn.ch>
Date: Wed, 11 Jun 2025 17:05:21 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	Rob Herring <robh@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Chaoyi Chen <chaoyi.chen@...k-chips.com>,
	Matthias Schiffer <matthias.schiffer@...tq-group.com>,
	Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add
 informative text about RGMII delays

> BTW I found that in some case the assumption of PHY-side delay being
> always better than MAC-side one is wrong -- modern MACs usually have
> adjustable delay line, but Realtek 8211-series PHYs have only on/off
> delay with a fixed 2ns value.

There is another email conversation last month about this. The RGMII
standard says a 2ns delay is needed. If your hardware needs something
other than 2ns, it is breaking the standard. It probably means
somebody has been lazy and made a bad design. The PCB track lengths
have not been balanced, or the MAC or PHY internal delays are poorly
designed. Whatever, it is breaking the standard. We should not be
encouraging such bad design by making it easy to work around broken
designs.

There is also another thread about Broadcom MAC/PHY combinations, and
somebody doing tests and showing that combination is very robust to
delays, it will happily work with 1ns or 3ns, not just 2.00ns.

So in general, a fixed 2ns value should just work if you are
compliment to the standard.

> > > Well I am not sure, considering two examples I raised here (please
> > > note
> > > I am comparing QCOM ETHQOS and TI PRUETH two drivers, they have
> > > contrary handling of RGMII modes, and one matches the old binding
> > > document, one matches the new one).
> > 
> > Nope, i fully agree with Russell, the binding has not changed, just
> > the
> > words to explain the binding.
> 
> Well I read about phy.rst, and I found my understanding of the old
> binding matches my understanding of phy.rst, but does not match the new
> binding.

So please quote the text, explain how you interpret it, and maybe we
can then tell you how you have it wrong. Or i might admit that the
text needs more work to remove more ambiguities.

> Well I think "rgmii-*" shouldn't exist at all, if focusing on hardware.
> I prefer only "rgmii" with properties describing the delay numbers.

As Russell said, we cannot easily change it without breaking
systems. And i'm not convinced a new set of properties would be any
better. Developers are often lazy. They try various things until it
works and call it done. There are multiple ways of getting a MAC/PHY
link to work given the available parameters, and there are multiple
combination which works, but are not correct according to the
definitions. I expect the same to be true for a new set of
parameters. Laziness wins out over correctness.

And the real issue is more subtle. Working incorrect implementations
sometimes turn into broken incorrect implementations. We have seen
cases where somebody correctly describes their hardware in DT and it
did not work. Digging into the details, how the implementation was
broken was found, and fixed, so that it correctly implemented DT, and
made that correctly described board work. But in the process it broken
lots of incorrectly described but working boards.

	Andrew

Powered by blists - more mailing lists