netdev - Re: [PATCH net-next] net: phy: realtek: disable PHY-mode EEE

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

Message-ID: <Z9ieiYHUSnBbppe4@shell.armlinux.org.uk>
Date: Mon, 17 Mar 2025 22:13:29 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next] net: phy: realtek: disable PHY-mode EEE

On Mon, Mar 17, 2025 at 10:40:38PM +0100, Andrew Lunn wrote:
> On Sun, Mar 16, 2025 at 12:39:54PM +0000, Russell King (Oracle) wrote:
> > Realtek RTL8211F has a "PHY-mode" EEE support which interferes with an
> > IEEE 802.3 compliant implementation. This mode defaults to enabled, and
> > results in the MAC receive path not seeing the link transition to LPI
> > state.
> > 
> > Fix this by disabling PHY-mode EEE.
> > 
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> > ---
> > This patch isn't the best approach...
> 
> But i guess a better approach requires we have support for PHY-mode
> EEE? Which at the moment we do not have.

I'm not sure what this "PHY-mode" is - the datasheet for the PHY doesn't
mention the mode in its functional description, it only exists as a
simple description in the register documentation!

What I do know is that with this bit set, a MAC behind it never sees
the LPI signalled from the remote end, but 'scope shows that the
physical link has quietened down except for what I'd call the chirps
to keep both ends synchronised.

With the bit clear, then everything works as expected - as tested with
the stmmac driver on a Tegra platform. The stmmac MAC sees LPI on its
receive side, and all the nice juicy stmmac bugs requiring RXC to be
running can then be reproduced. :)

Not sure whether it would be better to fix stmmac first before this
is merged, but in order to develop and test, it needs to be fixed
first so the bug(s) can be reproduced. Given the netdev backlog, it
is unlikely that I'll get the stmmac patches out before the merge
window opens and net-next closes - so the "regression" that nvidia
reported is not going to get fixed in this cycle.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!