[PATCH] dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

[PATCH] dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

[Guangshuo Li]

bam_dma_probe() calls pm_runtime_use_autosuspend(), but
bam_dma_remove() does not call the matching
pm_runtime_dont_use_autosuspend() when removing the device.

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() call before forcing
the device into runtime suspend during removal.

This issue was found by manual code inspection.

Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/dma/qcom/bam_dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 1bb26af0405f..05a3b1f9e0c2 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -1401,6 +1401,7 @@ static void bam_dma_remove(struct platform_device *pdev)
 	struct bam_device *bdev = platform_get_drvdata(pdev);
 	u32 i;
 
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_force_suspend(&pdev->dev);
 
 	of_dma_controller_free(pdev->dev.of_node);
-- 
2.43.0

Re: [PATCH] dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect teardown sequence in `bam_dma_remove()` causes unclocked hardware accesses, tasklet races, and unbalanced clock disables.
- [High] The IRQ handler reads hardware registers before verifying the device is active, risking a crash on spurious interrupts.
--

--- Patch [1]: [PATCH] dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal ---
commit d2172d870f372599d3763db15e5350f372805ea8
Author: Guangshuo Li <lgs201920130244@gmail.com>

dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

This commit adds a missing pm_runtime_dont_use_autosuspend() call in
bam_dma_remove() to properly drop the autosuspend usage count. This prevents
unbalanced usage counts if the autosuspend delay is set to a negative value.

> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 1bb26af0405f3..05a3b1f9e0c23 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1401,6 +1401,7 @@ static void bam_dma_remove(struct platform_device *pdev)
>  	struct bam_device *bdev = platform_get_drvdata(pdev);
>  	u32 i;
>  
> +	pm_runtime_dont_use_autosuspend(&pdev->dev);
>  	pm_runtime_force_suspend(&pdev->dev);

[Severity: High]
This isn't a bug introduced by this patch, but does calling
pm_runtime_force_suspend() here break the teardown sequence?

If the device is active, pm_runtime_force_suspend() forcefully disables the
BAM hardware clock. The driver then immediately accesses hardware via
writel_relaxed() and bam_dma_terminate_all() in bam_dma_remove(), which
can trigger a synchronous bus error:

drivers/dma/qcom/bam_dma.c:bam_dma_remove() {
    ...
    pm_runtime_force_suspend(&pdev->dev);
    ...
    /* mask all interrupts for this execution environment */
    writel_relaxed(0, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
    ...
}

Additionally, does this cause unbalanced clock disables?
pm_runtime_force_suspend() drops the clock enable count to 0, which would
cause the subsequent clk_disable_unprepare(bdev->bamclk) at the end of
bam_dma_remove() to decrement the count to -1 and trigger a clock
framework warning.

>  
>  	of_dma_controller_free(pdev->dev.of_node);

[Severity: High]
This is a pre-existing issue, but does the IRQ handler read hardware registers
before verifying the device is active?

In bam_dma_irq(), process_channel_irqs() is called before pm_runtime_get_sync():

drivers/dma/qcom/bam_dma.c:bam_dma_irq() {
    ...
    srcs |= process_channel_irqs(bdev);
    ...
    ret = pm_runtime_get_sync(bdev->dev);
    ...
}

Inside process_channel_irqs(), it reads hardware registers:

drivers/dma/qcom/bam_dma.c:process_channel_irqs() {
    ...
    srcs = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_SRCS_EE));
    ...
}

If the IRQ handler executes due to a spurious interrupt or shared line while
the device is in a runtime-suspended state (and its clocks are off), could
reading the BAM register cause a bus fault or crash?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260808110642.2770355-1-lgs201920130244@gmail.com?part=1

Re: [PATCH] dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

[Bartosz Golaszewski]

On Sat, 8 Aug 2026 13:06:42 +0200, Guangshuo Li
<lgs201920130244@gmail.com> said:
> bam_dma_probe() calls pm_runtime_use_autosuspend(), but
> bam_dma_remove() does not call the matching
> pm_runtime_dont_use_autosuspend() when removing the device.
>
> 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() call before forcing
> the device into runtime suspend during removal.
>
> This issue was found by manual code inspection.
>
> Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>