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 ADB7040DFD9; Fri, 10 Apr 2026 23:49:26 +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=1775864968; cv=none; b=J7fSnTZLotLayDXxsvnQSGL1fxw5wXzh5CEoloZOE+kibPpPIhsyc/4teBqVjz7YI2R+Z2jOz3zKjsqN8Q7ALdPTaQwsXk+zthhoxieEiqXGznsuIWz4RJmEruCS993y185pxTk4DjVggSHPl3QC07fGX82R/Tub7KnIY1RlfdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775864968; c=relaxed/simple; bh=pLiaHzDtvRPWgWLYGJlwiFUsCCGbTtzVX9RlVtYqPGY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SiF6f4pPFFyjknCvJZeZlvyorxHaH5S8Bp2Udc3N60uG3zXHDfV0cBJpnJytHqCK8FI+RbtwT1OcJwQ5/3MT6ijyVdNt0Pc5mFRKJD+3HJ/A7kknFdkOetUS8UJdcmerolrgxybC7AawsJ4oh5DArDipsj1X0/+osTjMqA4n9OU= 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=FV/Dzq/x; 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="FV/Dzq/x" 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=GniXfLefCt+nsXI0+DB9pBwNPJLQYdvU0xNyxBuHy7I=; b=FV/Dzq/xwRVulghjslqRmGOd8Y 4Iw4Fd2dWsVQQyC9YtW/1GqIlJQCSKx4uIu1puR7T8UQAaqKudFNlkO2Ugtl/i7yGfV3NbvXOOOCB zLd65ZP2rNOsO2DuQR37TXt8qWq0BViL6U48G+fwvdFlyB44Ym5vXS7nq0DgNUyTWmdHaxF48B428 eDBGYIXYGIqgwanhUXhvV5s0+O60cmBHSvLghNfN0My+kQ5RFfi9FQsrqY4UjwPG1r0m5IOpDgy8J IUMzZVEbpdSUnBDp0y6jRCVAwblmJ9GPqQLzz8ErZ2NGc6tWAdAQx8taBorxTnzp71k5GGjMqGs1v A4XlokPg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:37062) 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 1wBLbB-000000005UD-3ORn; Sat, 11 Apr 2026 00:49:17 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1wBLb8-00000000659-3B1D; Sat, 11 Apr 2026 00:49:14 +0100 Date: Sat, 11 Apr 2026 00:49:14 +0100 From: "Russell King (Oracle)" To: Biju Das Cc: Andrew Lunn , "biju.das.au" , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Ovidiu Panait , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Geert Uytterhoeven , Prabhakar Mahadev Lad , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path Message-ID: References: <20260410142904.439666-1-biju.das.jz@bp.renesas.com> <839fec66-5ec0-4cc0-a0c4-ae2de6902188@lunn.ch> Precedence: bulk X-Mailing-List: netdev@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: Sender: Russell King (Oracle) On Fri, Apr 10, 2026 at 04:41:08PM +0000, Biju Das wrote: > Hi Andrew, > > > -----Original Message----- > > From: Andrew Lunn > > Sent: 10 April 2026 16:15 > > Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path > > > > > Apart from that, looks fine to me - it seems some paths call > > > phy_init_hw() can be called with or without phydev->lock held, and > > > this one will call it with the lock held which seems to be okay. > > > > Haven't we had deadlocks in this area before? > > > > Please test with CONFIG_PROVE_LOCKING enabled. > > I have n't faced any issue with micrel phy. But my collegue > got the below issue with Microsemi phy. It doesn't finish the boot. > > drivers/net/phy/mscc/mscc_main.c Looking at this driver, I'm wondering why it's taking phydev->lock in vsc85xx_edge_rate_cntl_set()... phy_modify_paged() is already a fully locked atomic operation (it takes the bus lock) and taking phydev->lock gains nothing. vsc85xx_mac_if_set() is a different matter, and this _should_ be using phy_modify() to atomically change MSCC_PHY_EXT_PHY_CNTL_1. phydev->lock doesn't guarantee that e.g. userspace won't access the register behind this code's back. vsc8531_pre_init_seq_set() is a repeat of vsc85xx_edge_rate_cntl_set() except with phy_select_page()..phy_restore_page() which does the necessary bus locking to ensure the entire sequence is done atomically. Ditto vsc85xx_eee_init_seq_set(). So, I question whether any of the functions in this driver actually have a valid reason to take phydev->lock - looks to me like a not very well written driver. In cases like this, I don't think we should make things more difficult in the core just because we have a lockdep splat when that can be avoided by killing off unnecessary locking. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!