From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 71CB642AA6 for ; Tue, 27 Jan 2026 00:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769474457; cv=none; b=JRWPyWRwRAnfI0uh/nHoCLsIpKdIO62TsftKsPLfUKj/nRcNQa1WeVU9rf3CRczZkRx7526/3sBTZm551wUQJF+Hfe3/Hfpc8gR9BrRLxsw9ONbGA9RMRwCNudEWrXRNRQj8S8H7j6t0HSec/L/uW+0K+Xio7rZ7MpyCPhmJaGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769474457; c=relaxed/simple; bh=FDSZmApZTKLD7bqxE5fcK4gRn51ugRSvMR/vvQBFnWc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vAKnH3Ew+MKEmrov4agXyFU4vQGlaCrzNqXOdRSQloszrksb6XeBcmkQ8jdJnPXVF/4+sYBD3ZxA+LKeKCllf77prXRzXukNGDYYf97ahSkWuZwBNiXUwYaNqPDQJtP/UxHO+/ofVHx1cTIWx+wHefFdGDka0zff2bnXdL2zQRA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q0wLd03M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q0wLd03M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67DAAC116C6; Tue, 27 Jan 2026 00:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769474457; bh=FDSZmApZTKLD7bqxE5fcK4gRn51ugRSvMR/vvQBFnWc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q0wLd03Mgtol6WxGBhARowmEdA89LnFc0PHMRjf8qlNgKYXb3eMpsPBlZ6e8XwYFO IvqM5UDxe219kUeXSOmepN2HI5MdrL8eCwcI39U5MVHLAkzG/i7anAzgFwa1B700vL 3/6zDrsLrTcefDf+bVuFrLUMHiZDSmeJD7f8a7hPMiMiTsPoUqHJ+ObOAFYCJr3pB9 vEwEG5akak2+X/ZL91NSPlvDlJ0vWLfNu3EEGO60iu0ML26kuBTQGADJzuanY7iMLK ULRUV/f1CU8SwwzhAI0a24zyuKKJvlFxjx9nFVHQ7HwDvC/ycIyfTqfhvBXgjnz8xT YMfhBE8PvdVHg== From: Jakub Kicinski To: rmk+kernel@armlinux.org.uk Cc: Jakub Kicinski , 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 Date: Mon, 26 Jan 2026 16:40:20 -0800 Message-ID: <20260127004020.3785641-1-kuba@kernel.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- net: stmmac: rk: add SoC specific ->init() method This commit adds infrastructure for SoC-specific initialization by adding an init callback to rk_gmac_ops and calling it from rk_gmac_setup(). > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c > index 7f8ffd1549bc..4117f6863ff0 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c [ ... ] > @@ -1618,6 +1619,14 @@ static struct rk_priv_data *rk_gmac_setup(struct platform_device *pdev, > > bsp_priv->dev = dev; > > + if (ops->init) { > + ret = ops->init(bsp_priv); > + if (ret) { > + dev_err_probe(dev, ret, "failed to init BSP\n"); > + return ERR_PTR(ret); ^^^^^^^^^^^^^^^ 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. > + } > + } > + > return bsp_priv; > }