All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xiangwu Lai" <laixiangwu@cmss.chinamobile.com>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [PATCH] pinctrl: stm32: Fix reset control leak in stm32_pctl_probe() error paths
Date: Tue, 10 Nov 2026 07:11:44 +0000	[thread overview]
Message-ID: <sashiko-outbox-206463@kernel.org> (raw)
In-Reply-To: <20261110065722.1340-1-laixiangwu@cmss.chinamobile.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] pinctrl: stm32: incorrect Fixes trailer in commit message
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Medium] pinctrl: stm32: clock leak in stm32_pctl_probe() [1]
--

commit 7844cefd15f00547f16870f8594d1153fe131bff
Author: Xiangwu Lai <laixiangwu@cmss.chinamobile.com>

> pinctrl: stm32: Fix reset control leak in stm32_pctl_probe() error paths
>
> stm32_pctl_probe() acquires an exclusive reset control for every GPIO
> bank with of_reset_control_get_exclusive(), but none of the error
> paths release them again: the bank loop returns directly on
> -EPROBE_DEFER and on a failed clock lookup, and the
> clk_bulk_prepare_enable() failure and the err_register path also
> leave the already acquired reset controls behind.
>
> On success the reset controls are kept for the lifetime of the device
> and are never released either (the driver has no .remove), but that
> is harmless.  On a failed probe, and in particular when the probe is
> retried after -EPROBE_DEFER, every attempt leaks another set of
> reset control references.
>
> Release the acquired reset controls on all error paths.
>
> Fixes: bb949ed9b16b ("pinctrl: stm32: Switch to use for_each_gpiochip_node() helper")
> Signed-off-by: laixiangwu <laixiangwu@cmss.chinamobile.com>

[Severity: Low]
Commit bb949ed9b16b ("pinctrl: stm32: Switch to use for_each_gpiochip_node()
helper") only replaced the child-node iteration macro without changing how
bank->rstc was acquired or cleaned up.  Should the Fixes tag instead point
to 2254e77665d5 ("pinctrl: stm32: defer probe if reset resource is not yet
ready"), which moved the of_reset_control_get_exclusive() loop into
stm32_pctl_probe() and added the -EPROBE_DEFER return path?

> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
> index 405ebb22c9eaf..02410e57f97d7 100644
> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
> @@ -1963,15 +1963,17 @@ int stm32_pctl_probe(struct platform_device *pdev)
>  		bank->rstc = of_reset_control_get_exclusive(np, NULL);
>  		if (PTR_ERR(bank->rstc) == -EPROBE_DEFER) {
>  			fwnode_handle_put(child);
> -			return -EPROBE_DEFER;
> +			ret = -EPROBE_DEFER;
> +			goto err_put_rstcs;
>  		}

[Severity: Medium]
This problem wasn't introduced by this patch, but does jumping to
err_put_rstcs without calling clk_bulk_put(i, pctl->clks) leak the clock
references [1] acquired in earlier iterations of the loop when
of_reset_control_get_exclusive() returns -EPROBE_DEFER on a subsequent bank
(i > 0)?

[1] https://sashiko.dev/#/bug/linux-022b050a-8471-43dd-a330-d8c0a082f0ff

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110065722.1340-1-laixiangwu@cmss.chinamobile.com?part=1

  reply	other threads:[~2026-11-10  7:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  6:57 [PATCH] pinctrl: stm32: Fix reset control leak in stm32_pctl_probe() error paths Xiangwu Lai
2026-11-10  7:11 ` sashiko-bot [this message]
2026-11-10  8:32   ` Xiangwu Lai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-206463@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=laixiangwu@cmss.chinamobile.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.