netdev - Re: [PATCH net] net: dsa: mxl-gsw1xx: manually clear RANEG bit

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: <aTMtI5VseldRIUnF@makrotopia.org>
Date: Fri, 5 Dec 2025 19:06:11 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, 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>,
	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 03:52:49PM +0000, Russell King (Oracle) wrote:
> On Fri, Dec 05, 2025 at 03:40:35PM +0000, Daniel Golle wrote:
> > On Fri, Dec 05, 2025 at 03:17:37PM +0000, Russell King (Oracle) wrote:
> > > On Fri, Dec 05, 2025 at 01:56:39PM +0000, Daniel Golle wrote:
> > > > On Fri, Dec 05, 2025 at 02:45:35PM +0100, Andrew Lunn wrote:
> > > > > 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.
> > > > 
> > > > Is the restart_an() operation allowed to sleep? Looking at other
> > > > drivers I only ever see that it sets a self-clearing AN RESTART bit,
> > > > never waiting for that bit to clear. Hence I wanted to immitate
> > > > that behavior by clearing the bit asynchronously. If that's not needed
> > > > and msleep(10) or usleep_range(10000, 20000) can be used instead that'd
> > > > be much easier, of course.
> > > 
> > > Sleeping is permitted in this code path, but bear in mind that it
> > > will be called from ethtool ops, and thus the RTNL will be held,
> > > please keep sleep durations to a minimum.
> > 
> > In that sense 10ms (on top of the MDIO operation) is not that little.
> > Maybe it is worth to use delayed_work to clear the bit after all...
> 
> ... in which case I think you need to do a better job.
> 
> The cancel_delayed_work() in the pcs_disable() method means if we
> stopp using this PCS briefly while the AN restart bit is set, there's
> nothing that will clear it.

The reset of the whole PCS unit (which is asserted in .pcs_disable and
deasserted in .pcs_enable) also resets the AN restart bit.

> 
> There are other implementations that have this problem. mvneta has
> the same problem, but there we can write the register to set the
> MVNETA_GMAC_INBAND_RESTART_AN, and then immediately write it again
> without delay to clear this bit. The bit is documented as self
> clearing, but practical observation indicates it never does.
> 
> Are you sure you need to wait 10ms ? What happens if you set the
> bit and then immediately clear it, like we do for mvneta?

MaxLinear engineer Benny Weng has told me (quote):

"I did a check on the REANEG bit, [...] and it needs to clear the bit
manually and please give 10ms delay in between."

In my observation the bit *does* clear itself *most* of the time,
but aparently when being set in the wrong moment it doesn't. This
makes testing rather difficult and I'd just follow their advise.