Message-ID: <40720ca3b3b8676aaec55605a70f055418dcb4de.camel@ti.com>
Date: Thu, 22 Jan 2026 10:05:45 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Andrew Lunn <andrew@...n.ch>
CC: <nm@...com>, <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
	<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <bb@...com>, <afd@...com>,
	<p-bhagat@...com>, <gehariprasath@...com>, <stable@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <srk@...com>, <s-vadapalli@...com>
Subject: Re: [PATCH v2] arm64: dts: ti: k3-am62d2-evm: Fix missing RX delay
 for DP83867 PHY

On Wed, 2026-01-21 at 14:22 +0100, Andrew Lunn wrote:
> On Wed, Jan 21, 2026 at 11:15:50AM +0530, Siddharth Vadapalli wrote:
> > MAC Ports 1 and 2 of the CPSW3G Ethernet Switch in the AM62D2 SoC are both
> > connected to different instances of the DP83867 Ethernet PHY on the AM62D2
> > EVM, with the 'phy-mode' set to 'rgmii-id'. The DP83867 Ethernet PHY has to
> > add a 2 nanosecond delay on receive (from wire) based on the EVM design.
> > 
> > Since the device driver for the DP83867 Ethernet PHY coincidentally assumes
> > that a 2 nanosecond receive delay has to be added in the absence of the
> > 'ti,rx-internal-delay' property, Ethernet is functional.
> > 
> > However, since the device-tree is intended to describe the Hardware, and,
> > the device driver for the DP83867 Ethernet PHY may change in the future,
> > add the 'ti,rx-internal-delay' property and assign it the value
> > 'DP83867_RGMIIDCTL_2_00_NS' which corresponds to a 2 nanosecond
> > delay.
> 
> The driver will not change. Doing so will break boards, causing

Ok.

> regressions. Also, passing PHY_INTERFACE_MODE_RGMII_ID to the PHY
> means the PHY should add 2ns, or the closet it can achieve. The PHY
> driver does not coincidentally assumes that a 2 nanosecond receive
> delay is required, it is required a 2ns delay is added.

A default of 2ns is chosen and is overridden by the value specified in the
device-tree via the
'ti,rx-internal-delay' property. So it is ultimately what is described in
the device-tree that dictates the Hardware and the configuration that the
driver should perform. I agree that in this case the 2ns delay
doesn't have to be described in the device-tree for functionality. But my
question is whether it is wrong or unexpected to specify the delay in the
device-tree when it is simply describing the Hardware?

For further context, U-Boot (Bootloader) uses the Linux device-tree. The U-
Boot PHY driver relies
on the device-tree to specify the delay. Is it incorrect to rely on the
device-tree description for configuring the Hardware? Unlike Linux PHY
driver, the U-Boot PHY driver doesn't assign a default of 2ns. Instead, it
asks for the delay to be specified in the device-tree. While this may seem
like a 'bug' in the U-Boot PHY driver, given that a proper and complete
description of the Hardware is all that the driver expects, wouldn't the
proper 'fix' be to simply describe the same in the device-tree?

Please let me know what you think.

> 
> So this patch is pointless.
> 
> Please drop it.

This is required for U-Boot as pointed out above. The reason I didn't
mention it in the commit message earlier is because the patch is simply
describing the Hardware which is what the device-tree does. Mentioning U-
Boot would have taken the conversation in a different direction where the
reader starts questioning why U-Boot PHY driver can't have a default the
way Linux PHY driver does. That would be a valid point if the patch was
violating the device-tree convention or doing something unexpected. Since
that isn't the case, I have kept the description simple, positioning this
patch as a 'fix' in terms of explicitly describing the Hardware through the
device-tree, rather than depending on the driver defaults.

Regards,
Siddharth.

Powered by blists - more mailing lists