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.
