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] [thread-next>] [day] [month] [year] [list]

Message-ID: <57823bd1-265c-4d01-92d9-9019a2635301@lunn.ch>
Date: Mon, 28 Jul 2025 16:41:14 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Michael Walle <mwalle@...nel.org>
Cc: 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>,
	Matthias Schiffer <matthias.schiffer@...tq-group.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] Revert "net: ethernet: ti: am65-cpsw: fixup PHY
 mode for fixed RGMII TX delay"

On Mon, Jul 28, 2025 at 08:49:38AM +0200, Michael Walle wrote:
> This reverts commit ca13b249f291f4920466638d1adbfb3f9c8db6e9.
> 
> This patch breaks the transmit path on an AM67A/J722S. This SoC has an
> (undocumented) configurable delay (CTRL_MMR0_CFG0_ENET1_CTRL, bit 4).

Is this undocumented register only on the AM67A/J722S?

The patch being reverted says:

   All am65-cpsw controllers have a fixed TX delay

So we have some degree of contradiction here.

> The u-boot driver (net/ti/am65-cpsw-nuss.c) will configure the delay in
> am65_cpsw_gmii_sel_k3(). If the u-boot device tree uses rgmii-id this
> patch will break the transmit path because it will disable the PHY delay
> on the transmit path, but the bootloader has already disabled the MAC
> delay, hence there will be no delay at all.

We have maybe 8 weeks to fix this, before it makes it into a released
kernel. So rather than revert, i would prefer to extend the patch to
make it work with all variants of the SoC.

Is CTRL_MMR0_CFG0_ENET1_CTRL in the Ethernet address space? Would it
be possible for the MAC driver to read it, and know if the delay has
been disabled? The switch statement can then be made conditional?

If this register actually exists on all SoC variants, can we just
globally disable it, and remove the switch statement?

	 Andrew