linux-kernel - Re: [PATCH] net: stmmac: don't stop RXC during LPI

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]

Date:   Wed, 26 Jan 2022 13:27:34 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jisheng Zhang <jszhang@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: stmmac: don't stop RXC during LPI

On Wed, Jan 26, 2022 at 08:55:22PM +0800, Jisheng Zhang wrote:
> On Sun, Jan 23, 2022 at 06:39:26PM +0100, Andrew Lunn wrote:
> > > I think this is a common issue because the MAC needs phy's RXC for RX
> > > logic. But it's better to let other stmmac users verify. The issue
> > > can easily be reproduced on platforms with PHY_POLL external phy.
> > 
> > What is the relevance of PHY polling here? Are you saying if the PHY
> > is using interrupts you do not see this issue?
> 
> I tried these two days, if the PHY is using interrupts, I can't
> reproduce the issue. It looks a bit more complex. Any suggestions?

I suppose it could be that there is a delay between the PHY reporting
the link loss, raising an interrupt, which is then processed to disable
the receive side, and the PHY going into LPI. The problem with polling
is, well, it's polling, and at a one second rate - which probably is too
long between the PHY noticing the loss of link and going into LPI.

What this also probably means is that if interrupt latency is high
enough, the same problem will occur.

So maybe the EEE support to be a little more clever - so we only enable
clock stop after the MAC driver has disabled the receive side.

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