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

["Michael Walle" <mwalle@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]