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 1F6CF2F60CB for ; Wed, 28 Jan 2026 12:20:09 +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=1769602811; cv=none; b=YxlvLcZ55SBfMTPOMS6HbtjUufVvkY8/E98IH7dHkpSOjSIwKbNqUhiK8VZisq7zuJFbsj3Up39ZWDrRge2GToktKt6zr3TrnGOHe9Kvan7KQMVsEx+282/7J9G7xRplsUWND8yPBBOjYd12ABVIRmOHEanW6i24ZVJNkZSGoYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769602811; c=relaxed/simple; bh=FWxaYVTB0KpBOKsNtP1n3kIxFkvHH8CTcgSRc43DxLA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JTkuKiF3GsBR01gNf4gQ5rpld5pkh9Qrk2/uSEJ8qt7/O4mC6inDt2UzE+3TQ4v/BTcy6PeVMNUT/6ICXmvVgHrTVANx6/Zp/jc7Vn2AC92lpJ7zBNWXiRsoOfBDvNBHGxmLsnsXf72JvnlV45GIe+Fujgi3jqd1ZgNzcREOnTU= 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=Qzi+YIXH; 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="Qzi+YIXH" 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=ISotn7edf+IUTj82nvFY2R7E+1j0WbBkqwZTBvRb3ws=; b=Qzi+YIXHL/nhOP7tltKeGwXgJm TDhTlh2TPDZxXVdv5t87t7vOJ8E4/MaWXYHiS3vl0HG23k3aakBDz6HFBXxIvKGrR4WDE1jFgF5e5 t09PWIRt76FZjpVYVe+bi6M32aA+UjIgGmzOO4wbHYUHTB1dcSgRkEdDjgGamVIVfGfxN973Z4BIZ 00yUAVQ48RWmURUaDLH8Wjkcu+8ZStYGULzBdOn8+AlwytvuLrmPYgTs6ywykk+O2ZFVpXoUEvGyN 1HWJpcMJxB8wD/nUk5PFF9scmXJwRH3P2Y7Cu3DkQZfsLvXIXci9UP6mTJwFfKwdInatD5diUFl4P knpPGadA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:55194) 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 1vl4We-000000007Lo-18uM; Wed, 28 Jan 2026 12:20:00 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1vl4Wa-000000006xo-3rF9; Wed, 28 Jan 2026 12:19:56 +0000 Date: Wed, 28 Jan 2026 12:19:56 +0000 From: "Russell King (Oracle)" To: Philipp Zabel Cc: Andrew Lunn , Alexandre Torgue , Andrew Lunn , "David S. Miller" , Eric Dumazet , Heiko Stuebner , Jakub Kicinski , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org, Paolo Abeni Subject: Re: [PATCH net-next 1/3] net: stmmac: rk: fix missing reset_control_put() Message-ID: References: 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 Wed, Jan 28, 2026 at 01:04:21PM +0100, Philipp Zabel wrote: > On Mi, 2026-01-28 at 10:58 +0000, Russell King (Oracle) wrote: > > rk_gmac_setup() delves into the PHY's DT node to retrieve its reset > > control using of_reset_control_get(). However, it never releases it > > when the driver is removed. Add reset_control_put() to rk_gmac_exit() > > to clean this up. > > > > Signed-off-by: Russell King (Oracle) > > --- > > drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c > > index 5f8d2031b97c..bc69cbb5a7d4 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c > > @@ -1784,6 +1784,8 @@ static void rk_gmac_exit(struct device *dev, void *bsp_priv_) > > > > if (priv->plat->phy_node && bsp_priv->integrated_phy) > > clk_put(bsp_priv->clk_phy); > > + > > + reset_control_put(bsp_priv->phy_reset); > > } > > > > static int rk_gmac_probe(struct platform_device *pdev) > > This is fine because the driver sets plat_dat->suspend, and so > rk_gmac_exit() is never called via stmmac_pltfr_exit() during suspend. > > It does look a bit sketchy to release resources in the rk_gmac_exit() > counterpart to rk_gmac_init(), which never requested the resources, > though. Maybe use devm_add_action_or_reset() to register the release of > the reset during remove? Thanks, but I think a sense of proportion is required here. This patch is the result of introducing the ->init() method, and AI noticing that there was no cleanup of this resource. This was the simplest way to implement that cleanup. However, your review commit also applies to bsp_priv->clk_phy which has the same problem - this also isn't obtained in rk_gmac_init(), but in rk_gmac_clk_init(). Given that, and the fact that this entire series is already considerably big (it was 21 patches, then 22, now 23, and with this it's going to become 24 patches) I'm going to say that this issue can be addressed at a later time. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!