netdev - Re: [PATCH 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

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: <Z8bhJkxUbG_HjXVf@shell.armlinux.org.uk>
Date: Tue, 4 Mar 2025 11:16:54 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Biju Das <biju.das.jz@...renesas.com>
Cc: "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
	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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Giuseppe Cavallaro <peppe.cavallaro@...com>,
	Jose Abreu <joabreu@...opsys.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

On Tue, Mar 04, 2025 at 10:56:39AM +0000, Biju Das wrote:
> > For the failure to happen, you need to check whether EEE is being used:
> > 
> > # ethtool --show-eee ethX
> > 
> > and check whether it states that EEE is enabled and active, and Tx LPI also shows the timer value.
> > 
> > You need a PHY that does stop it's receive clock when the link enters low-power mode. PHYs are not
> > required to have this ability implemented, and there's no way for software to know whether it is or
> > not.
> > 
> > Then, you need to be certain that your link partner does actually support EEE and signals LPI from its
> > side, rather than just advertising EEE. Lastly, you need to ensure that there is no traffic over the
> > cable when you're resuming for the period of the reset timeout for the failure to occur. If the link
> > wakes up, the clock will be started and reset will complete.
> > 
> > One can rule out some of the above by checking the LPI status bits, either in the DWMAC or PHY which
> > indicates whether transmit and/or receive seeing LPI signalled.
> > 
> > If the link doesn't enter low power, then the receive clock won't be stopped, and reset will complete.
> > If the link wakes up during reset, then the clock will be restarted, and reset will complete before
> > the timeout expires.
> > 
> > So, the possibility for a successful test is quite high.
> 
> 
> This what I get on next. It is showing enabled , but inactive.
> 
> root@...rc-rzg3e:~# ethtool --show-eee eth0
> EEE settings for eth0:
>         EEE status: enabled - inactive
>         Tx LPI: 1000000 (us)
>         Supported EEE link modes:  100baseT/Full
>                                    1000baseT/Full
>         Advertised EEE link modes:  100baseT/Full
>                                     1000baseT/Full
>         Link partner advertised EEE link modes:  Not reported

That means your link partner doesn't support EEE (or has EEE disabled)
so the issue we're discussing in this thread doesn't occur for your
setup.

In order to do a valid test for the issue in this thread, you need a
link partner that supports EEE and has EEE enabled.

Note that also with an EEE capable setup, with the LPI timer set to
one second, you need to have not transmitted any packets for one
second before the transmit path enters LPI. Although this is the
default for stmmac, it seems to me to be an excessively long default,
and may even be masking some problems.

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