Re: [PATCH v18 03/14] dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Race condition during device removal can lead to unclocked register accesses and system crash because the workqueue is canceled after hardware is suspended.
--

commit b9a9d75f58c32f4c8ef9136a87ab0247a418dd26
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue

This commit converts the BAM DMA driver to use the high-priority variant of
the BH workqueue instead of legacy tasklets for starting DMA transactions.

> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index b3d36ea799843..1c62f845ac0b9 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
[ ... ]
> @@ -1394,7 +1394,7 @@ static void bam_dma_remove(struct platform_device *pdev)
>  			    bdev->channels[i].fifo_phys);
>  	}
>  
> -	tasklet_kill(&bdev->task);
> +	cancel_work_sync(&bdev->work);

[Severity: High]
This is a pre-existing issue, but can this ordering lead to a race condition
during device removal?

Earlier in bam_dma_remove(), pm_runtime_force_suspend() is called. This
forces the device into suspend and disables its clocks without waiting for
active runtime PM references to drop.

If the work queue is executing concurrently and acquires a PM reference via
pm_runtime_get_sync() just before the forceful suspend, will it proceed to
access BAM hardware registers in bam_start_dma() after the clocks have
been disabled?

Accessing unclocked registers on ARM/QCOM platforms typically causes
asynchronous external aborts or bus errors resulting in a kernel panic.
Should the background work be explicitly canceled before shutting down the
hardware?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com?part=3