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.

Fixes: 1544bca2f188 ("arm64: dts: ti: Add support for AM62D2-EVM")
Cc: <stable@vger.kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
---

Hello,

v1 of this patch is at:
https://lore.kernel.org/r/20260120061335.1497832-1-s-vadapalli@ti.com/
Changes since v1:
- Fixed typo in the commit message based on the feedback at:
  https://lore.kernel.org/r/6650770b-2e9c-4f9a-8310-1f335ffa69f8@ti.com/
- Collected Reviewed-by tag from
  Hari Prasath Gujulan Elango <gehariprasath@ti.com>
  https://lore.kernel.org/r/6650770b-2e9c-4f9a-8310-1f335ffa69f8@ti.com/

Patch is based on commit
6c790212c588 Merge tag 'devicetree-fixes-for-6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
of Mainline Linux.

Regards,
Siddharth.

 arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
index 2b233bc0323d..17c64af4f97b 100644
--- a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
@@ -649,12 +649,14 @@ &cpsw3g_mdio {
 
 	cpsw3g_phy0: ethernet-phy@0 {
 		reg = <0>;
+		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
 		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 		ti,min-output-impedance;
 	};
 
 	cpsw3g_phy1: ethernet-phy@3 {
 		reg = <3>;
+		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
 		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 		ti,min-output-impedance;
 	};
-- 
2.51.1

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
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.

So this patch is pointless.

Please drop it.

       Andrew

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.