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

[Siddharth Vadapalli]

On Mon, Apr 28, 2025 at 04:08:10PM +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.
> 
> 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.

Isn't the ambiguity arising due to an incomplete description wherein we
are not having an accurate description for the PCB Traces?

A complete description might be something like:

mac {
	pcb-traces {
		mac-to-phy-trace-delay = <X>; // Nanoseconds
		phy-to-mac-trace-delay = <Y>; // Nanoseconds
	};
	phy-mode = "rgmii-*";
	phy-handle = <&phy>;
};

In some designs, the "mac-to-phy-trace" and the "phy-to-mac-trace" are
treated as a part of the MAC block for example. Depending on which block
contains the trace, the delay is added accordingly.

Regards,
Siddharth.