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: <24fab53831b359f3e3d809d22ace7572e196cdf0.camel@ew.tq-group.com>
Date: Wed, 30 Apr 2025 09:33:59 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Andrew Lunn <andrew@...n.ch>
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, 2025-04-29 at 14:08 +0200, Andrew Lunn wrote:
> 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.

If we want to support fine-tuning properties and other driver-specific
attributes that rely on the specific delay mode used on the MAC or PHY side, we
must make this policy a part of the binding docs.

Also, we make decisions how DT bindings work in Linux all the time, and other OS
must implement them in the same way to be compatible with Device Trees using
these bindings. I don't see how in this case we suddenly can't make such a
decision.

>  
> I drafted some text last night. I need to review it because i often
> make typos, and then i will post it.

Thanks, I'll give it a read later.

Best,
Matthias

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/