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

Message-ID: <b75c6a2cf10e2acf878c38f8ca2ff46708a2c0a1.camel@ew.tq-group.com>
Date: Tue, 29 Apr 2025 09:24:49 +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 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.

> 
> I don't think a whole new set of properties will solve anything. I
> would say the core of the problem is that there are multiple ways of
> getting a working system, many of which don't fit the DT binding. But
> DT developers don't care about that, they are just happy when it
> works. Adding a different set of properties won't change that.
> 
> 	Andrew

Hmm, considering that

- interpretation of existing properties is inconsistent
- we could like something with a consistent interpretation
- we can't change how existing drivers interpret the properties, as that would
be a breaking change,

I don't think we really have any options but to introduce something new, or keep
the inconsistent status quo.

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/