linux-kernel - Re: [PATCH net-next 2/2] net: bcmgenet: Support calling set

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: <1f270218-32c1-476b-a237-2c2458b17998@lunn.ch>
Date: Tue, 4 Nov 2025 05:14:55 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: netdev@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
	Doug Berger <opendmb@...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>,
	Simon Horman <horms@...nel.org>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Antoine Tenart <atenart@...nel.org>,
	Kuniyuki Iwashima <kuniyu@...gle.com>,
	Yajun Deng <yajun.deng@...ux.dev>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] net: bcmgenet: Support calling
 set_pauseparam from panic context

On Mon, Nov 03, 2025 at 03:00:21PM -0800, Florian Fainelli wrote:
> On 11/3/25 14:19, Andrew Lunn wrote:
> > > @@ -139,7 +141,8 @@ void bcmgenet_phy_pause_set(struct net_device *dev, bool rx, bool tx)
> > >   	linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydev->advertising, rx);
> > >   	linkmode_mod_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydev->advertising,
> > >   			 rx | tx);
> > > -	phy_start_aneg(phydev);
> > > +	if (!panic_in_progress())
> > > +		phy_start_aneg(phydev);
> > 
> > 
> > That does not look correct. If pause autoneg is off, there is no need
> > to trigger an autoneg.
> > 
> > This all looks pretty messy.
> 
> That is pre-existing code, so it would be a separate path in order to fix,
> though point taken.

Yes, i just noticed it in passing, a separate issue.

And by messy, i was meaning all the conditional locks. A new ethtool
op would avoid all that, and the new op is also really simple.

	Andrew