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: <4fbcce38-0a74-48d5-9802-a430098eccf2@lunn.ch>
Date: Fri, 18 Apr 2025 22:40:59 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: Matthias Schiffer <matthias.schiffer@...tq-group.com>,
	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>,
	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>,
	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 15, 2025 at 04:06:31PM +0530, Siddharth Vadapalli wrote:
> On Tue, Apr 15, 2025 at 12:18:01PM +0200, Matthias Schiffer wrote:
> > As discussed [1], the comments for the different rgmii(-*id) modes do not
> > accurately describe what these values mean.
> > 
> > As the Device Tree is primarily supposed to describe the hardware and not
> > its configuration, the different modes need to distinguish board designs
> 
> If the Ethernet-Controller (MAC) is integrated in an SoC (as is the case
> with CPSW Ethernet Switch), and, given that "phy-mode" is a property
> added within the device-tree node of the MAC, I fail to understand how
> the device-tree can continue "describing" hardware for different board
> designs using the same SoC (unchanged MAC HW).

phy-mode describes the link between the MAC and the PHY. So it either
needs to be in the MAC node, or the PHY node when describing the
board. I don't know the history of why it ended up in the MAC node,
but it did.

> Since all of the above is documented in "ethernet-controller.yaml" and
> not "ethernet-phy.yaml", describing what the "MAC" should or shouldn't
> do seems accurate, and modifying it to describe what the "PHY" should or
> shouldn't do seems wrong.

What we are really saying here is, does the PCB have extra long clock
lines in order to add the delays? If yes, the MAC/PHY pair does
nothing. If no, the MAC/PHY pair needs to add the delay.

DT however says nothing about how the MAC/PHY pair should add the
delay. That would be configuration, and DT should try to not describe
configuration. Hence the binding description needs to be neutral to
MAC and PHY.

Linux has a preference, that the PHY does the delay. However, other
operating systems might have other preferences. And since the binding
should be generic across a range of operating systems, we don't
mention Linux's preference.

	Andrew