linux-kernel - Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes

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: <d00838cc-5035-463b-9932-491c708dc7ac@lunn.ch>
Date: Tue, 29 Apr 2025 14:08:01 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Matthias Schiffer <matthias.schiffer@...tq-group.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Andy Whitcroft <apw@...onical.com>,
	Dwaipayan Ray <dwaipayanray1@...il.com>,
	Lukas Bulwahn <lukas.bulwahn@...il.com>,
	Joe Perches <joe@...ches.com>, Jonathan Corbet <corbet@....net>,
	Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
	Siddharth Vadapalli <s-vadapalli@...com>,
	Roger Quadros <rogerq@...nel.org>, Tero Kristo <kristo@...nel.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux@...tq-group.com
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller:
 update descriptions of RGMII modes

On Tue, Apr 29, 2025 at 09:24:49AM +0200, Matthias Schiffer wrote:
> On Mon, 2025-04-28 at 16:08 +0200, Andrew Lunn wrote:
> > 
> > > > However, with the yaml stuff, if that is basically becoming "DT
> > > > specification" then it needs to be clearly defined what each value
> > > > actually means for the system, and not this vague airy-fairy thing
> > > > we have now.
> > 
> >  
> > > I agree with Russell that it seems preferable to make it unambiguous whether
> > > delays are added on the MAC or PHY side, in particular for fine-tuning. If
> > > anything is left to the implementation, we should make the range of acceptable
> > > driver behavior very clear in the documentation.
> > 
> > I think we should try the "Informative" route first, see what the DT
> > Maintainers think when we describe in detail how Linux interprets
> > these values.
> 
> Oh, we should not be Linux-specific. We should describe in detail how *any OS*
> must interpret values.

There is two things here. One is related to delays on the PCB. Those
are OS agnostic and clearly you are describing hardware. But once you
get to implementing the delay in the MAC or the PHY, it is policy if
the PHY does it, or the MAC does it. Different OSes can have different
policy. We cannot force other OSes to do the same as Linux.
 
I drafted some text last night. I need to review it because i often
make typos, and then i will post it.

	Andrew