stm32_rng_probe() calls pm_runtime_use_autosuspend(), but neither the
probe failure path nor stm32_rng_remove() calls the matching
pm_runtime_dont_use_autosuspend() before disabling runtime PM.

If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.

Add the missing pm_runtime_dont_use_autosuspend() calls to both the
probe failure and remove paths before disabling runtime PM.

This issue was found by manual code inspection.

Fixes: c6a97c42e399 ("hwrng: stm32 - add support for STM32 HW RNG")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/char/hw_random/stm32-rng.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
index 9a8c00586ab0..6de4c52bd4d6 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -370,6 +370,7 @@ static int stm32_rng_init(struct hwrng *rng)
 
 static void stm32_rng_remove(struct platform_device *ofdev)
 {
+	pm_runtime_dont_use_autosuspend(&ofdev->dev);
 	pm_runtime_disable(&ofdev->dev);
 }
 
@@ -592,7 +593,14 @@ static int stm32_rng_probe(struct platform_device *ofdev)
 	pm_runtime_use_autosuspend(dev);
 	pm_runtime_enable(dev);
 
-	return devm_hwrng_register(dev, &priv->rng);
+	ret = devm_hwrng_register(dev, &priv->rng);
+	if (ret) {
+		pm_runtime_dont_use_autosuspend(dev);
+		pm_runtime_disable(dev);
+		return ret;
+	}
+
+	return 0;
 }
 
 static struct platform_driver stm32_rng_driver = {
-- 
2.43.0

On Sat, Aug 08, 2026 at 03:45:10PM +0800, Guangshuo Li wrote:
> stm32_rng_probe() calls pm_runtime_use_autosuspend(), but neither the
> probe failure path nor stm32_rng_remove() calls the matching
> pm_runtime_dont_use_autosuspend() before disabling runtime PM.
>
> If the autosuspend delay is set to a negative value while autosuspend
> is enabled, the runtime PM core increments usage_count to prevent
> runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
> during teardown, this reference is not dropped and usage_count remains
> unbalanced.

If calls to pm_runtime_use_autosuspend() must be paired with
pm_runtime_dont_use_autosuspend() then I wonder if having a
devm_pm_runtime_use_autosuspend() would be worthwhile?

That way stm32_rng_remove() could be entirely replaced with devres
cleanup.


Daniel.

Hi Daniel,

Thanks for the suggestion.

On Mon, 10 Aug 2026 at 18:24, Daniel Thompson <danielt@kernel.org> wrote:
>
> On Sat, Aug 08, 2026 at 03:45:10PM +0800, Guangshuo Li wrote:
> > stm32_rng_probe() calls pm_runtime_use_autosuspend(), but neither the
> > probe failure path nor stm32_rng_remove() calls the matching
> > pm_runtime_dont_use_autosuspend() before disabling runtime PM.
> >
> > If the autosuspend delay is set to a negative value while autosuspend
> > is enabled, the runtime PM core increments usage_count to prevent
> > runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
> > during teardown, this reference is not dropped and usage_count remains
> > unbalanced.
>
> If calls to pm_runtime_use_autosuspend() must be paired with
> pm_runtime_dont_use_autosuspend() then I wonder if having a
> devm_pm_runtime_use_autosuspend() would be worthwhile?
>
> That way stm32_rng_remove() could be entirely replaced with devres
> cleanup.
>
>
> Daniel.

There is already devm_pm_runtime_enable(), whose devres cleanup calls
pm_runtime_dont_use_autosuspend() followed by pm_runtime_disable().

So I think this driver can simply switch from pm_runtime_enable() to
devm_pm_runtime_enable(), and stm32_rng_remove() can then be removed
entirely.

I'll rework the patch accordingly.

Thanks,
Guangshuo