[PATCH] fsl/fman: Fix clk reference leak in read_dts_node()

[PATCH] fsl/fman: Fix clk reference leak in read_dts_node()

[Wentao Liang]

of_clk_get() returns a clock with its reference count incremented, but
read_dts_node() only uses it to read the rate and never calls clk_put().
The clock is not stored anywhere, so the reference cannot be released
later either.

Release the clock once its rate has been read, which also covers the
error path taken when the rate is zero.

Fixes: 414fd46e7762 ("fsl/fman: Add FMan support")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 drivers/net/ethernet/freescale/fman/fman.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 013273a2de32..0f342b1a845b 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2732,6 +2732,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
 	}
 
 	clk_rate = clk_get_rate(clk);
+	clk_put(clk);
 	if (!clk_rate) {
 		err = -EINVAL;
 		dev_err(&of_dev->dev, "%s: Failed to determine FM%d clock rate\n",
-- 
2.34.1

Re: [PATCH] fsl/fman: Fix clk reference leak in read_dts_node()

[Simon Horman]

On Thu, Sep 17, 2026 at 11:01:35AM +0000, Wentao Liang wrote:
> of_clk_get() returns a clock with its reference count incremented, but
> read_dts_node() only uses it to read the rate and never calls clk_put().
> The clock is not stored anywhere, so the reference cannot be released
> later either.
> 
> Release the clock once its rate has been read, which also covers the
> error path taken when the rate is zero.
> 
> Fixes: 414fd46e7762 ("fsl/fman: Add FMan support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>

As noted by Andrew Lunn elsewhere, fixes for bugs are present in net
should be target at net like this:

Subject: [PATCH net] ...

Also, perhaps someone else has mentioned this, but please slow down a bit
with your patches. I see 19 in Patchwork as of writing. But we encourage
a maximum of 15, and I really would like to stress that is a maximum
to be used sparingly, not a buffer to be refilled.

Link: https://docs.kernel.org/process/maintainer-netdev.html#limit-patches-outstanding-on-mailing-list

I don't think there is any need to repost because of this feedback,
but please keep them in mind for the future.

As for this code change, it looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>