Re: [PATCH RESEND v4] 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:
- [High] Incomplete hardware reset during initialization leaves unallocated active channels unmasked and uncleared, leading to an IRQ storm.
- [High] The patch claims to enable 64 channels but fails to update integration layers, leaving hardcoded 8-channel limits that prevent utilization and break probing.

Pre-existing issues:
- [High] The GET_CH_32 macro is called with swapped `dir` and `ch` arguments in `dw_hdma_v0_core_ch_status()`, reading the wrong register.
--

commit 973288f2abf5c733055723f7bd6942953badd2e0
Author: Devendra K Verma <devendra.verma@amd.com>

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

This patch updates the dw-edma driver to support 64 read and write channels
for HDMA. It defines new macros for the maximum channel counts, scales up
internal data structures, and changes channel masks to 64-bit types to
accommodate the increased capacity.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 0b30ce1385036..79f653da8e0fd 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -61,11 +61,11 @@ struct dw_edma_pcie_data {
>  	/* eDMA registers location */
>  	struct dw_edma_block		rg;
>  	/* eDMA memory linked list location */
> -	struct dw_edma_block		ll_wr[EDMA_MAX_WR_CH];
> -	struct dw_edma_block		ll_rd[EDMA_MAX_RD_CH];
> +	struct dw_edma_block		ll_wr[HDMA_MAX_WR_CH];
> +	struct dw_edma_block		ll_rd[HDMA_MAX_RD_CH];
>  	/* eDMA memory data location */
> -	struct dw_edma_block		dt_wr[EDMA_MAX_WR_CH];
> -	struct dw_edma_block		dt_rd[EDMA_MAX_RD_CH];
> +	struct dw_edma_block		dt_wr[HDMA_MAX_WR_CH];
> +	struct dw_edma_block		dt_rd[HDMA_MAX_RD_CH];
>  	/* Other */
>  	enum dw_edma_map_format		mf;
>  	u8				irqs;

[Severity: High]
Does this successfully enable 64 channels if the integration layers still
enforce an 8-channel limit?

For example, in drivers/pci/controller/dwc/pcie-designware.c
dw_pcie_edma_find_channels() checks 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 drivers/dma/dw-edma/dw-edma-pcie.c dw_edma_pcie_get_synopsys_dma_data()
clamps capabilities to defaults:

    pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
                             FIELD_GET(DW_PCIE_SYNOPSYS_VSEC_DMA_WR_CH, val));

If a device actually reports 64 channels, won't probe fail immediately
because the PCIe wrapper bounds checks against EDMA_MAX_WR_CH (8) instead of
HDMA_MAX_WR_CH (64)?

> 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
> @@ -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]
Can changing this loop in dw_hdma_v0_core_off() from a fixed hardware maximum
to the software-allocated count dw->wr_ch_cnt lead to an IRQ storm?

If a bootloader or previous kernel instance leaves channels greater than
dw->wr_ch_cnt active, won't they remain unmasked and unhandled?

Because dw_hdma_v0_core_handle_int() bounds the interrupt checking mask:

    while (mask) {
        pos = __ffs64(mask);
        if (pos >= total)
            break;

Any unallocated active channel might repeatedly raise hardware interrupts
without ever being cleared.

[Severity: High]
This is a pre-existing issue, but in dw_hdma_v0_core_ch_status() in
drivers/dma/dw-edma/dw-hdma-v0-core.c, does the GET_CH_32 macro have the
arguments swapped?

    tmp = FIELD_GET(HDMA_V0_CH_STATUS_MASK,
                    GET_CH_32(dw, chan->id, chan->dir, ch_stat));

The GET_CH_32 macro expects (dw, dir, ch, name). If chan->id is passed as dir,
won't __dw_ch_regs() evaluate dir as non-write (0) for any channel ID greater
than 0, causing it to always read from channel 0 or 1's read registers?

[ ... ]

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