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

[Andrew Lunn]

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