Re: [PATCH v4] dmaengine: dw-edma: Enable HDMA 64R/W Channels

[sashiko-bot@kernel.org]

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

New issues:
- [High] The DesignWare PCIe controller driver (`pcie-designware.c`) was not updated to reflect the new 64-channel limits for HDMA, breaking configurations that declare more than 8 channels.

Pre-existing issues:
- [High] The function `dw_hdma_v0_core_ch_status()` calls `GET_CH_32` with swapped `dir` and `ch` parameters, resulting in incorrect channel status reads.
--

commit 49f2923c673f70626e15a62547f82ae4f0d06439
Author: Devendra K Verma <devendra.verma@amd.com>

dmaengine: dw-edma: Enable HDMA 64R/W Channels

As per 'Designware Cores PCI Express Controller Databook',
Section 7.1 - Overview, HDMA supports 64 Read and 64 Write
channels. Current controller driver supports up to 8 read and
write channels only. In order to utilize all the channels the
controller driver need to have the channel related structs
and variables as per the number of channels supported by IP.

[ ... ]

> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> index 632abb8b481cf..84b0076f78bf0 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c

[Severity: High]
This is a pre-existing issue, but there appears to be a parameter ordering
bug in dw_hdma_v0_core_ch_status() in this file that breaks channel status
reads:

drivers/dma/dw-edma/dw-hdma-v0-core.c:dw_hdma_v0_core_ch_status() {
	...
	tmp = FIELD_GET(HDMA_V0_CH_STATUS_MASK,
			GET_CH_32(dw, chan->id, chan->dir, ch_stat));
	...
}

The GET_CH_32 macro expects arguments in the order (dw, dir, ch, name).
Because it is called with chan->id as the direction and chan->dir as the
channel ID, does this cause the driver to read the DMA status of the wrong
channel, potentially leading to missing completions or data corruption?

[ ... ]

> diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> index 1fafd5b0e3153..da7a5cc93ad43 100644
> --- a/include/linux/dma/edma.h
> +++ b/include/linux/dma/edma.h
> @@ -14,6 +14,8 @@
>  
>  #define EDMA_MAX_WR_CH                                  8
>  #define EDMA_MAX_RD_CH                                  8
> +#define HDMA_MAX_WR_CH                                  64
> +#define HDMA_MAX_RD_CH                                  64

[Severity: High]
Does this patch miss updating the bounds checking in the PCIe controller
driver to use the new HDMA channel limits?

In drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_edma_find_channels(),
there is a hardcoded sanity check against EDMA_MAX_WR_CH:

	if (!pci->edma.ll_wr_cnt || pci->edma.ll_wr_cnt > EDMA_MAX_WR_CH ||
	    !pci->edma.ll_rd_cnt || pci->edma.ll_rd_cnt > EDMA_MAX_RD_CH)
		return -EINVAL;

And in dw_pcie_edma_irq_vector(), it limits IRQ allocation to the old maximum:

	if (nr >= EDMA_MAX_WR_CH + EDMA_MAX_RD_CH)
		return -EINVAL;

Will this cause any native HDMA PCIe controller declaring more than 8
channels to fail instantiation or IRQ allocation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608112011.3289409-1-devendra.verma@amd.com?part=1