Re: [PATCH 06/28] ALSA: dmaengine: Always terminate DMA when a PCM is closed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ALSA: dmaengine: double-termination and dead code in __snd_dmaengine_pcm_close()
--

commit 6131d1de92af956678d470a7a7f214c9985a5ad4
Author: Hector Martin <marcan@marcan.st>

ALSA: dmaengine: Always terminate DMA when a PCM is closed

This commit updates __snd_dmaengine_pcm_close() to ensure that the DMA
channel is properly terminated even if the PCM is closed while suspended.

> diff --git a/sound/core/pcm_dmaengine.c b/sound/core/pcm_dmaengine.c
> index 1306b04be171a..e59b561b849d2 100644
> --- a/sound/core/pcm_dmaengine.c
> +++ b/sound/core/pcm_dmaengine.c
[ ... ]
> @@ -355,6 +355,11 @@ static void __snd_dmaengine_pcm_close(struct snd_pcm_substream *substream,
>  	if (status == DMA_PAUSED)
>  		dmaengine_terminate_async(prtd->dma_chan);
>  
> +	/*
> +	 * The PCM might have been closed while suspended, which would
> +	 * skip the STOP trigger. Make sure we terminate.
> +	 */
> +	dmaengine_terminate_async(prtd->dma_chan);

[Severity: Medium]
Does this result in a double-termination when the DMA status is DMA_PAUSED?

Since dmaengine_terminate_async(prtd->dma_chan) is now called
unconditionally, the preceding dmaengine_tx_status() check and the initial
termination call appear to be redundant.

Could this double-termination sequence cause unexpected behavior in DMA
drivers that do not handle consecutive termination calls gracefully?

>  	dmaengine_synchronize(prtd->dma_chan);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920-macaudio-v1-0-741cc20a74e5@gmail.com?part=6