Re: [PATCH v3 5/9] dmaengine: dw-edma: Serialize channel state checks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] `dw_edma_device_terminate_all()` fails to actually stop the DMA hardware engine, leaving it vulnerable to permanent hangs if the hardware stalls.
- [High] The driver advertises `DMA_CYCLIC` support and accepts cyclic transfers, but fails to implement true infinite looping or fire the required period completion callbacks.
--

--- Patch [5]: [PATCH v3 5/9] dmaengine: dw-edma: Serialize channel state checks ---
commit 1467b5248fd39f737e5901d6f209dccdfffd622e
Author: Koichiro Den <den@valinux.co.jp>

dmaengine: dw-edma: Serialize channel state checks

The commit fixes a race condition between pause()/resume() and interrupt 
handlers by extending vc.lock coverage to include channel state checks. 
This prevents the channel from becoming permanently wedged due to missed state 
updates, and ensures issue_pending() uses the correct configuration state.

> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index b06b299661c02..8b0e2af734da9 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but does dw_edma_device_terminate_all() fail to
actually stop the DMA hardware engine?

If the hardware stalls (e.g., due to an unresponsive peripheral or AXI bus 
hang), it looks like the DMA channel could become permanently wedged. When a
client calls dmaengine_terminate_all() to abort a transfer, the code sets a
software flag:

drivers/dma/dw-edma/dw-edma-core.c:dw_edma_device_terminate_all() {
    ...
    } else if (chan->request > EDMA_REQ_PAUSE) {
        err = -EPERM;
    } else {
        chan->request = EDMA_REQ_STOP;
    }
    ...
}

Will this cause the polling loop in dw_edma_wait_termination() to time out 
if the hardware is stalled and the interrupt never fires? Should the hardware 
be explicitly stopped rather than relying exclusively on natural completion?

[Severity: High]
This is a pre-existing issue, but does the driver fail to implement true 
infinite looping for DMA_CYCLIC transfers?

When a client submits a cyclic transfer via device_prep_dma_cyclic(), it is 
unrolled into a finite list of bursts based on xfer.cyclic.cnt. However, in 
dw_edma_done_interrupt(), the descriptor appears to be completely finished 
without calling vchan_cyclic_callback(vd):

drivers/dma/dw-edma/dw-edma-core.c:dw_edma_done_interrupt() {
    ...
    case EDMA_REQ_PAUSE:
        desc = vd2dw_edma_desc(vd);
        if (!desc->chunks_alloc) {
            dw_hdma_set_callback_result(vd,
                                        DMA_TRANS_NOERROR);
            list_del(&vd->node);
            vchan_cookie_complete(vd);
        }
    ...
}

Will this cause subsystems relying on cyclic DMA (like ALSA for audio) to hang 
indefinitely while waiting for period completion events?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715175740.1110404-1-den@valinux.co.jp?part=5