linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <804f394db1151f1fb1f19739d5347b38a3930e8a.camel@ew.tq-group.com>
Date: Mon, 04 Aug 2025 15:45:08 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Michael Walle <mwalle@...nel.org>, Siddharth Vadapalli
 <s-vadapalli@...com>,  Andrew Lunn <andrew@...n.ch>
Cc: 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>, 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 Mon, 2025-08-04 at 09:37 +0200, Michael Walle wrote:
> On Sat Aug 2, 2025 at 7:44 AM CEST, Siddharth Vadapalli wrote:
> > 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.
> 
> Of all the myriad settings of the SoC, this was the one which was
> not validated? Anyway, TI should really get that communicated in a
> proper way because in the e2e forum you'll get the exact opposite
> answer, which is, it is a documentation issue. And also, the
> original document available to TI engineers apparently has that setting
> documented (judging by the screenshot in the e2e forum).
> 
> > 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 that case u-boot shall be fixed, soon. And to workaround older
> u-boot versions, linux shall always enable that delay, like Andrew
> proposed.

I can submit my patch for U-Boot some time this week, probably tomorrow. Do you
also want me to take care of the Linux side for enabling the MAC delay?

Best,
Matthias


> 
> > 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.
> 
> See above, that seems to be still the case.
> 
> -michael

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/