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

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] Stack out-of-bounds read and channel mask truncation on 32-bit platforms in HDMA interrupt handler.
- [Medium] Incomplete enablement: DesignWare PCIe controller wrapper still hardcodes an 8-channel limit.

Pre-existing issues:
- [High] Argument swap when reading channel status causes it to access the wrong hardware register.
--

commit 0f2309c78c7292ae29af15b436ce0e4f16f62d96
Author: Devendra K Verma <devendra.verma@amd.com>

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

This patch increases the maximum supported read and write channels from 8 to
64 for the HDMA IP. It updates the channel structs, mask types, and probe
function configuration to accommodate the larger number of channels. It also
defines new HDMA-specific macros to reflect the updated channel counts.

> diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h
> index 902574b1ba867..d12fefbf39524 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.h
> +++ b/drivers/dma/dw-edma/dw-edma-core.h
> @@ -91,8 +91,8 @@ struct dw_edma_chan {
>  
>  struct dw_edma_irq {
>  	struct msi_msg                  msi;
> -	u32				wr_mask;
> -	u32				rd_mask;
> +	u64				wr_mask;
> +	u64				rd_mask;

[Severity: Critical]
Can changing these to u64 cause a stack out-of-bounds read and mask truncation
on 32-bit platforms?

In dw_hdma_v0_core_handle_int(), the local mask variable is still defined as
an unsigned long:

drivers/dma/dw-edma/dw-hdma-v0-core.c:dw_hdma_v0_core_handle_int()
    unsigned long off, mask;

    if (dir == EDMA_DIR_WRITE) {
        total = dw->wr_ch_cnt;
        off = 0;
        mask = dw_irq->wr_mask;
    }
    ...
    for_each_set_bit(pos, &mask, total) {

Assigning the 64-bit dw_irq->wr_mask to the 32-bit local mask variable will
silently truncate the upper 32 bits on 32-bit architectures. Furthermore, if
total is up to 64, won't for_each_set_bit() read past the 4-byte mask
variable into adjacent stack memory, potentially triggering spurious
interrupts or KASAN panics?

[ ... ]

> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> index 632abb8b481cf..d7a3c9a73e9c4 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> @@ -53,13 +53,24 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch)
>  static void dw_hdma_v0_core_off(struct dw_edma *dw)
>  {
>  	int id;
> +	enum dw_edma_dir dir;
> +
> +	dir = EDMA_DIR_WRITE;
> +	for (id = 0; id < dw->wr_ch_cnt; id++) {
> +		SET_CH_32(dw, dir, id, int_setup,
> +			  HDMA_V0_STOP_INT_MASK | HDMA_V0_ABORT_INT_MASK);
> +		SET_CH_32(dw, dir, id, int_clear,
> +			  HDMA_V0_STOP_INT_MASK | HDMA_V0_ABORT_INT_MASK);
> +		SET_CH_32(dw, dir, id, ch_en, 0);
> +	}

[Severity: High]
This isn't a bug introduced by this patch, but does dw_hdma_v0_core_ch_status()
pass arguments to GET_CH_32() in the wrong order?

The macro expects the direction first and the channel index second, but it
is invoked as:

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));

Will this cause the channel ID (now up to 63) to be used as the direction,
and the direction to be used as the channel ID, consistently reading the
status register of the wrong channel?

[ ... ]

> 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: Medium]
Does the DesignWare PCIe controller wrapper also need an update to support
the 64 channels?

In dw_pcie_edma_find_channels(), the initialization still checks against
the 8-channel limit:

drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_edma_find_channels()
    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;

If a host platform's HDMA IP supports and requests more than 8 channels,
won't this hardcoded check fail and return -EINVAL, preventing the
new channels from being used?

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