Re: [PATCH v6] dmaengine: dw-axi-dmac: report paused state and residue in tx_status

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dmaengine: false block matching on overlapping physical memory
--

commit 401af67dfb5740614a39aa65705b156a731bba3f
Author: Rui Wang <wr574332525@163.com>
Subject: dmaengine: dw-axi-dmac: report paused state and residue in tx_status

This commit updates device_tx_status to report the paused state when
appropriate. It also improves the residue computation for in-flight
transfers by reading the current hardware pointer to calculate the
transferred bytes, rather than relying solely on completed block counts.

> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index eebed2474210d..0fa97b83be828 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c

[ ... ]

> @@ -352,33 +352,110 @@ static void vchan_desc_put(struct virt_dma_desc *vdesc)

[ ... ]

> +static u32 axi_chan_get_xferred(struct axi_dma_chan *chan,
> +				struct axi_dma_desc *desc)
> +{
> +	struct axi_dma_hw_desc *hw_desc;
> +	bool dst = chan->direction == DMA_DEV_TO_MEM;
> +	u64 pos, start;
> +	u32 xferred = 0;
> +	int i;
> +
> +	pos = axi_chan_readq(chan, dst ? CH_DAR : CH_SAR);
> +
> +	for (i = 0; i < desc->nr_hw_descs; i++) {
> +		hw_desc = &desc->hw_desc[i];
> +		start = le64_to_cpu(dst ? hw_desc->lli->dar : hw_desc->lli->sar);
> +
> +		/* Current position is inside this block: partial progress */
> +		if (pos >= start && pos <= start + hw_desc->len)
> +			return xferred + (u32)(pos - start);

[Severity: Medium]
Will this condition falsely match the wrong block if a scatter-gather list
maps the same physical address multiple times?

If a client driver submits a multi-block scatter-gather list with overlapping
physical memory regions (such as repeating a single dummy zero-page for SPI
TX/RX), this linear scan could match an earlier block in the list while the
hardware is actually executing a later block.

Does this mask actual progress and cause the reported transferred byte count
to repeatedly loop back to 0, corrupting the residue computation when queried
via dmaengine_tx_status()?

> +
> +		xferred += hw_desc->len;
> +	}
> +
> +	/* Position doesn't match any block, be conservative */
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928035133.2046-1-wr574332525@163.com?part=1