[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97389f24-d900-4ff0-8a80-f75e44163499@lunn.ch>
Date: Fri, 5 Dec 2025 14:45:35 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Hauke Mehrtens <hauke@...ke-m.de>, Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Rasmus Villemoes <ravi@...vas.dk>,
"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
John Crispin <john@...ozen.org>
Subject: Re: [PATCH net] net: dsa: mxl-gsw1xx: manually clear RANEG bit
On Fri, Dec 05, 2025 at 01:32:20AM +0000, Daniel Golle wrote:
> Despite being documented as self-clearing, the RANEG bit sometimes
> remains set, preventing auto-negotiation from happening.
>
> Manually clear the RANEG bit after 10ms as advised by MaxLinear, using
> delayed_work emulating the asynchronous self-clearing behavior.
Maybe add some text why the complexity of delayed work is used, rather
than just a msleep(10)?
Calling regmap_read_poll_timeout() to see if it clears itself could
optimise this, and still be simpler.
Andrew
Powered by blists - more mailing lists