netdev - Re: [PATCH net-next] Revert "net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed RGMII TX delay"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <47b0406f-7980-422e-b63b-cc0f37d86b18@ti.com>
Date: Sat, 2 Aug 2025 11:14:23 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Andrew Lunn <andrew@...n.ch>
CC: Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Michael Walle
	<mwalle@...nel.org>, Nishanth Menon <nm@...com>,
        Vignesh Raghavendra
	<vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>, Andrew Lunn
	<andrew+netdev@...n.ch>,
        "David S . Miller" <davem@...emloft.net>,
        Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni
	<pabeni@...hat.com>, Roger Quadros <rogerq@...nel.org>,
        Simon Horman
	<horms@...nel.org>,
        Siddharth Vadapalli <s-vadapalli@...com>,
        Maxime
 Chevallier <maxime.chevallier@...tlin.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux@...tq-group.com>
Subject: Re: [PATCH net-next] Revert "net: ethernet: ti: am65-cpsw: fixup PHY
 mode for fixed RGMII TX delay"

On Wed, Jul 30, 2025 at 04:27:52PM +0200, Andrew Lunn wrote:
> > I can confirm that the undocumented/reserved bit switches the MAC-side TX delay
> > on and off on the J722S/AM67A.
> 
> Thanks.
> 
> > I have not checked if there is anything wrong with the undelayed
> > mode that might explain why TI doesn't want to support it, but
> > traffic appears to flow through the interface without issue if I
> > disable the MAC-side and enable the PHY-side delay.
> 
> I cannot say this is true for TI, but i've often had vendors say that
> they want the MAC to do the delay so you can use a PHY which does not
> implement delays. However, every single RGMII PHY driver in Linux
> supports all four RGMII modes. So it is a bit of a pointless argument.
> 
> And MAC vendors want to make full use of the hardware they have, so
> naturally want to do the delay in the MAC because they can.
> 
> TI is a bit unusual in this, in that they force the delay on. So that
> adds a little bit of weight towards maybe there being a design issue
> with it turned off.

Based on internal discussions with the SoC and Documentation teams,
disabling TX delay in the MAC (CPSW) is not officially supported by
TI. The RGMII switching characteristics have been validated only with
the TX delay enabled - users are therefore expected not to disable it.
Disabling the TX delay may or may not result in an operational system.
This holds true for all SoCs with various CPSW instances that are
programmed by the am65-cpsw-nuss.c driver along with the phy-gmii-sel.c
driver.

In addition to the above, I would like to point out the source of
confusion. When the am65-cpsw-nuss.c driver was written(2020), the
documentation indicated that the internal delay could be disabled.
Later on, the documentation was updated to indicate that internal
delay cannot (should not) be disabled by marking the feature reserved.
This was done to be consistent with the hardware validation performed.
As a result, older documentation contains references to the possibility
of disabling the internal delay whereas newer documentation doesn't.

Regards,
Siddharth.