linux-kernel - Re: [RFC net-next v1 2/2] net. phy: dp83tg720: Add randomized polling intervals for unstable link detection

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]

Message-ID: <1f2c1169-076d-460f-9635-d6ca6c4d310d@lunn.ch>
Date: Thu, 28 Nov 2024 15:29:20 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC net-next v1 2/2] net. phy: dp83tg720: Add randomized
 polling intervals for unstable link detection

On Thu, Nov 28, 2024 at 09:07:14AM +0100, Oleksij Rempel wrote:
> Hi Andrew,
> 
> On Wed, Nov 27, 2024 at 04:37:49PM +0100, Andrew Lunn wrote:
> > On Wed, Nov 27, 2024 at 02:10:11PM +0100, Oleksij Rempel wrote:
> > > Address the limitations of the DP83TG720 PHY, which cannot reliably detect or
> > > report a stable link state. To handle this, the PHY must be periodically reset
> > > when the link is down. However, synchronized reset intervals between the PHY
> > > and its link partner can result in a deadlock, preventing the link from
> > > re-establishing.
> > > 
> > > This change introduces a randomized polling interval when the link is down to
> > > desynchronize resets between link partners.
> > 
> > Hi Oleksij
> > 
> > What other solutions did you try? I'm wondering if this is more
> > complex than it needs to be. Could you add a random delay in
> > dp83tg720_read_status() when it decides to do a reset?
> 
> Yes, this would be possible, but there are multiple reasons I decided to
> go this way:
> - in link down case, it is better to increase polling frequency, it
>   allows to reduce link up time.
> - there are PHYs, for example an integrated to LAN9372 which supports
>   only link down interrupt. As long as link is down, it should be
>   polled.
> - i'm working on generic PHY stats support and PHYs need to be polled,
>   even with IRQ support, just less frequently.
> 
> I can add it to the commit message.

Yes, more justification would be good.

In general, we try to hide workarounds for broken devices in the
driver, not expose it to all drivers. Variable rate polling, and
polling even when interrupt are enabled does however sound
useful. Cable testing might also be able to use it.

	Andrew