From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D9179D3409E for ; Tue, 27 Jan 2026 16:18:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/79F/2nYHgLtX3zWZBYvS4vVO4mvQ/yFNKrEZukNPf4=; b=P+aHR+y8S6cnbo uChdsr0sKlsgDp2AvwgP9e/58gVThQqTbA2Eysy4I8wn9+xz0Tnmrggj98lp2hVInK9aAMQKb7N/4 yuHjTFR/AmKZ/UnnpQZDKiUvhcV6N3igQAfeEmJP2xLGfZg5sFDVQnV9obIi0hn/v5R+Wqjc3XLVA vQC76sU593oHGzkt5Qb87vX1sfPNZCTEAZkM65ZOOdQIJ8GUTyVaepsA9afkwZE3awDgojI7ODcmg ZLbbFfVFE34RLKgWe3X53iMwMYVpZqcojI1iCBN37qyZloib8XwzYFWE+n0Wuf6xmZQk7gD0Jt2Z7 PsgUjxa056WYNRJoRF8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vkllf-0000000Edm9-3DFA; Tue, 27 Jan 2026 16:18:16 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vkllX-0000000EdlF-1LCS; Tue, 27 Jan 2026 16:18:07 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 77FA560132; Tue, 27 Jan 2026 16:18:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 987AEC116C6; Tue, 27 Jan 2026 16:18:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769530686; bh=ZcNWtYJLIeryb15EqaIHjsT/CHKImJVZ9MYEChHRjRI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=i1fRsSxV9eVplljd+MJ6yUFvekmXAaHasq2TxJPzMmEmHW6XOVTGJPY5H5/PpjoPt 5lV896kGw0/406DS2MElUeHkkQc68yLkwtDyND7plvjq1EQuZtwr+8jDvS4H2WrF+i VqmNtJdv05LND6Fzfa0CMHrQ4Qgs5nq7GgTqblB7w+ySjgOS3pPrtLWtdSxt4mSByF 2kF9Lia/W5vBPtEWCvXn84V4mPNmRLpTRZ+T6hwR/kArs10I4s000LpEsISzBjRxaL O3Wwc1tumTy48rBSBsxvOC97A/BRRS2BwPC9GfsAW/JYW08WtyAUaR9BBsWxXrGYnF eL92+wnW9rJ4w== Date: Tue, 27 Jan 2026 08:18:04 -0800 From: Jakub Kicinski To: "Russell King (Oracle)" Cc: linux-stm32@st-md-mailman.stormreply.com, andrew+netdev@lunn.ch, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, pabeni@redhat.com, linux-rockchip@lists.infradead.org, heiko@sntech.de, alexandre.torgue@foss.st.com, andrew@lunn.ch, davem@davemloft.net, edumazet@google.com Subject: Re: [net-next,v2,06/22] net: stmmac: rk: add SoC specific ->init() method Message-ID: <20260127081804.64841f65@kernel.org> In-Reply-To: References: <20260127004020.3785641-1-kuba@kernel.org> MIME-Version: 1.0 X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Tue, 27 Jan 2026 11:09:58 +0000 Russell King (Oracle) wrote: > > > If ops->init() fails here, does bsp_priv->phy_reset need to be released? > > > > > > Earlier in rk_gmac_setup(), at line 1610, the code calls: > > > > > > bsp_priv->phy_reset = of_reset_control_get(plat->phy_node, NULL); > > > > > > of_reset_control_get() is not a devm-managed function, so the reset control > > > would need to be explicitly released with reset_control_put() on error paths. > > > > > > This new error return happens after phy_reset could have been acquired (when > > > the device has an integrated PHY), but before the function successfully > > > returns. If this path is taken, it appears the reset control would be leaked. > > > > > > Currently no SoC sets ops->init so this path cannot trigger, but when a > > > future SoC implements this callback, the leak would occur on init failure > > > for devices with integrated PHYs. > > > > However, the driver does not release this resource when cleaning up, so > > that's already a bug as the driver currently stands. I think this could > > be converted to devm_reset_control_get(), which would resolve both > > leakages, but not sure. > > Note that fixing this is going to add yet another patch to the series, > because this is a pre-existing bug in the driver. It can't be replaced > with devm_reset_control_get(), because this driver is getting resources > for a foreign device (we don't have the struct device pointer.) > > So, it isn't going to be a simple patch to fix this. Would it work to make that plus patches 1-4,6 a separate series? _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip