linux-kernel - Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add informative text about RGMII delays

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

Message-ID: <fc7ad44b922ec931e935adb96dcc33b89e9293b0.camel@icenowy.me>
Date: Wed, 11 Jun 2025 20:11:27 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, 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

在 2025-06-11星期三的 09:39 +0100，Russell King (Oracle)写道：
> On Wed, Jun 11, 2025 at 04:03:11PM +0800, Icenowy Zheng wrote:
> > 在 2025-06-05星期四的 15:48 +0200，Andrew Lunn写道：
> > > Which is theoretically fine. I've not looked at this driver in
> > > particular, but there are some MACs were you cannot disable the
> > > delay.
> > > The MAC always imposes 2ns delay. That would mean a PCB which
> > > also
> > > has
> > > extra long clock lines is simply FUBAR, cannot work, and 'rgmii'
> > > is
> > > invalid, so reject it.
> > 
> > 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.
> 
> The only time that MACs may implement delays based on the
> PHY_INTERFACE_MODE_RGMII* is if they also include code to pass
> PHY_INTERFACE_MODE_RGMII (no suffixes) to phylink / phylib to ensure
> that the PHY doesn't _also_ add delays. This isn't something we
> encourage because it's more code, more review, and a different way
> of implementing it - thus adding to maintainers workloads that are
> already high enough.

Well in fact I have an additional question: when the MAC has any extra
[tr]x-internal-delay-ps property, what's the threshold of MAC
triggering patching phy mode? (The property might be only used for a
slight a few hundred ps delay for tweak instead of the full 2ns one)

> 
> > > Just for a minute, consider your interpretation of the old text
> > > is
> > > wrong. Read the old text again and again, and see if you can find
> > > an
> > > interpretation which is the same as the new text. If you do:
> > > 
> > > * It proves our point that describing what this means is hard,
> > > and
> > >   developers will get it wrong.
> > > 
> > > * There is an interpretation of both the old and new where
> > > nothing
> > >   changed.
> > > 
> > > * You have to be careful looking at drivers, because some percent
> > > of
> > >   developers also interpreted it wrongly, and have broken
> > >   implementations as a result.  You cannot say the binding means
> > > X,
> > >   not Y, because there is a driver using meaning X.
> > > 
> > > My hope with the new text is that it focuses on hardware, which
> > > is
> > > what DT is about. You can look at the schematic, see if there is
> > > extra
> > > long clock lines or not, and then decided on 'rgmii-id' if there
> > > are
> > > not, and 'rgmii' is there are. The rest then follows from that.
> > 
> > Well I think "rgmii-*" shouldn't exist at all, if focusing on
> > hardware.
> > I prefer only "rgmii" with properties describing the delay numbers.
> 
> Yes, I think we as phylib maintainers have also come to the same
> conclusion with all the hassle this causes, but we can't get rid
> of this without breaking the kernel and breaking device-tree
> compatibility. So, we're stuck with it.
> 
> > > You are not reading it carefully enough. The binding describes
> > > hardware, the board. phy.rst describes the phylib interface. They
> > > are
> > > different.
> > 
> > Well I can't find the reason of phy-mode being so designed except
> > for
> > leaky abstraction from phylib.
> 
> I have no idea what that sentence means, sorry.

Well, I mean the existence of rgmii-* modes is coupled with the
internal of phylib, did I get it right?

>