From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9363F4C92; Tue, 7 Apr 2026 07:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775547657; cv=none; b=r6dn+2JfH1Bk8NnKNvsn2YmeceRUfwshwR1L9xoFcOamaHoshOBTgqRfQHb3oMECNgpaYUkiQmloRcquR8B63cYG3BV9PONpfn1Fc3c5GuaAL9uNGVn7s/LVfqRRsn2+5W6DQFRJs476+ggZNFuXTsKqo+FLHmysR/ryLdSLpXE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775547657; c=relaxed/simple; bh=xJ+zGuJ1ieW3IvMEzlcpuTEzIG3X1G9Bvo6tbsCX+bw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tXpSg32PM0w5D60y12zs1jZI6N3y9aMukCnnmrrG2yKct2iLSPS2Tr7ZtPPD7/637TvbukFmbcHuuZEeP9pERrD3fI8eKa9H1U6BDa4tAAEhYLXqusCqJJdLtfP4l6vfk+6dbJD7aXBOPfVVFT3ipXdkEaQ5jZ0szuNZW/3G4Fs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=icfMnjbb; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="icfMnjbb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=w/+taouX3Llr4l2eNBv9LRKm8Q+7wm2zafn3JOBQYX4=; b=icfMnjbbmfPCRJfi6wFqpbccat I+tTYcSPNng6wcCLScI5QuOdiQWPTNkg+ZHm1k6dU7FMxmRawVpOpWkQyy7mgX5+TadNHI3uILMdk St++IawXo4a1zb5Zdj7WvnDXzK40sWF6+2u7B5cUGJwOqIEdMcCbBrwRm+01I+N8oMuroHx+bAE5Q BznflKUqRdIY59SWUTQeydZnIOcZ/EXRLiD9hyAuK4xpnQeLUCONlVZcqbMAS2O9uh8U9bGBbQccy q9T3T27hk0AHqsKp0BEYuffGuCV/07WMj8durbr4ffpJiYGgyFr4lX3gh+cnOwsUo2GrIntLerLJH 0ULKTmaw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35644) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wA13K-000000000aL-13ou; Tue, 07 Apr 2026 08:40:50 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1wA13E-00000000260-3esB; Tue, 07 Apr 2026 08:40:44 +0100 Date: Tue, 7 Apr 2026 08:40:44 +0100 From: "Russell King (Oracle)" To: Jiawen Wu Cc: netdev@vger.kernel.org, 'Mengyuan Lou' , 'Andrew Lunn' , "'David S. Miller'" , 'Eric Dumazet' , 'Jakub Kicinski' , 'Paolo Abeni' , 'Simon Horman' , 'Jacob Keller' , 'Abdun Nihaal' , stable@vger.kernel.org Subject: Re: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module Message-ID: References: <076401dcc17d$905c40b0$b114c210$@trustnetic.com> <096d01dcc657$9ee42b00$dcac8100$@trustnetic.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <096d01dcc657$9ee42b00$dcac8100$@trustnetic.com> Sender: Russell King (Oracle) On Tue, Apr 07, 2026 at 02:27:34PM +0800, Jiawen Wu wrote: > On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote: > > On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote: > > > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote: > > > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote: > > > > > For the copper NIC with external PHY, the driver called > > > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during > > > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy() > > > > > upon module remove. > > > > > > > > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close. > > > > > > > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the > > > > remove function with rtnl_lock()..rtnl_unlock() ? > > > > > > This is also a solution. But I think it would be nice to unify with other drivers > > > that call the functions in ndo_open/close. > > > > Both approaches are equally valid. Some network drivers attach the PHY > > at probe time (and thus can return -EPROBE_DEFER if the PHY is specified > > but not present). Others attach in .ndo_open which can only fail in this > > circumstance with no retry without userspace manually implementing that. > > > > There are other advantages and disadvantages to each approach. > > Hi, > > So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it? The reaosn phylink_disconnect_phy() requires the RTNL lock is because it _can_ be called while the netdev is published, and the RTNL lock protects the networking core from the PHY being removed from the netdev, preventing ethtool ops into the PHY driver from running concurrently with the PHY's disconnection and potential later destruction. Offering two APIs, one which requires the lock to provide that protection and one which doesn't would over-complicate the phylink code and make reviews way more difficult, as we'd now have to spot the wrong function being used in the wrong code path. It's simpler for drivers that want to connect and disconnect the PHY at probe/remove time for them to just take the RTNL lock briefly over the call to phylink_disconnect_phy(). There is no "recommendation" for connecting and disconnecting the PHY at probe/remove time vs ndo_open/ndo_release. That's entirely up to the driver author. As I've already said, there are advantages and disadvantages of either way and that's a matter for the driver author to consider and select the most appropriate choice for their driver. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!