[PATCH] dmaengine: xilinx: zynqmp_dma: fix autosuspend cleanup during teardown

[PATCH] dmaengine: xilinx: zynqmp_dma: fix autosuspend cleanup during teardown

[Guangshuo Li]

zynqmp_dma_probe() calls pm_runtime_use_autosuspend(), but its failure
paths and zynqmp_dma_remove() do not call the matching
pm_runtime_dont_use_autosuspend().

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.

The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().

Add the missing pm_runtime_dont_use_autosuspend() calls to the probe
failure and remove paths.

This issue was found by manual code inspection.

Fixes: 64c6f7da8c2c ("dmaengine: zynqmp_dma: Add runtime pm support")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index f6a812e49ddc..635c3f6cc5c2 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -1116,8 +1116,10 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
 	}
 	if (!pm_runtime_enabled(zdev->dev)) {
 		ret = zynqmp_dma_runtime_resume(zdev->dev);
-		if (ret)
+		if (ret) {
+			pm_runtime_dont_use_autosuspend(zdev->dev);
 			return ret;
+		}
 	}
 
 	ret = zynqmp_dma_chan_probe(zdev, pdev);
@@ -1152,6 +1154,7 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
 err_disable_pm:
 	if (!pm_runtime_enabled(zdev->dev))
 		zynqmp_dma_runtime_suspend(zdev->dev);
+	pm_runtime_dont_use_autosuspend(zdev->dev);
 	pm_runtime_disable(zdev->dev);
 	return ret;
 }
@@ -1172,6 +1175,7 @@ static void zynqmp_dma_remove(struct platform_device *pdev)
 	zynqmp_dma_chan_remove(zdev->chan);
 	if (pm_runtime_active(zdev->dev))
 		zynqmp_dma_runtime_suspend(zdev->dev);
+	pm_runtime_dont_use_autosuspend(zdev->dev);
 	pm_runtime_disable(zdev->dev);
 }
 
-- 
2.43.0

Re: [PATCH] dmaengine: xilinx: zynqmp_dma: fix autosuspend cleanup during teardown

[Frank Li]

On Sat, Aug 08, 2026 at 07:52:28PM +0800, Guangshuo Li wrote:
> zynqmp_dma_probe() calls pm_runtime_use_autosuspend(), but its failure
> paths and zynqmp_dma_remove() do not call the matching
> pm_runtime_dont_use_autosuspend().
>
> 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.
>
> The documentation for pm_runtime_use_autosuspend() also notes that it
> is important to undo it with pm_runtime_dont_use_autosuspend() at
> driver exit time, unless runtime PM was initially enabled with
> devm_pm_runtime_enable().
>
> Add the missing pm_runtime_dont_use_autosuspend() calls to the probe
> failure and remove paths.
>
> This issue was found by manual code inspection.
>
> Fixes: 64c6f7da8c2c ("dmaengine: zynqmp_dma: Add runtime pm support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
>  drivers/dma/xilinx/zynqmp_dma.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f6a812e49ddc..635c3f6cc5c2 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -1116,8 +1116,10 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
>  	}
>  	if (!pm_runtime_enabled(zdev->dev)) {
>  		ret = zynqmp_dma_runtime_resume(zdev->dev);
> -		if (ret)
> +		if (ret) {
> +			pm_runtime_dont_use_autosuspend(zdev->dev);

Please use devm_runtime_enable() to fix this problem, auto tear down already
include it

static void pm_runtime_disable_action(void *data)
{
	pm_runtime_dont_use_autosuspend(data);
	pm_runtime_disable(data);
}

Frank

>  			return ret;
> +		}
>  	}
>
>  	ret = zynqmp_dma_chan_probe(zdev, pdev);
> @@ -1152,6 +1154,7 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
>  err_disable_pm:
>  	if (!pm_runtime_enabled(zdev->dev))
>  		zynqmp_dma_runtime_suspend(zdev->dev);
> +	pm_runtime_dont_use_autosuspend(zdev->dev);
>  	pm_runtime_disable(zdev->dev);
>  	return ret;
>  }
> @@ -1172,6 +1175,7 @@ static void zynqmp_dma_remove(struct platform_device *pdev)
>  	zynqmp_dma_chan_remove(zdev->chan);
>  	if (pm_runtime_active(zdev->dev))
>  		zynqmp_dma_runtime_suspend(zdev->dev);
> +	pm_runtime_dont_use_autosuspend(zdev->dev);
>  	pm_runtime_disable(zdev->dev);
>  }
>
> --
> 2.43.0
>

Re: [PATCH] dmaengine: xilinx: zynqmp_dma: fix autosuspend cleanup during teardown

[Krzysztof Kozlowski]

On 08/08/2026 13:52, Guangshuo Li wrote:
> zynqmp_dma_probe() calls pm_runtime_use_autosuspend(), but its failure
> paths and zynqmp_dma_remove() do not call the matching
> pm_runtime_dont_use_autosuspend().
> 
> 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.
> 
> The documentation for pm_runtime_use_autosuspend() also notes that it
> is important to undo it with pm_runtime_dont_use_autosuspend() at
> driver exit time, unless runtime PM was initially enabled with
> devm_pm_runtime_enable().
> 
> Add the missing pm_runtime_dont_use_autosuspend() calls to the probe
> failure and remove paths.
> 
> This issue was found by manual code inspection.
> 
> Fixes: 64c6f7da8c2c ("dmaengine: zynqmp_dma: Add runtime pm support")
> 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