rk_crypto_pm_init() calls pm_runtime_use_autosuspend(), but the
autosuspend setting is not undone if pm_runtime_set_suspended() fails
or when runtime PM is later torn down by rk_crypto_pm_exit().

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 cleanup, this reference is not dropped and usage_count remains
unbalanced.

Undo the autosuspend setting when pm_runtime_set_suspended() fails and
in rk_crypto_pm_exit() before disabling runtime PM.

This issue was found by manual code inspection.

Fixes: a216be3964c1 ("crypto: rockchip - introduce PM")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/crypto/rockchip/rk3288_crypto.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/rockchip/rk3288_crypto.c b/drivers/crypto/rockchip/rk3288_crypto.c
index b77bdce8e7fc..cfca472f996f 100644
--- a/drivers/crypto/rockchip/rk3288_crypto.c
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -150,14 +150,17 @@ static int rk_crypto_pm_init(struct rk_crypto_info *rkdev)
 	pm_runtime_set_autosuspend_delay(rkdev->dev, 2000);
 
 	err = pm_runtime_set_suspended(rkdev->dev);
-	if (err)
+	if (err) {
+		pm_runtime_dont_use_autosuspend(rkdev->dev);
 		return err;
+	}
 	pm_runtime_enable(rkdev->dev);
 	return err;
 }
 
 static void rk_crypto_pm_exit(struct rk_crypto_info *rkdev)
 {
+	pm_runtime_dont_use_autosuspend(rkdev->dev);
 	pm_runtime_disable(rkdev->dev);
 }
 
-- 
2.43.0

On 08/08/2026 11:30, Guangshuo Li wrote:
> rk_crypto_pm_init() calls pm_runtime_use_autosuspend(), but the
> autosuspend setting is not undone if pm_runtime_set_suspended() fails
> or when runtime PM is later torn down by rk_crypto_pm_exit().
> 
> 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 cleanup, this reference is not dropped and usage_count remains
> unbalanced.
> 
> Undo the autosuspend setting when pm_runtime_set_suspended() fails and
> in rk_crypto_pm_exit() before disabling runtime PM.
> 
> This issue was found by manual code inspection.
> 
> Fixes: a216be3964c1 ("crypto: rockchip - introduce PM")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---

You sent vast amount of patches, all separate, making it very difficult
to track and respond in efficient way. Do not do that.

Group your work per subsystem.

You were asked to clarify and respond to incorrect fixes statement. I do
not see how you clarified and responded at all.

Best regards,
Krzysztof

Hi Krzysztof,

On Thu, 20 Aug 2026 at 22:49, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 08/08/2026 11:30, Guangshuo Li wrote:
> > rk_crypto_pm_init() calls pm_runtime_use_autosuspend(), but the
> > autosuspend setting is not undone if pm_runtime_set_suspended() fails
> > or when runtime PM is later torn down by rk_crypto_pm_exit().
> >
> > 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 cleanup, this reference is not dropped and usage_count remains
> > unbalanced.
> >
> > Undo the autosuspend setting when pm_runtime_set_suspended() fails and
> > in rk_crypto_pm_exit() before disabling runtime PM.
> >
> > This issue was found by manual code inspection.
> >
> > Fixes: a216be3964c1 ("crypto: rockchip - introduce PM")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
>
> You sent vast amount of patches, all separate, making it very difficult
> to track and respond in efficient way. Do not do that.
>
> Group your work per subsystem.
>
> You were asked to clarify and respond to incorrect fixes statement. I do
> not see how you clarified and responded at all.
>
> Best regards,
> Krzysztof

Sorry about that. I should have replied to the earlier review comments
explicitly, and I also should not have sent so many separate patches.

I will group future patches by subsystem and make sure to respond
clearly to review feedback before resending.

Thanks for pointing this out.

Best regards,
Guangshuo