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

[sashiko-bot@kernel.org]

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