linux-kernel - Re: [PATCH net] 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] [day] [month] [year] [list]

Message-ID: <73ffdfe2-ecf2-44e9-8850-c00ed9ff388c@lunn.ch>
Date: Tue, 29 Apr 2025 17:26:26 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: 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] dt-bindings: net: ethernet-controller: Add
 informative text about RGMII delays

> > +# In practice, very few PCBs make use of extra long clock lines. Hence
> > +# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
> > +# unlikely to be accepted during review.
> 
> Maybe add "without details provided in the commit description."

I was thinking about that. And i would actually prefer a comment in
the DT explicitly saying the PCB adds delays.

> > +# If the PHY is to perform fine tuning, the properties
> > +# 'rx-internal-delay-ps' and 'tx-internal-delay-ps' in the PHY node
> > +# should be used. When the PHY is implementing delays, these
> > +# properties should have a value near to 2000ps.
> 
> ... according to the phy-mode used (as they're documented to be
> dependent on that.)
> 
> I'm wondering whether they should be dependent on which rgmii-* mode
> is being used, as delays << 2ns could be used to finely adjust the
> PCB delays if the PHY supports that. I haven't looked closely enough
> at PHY datasheets to know whether that's possible or not though.

Yes, i was trying to express that with the 'When the PHY is
implementing delays'. If the PHY is not adding delays, 'rgmii', small
fine tuning delays are O.K. And some PHYs do support this, they cover
the full range from 0ps to > 2000ps in steps.

	Andrew