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

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

[Devendra K Verma]

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.
Following changes are made to enable 64 Read / 64 Write
channel support:

 o Defined HDMA specific macros to reflect the channel count.
 o The count of ll_regions and dt_regions in dw_edma_chip and
   dw_edma_pcie_data shall be in accordance to number of read
   and write channels.
 o In dw_edma_probe() configure the channels as per the channels
   of the IP used.

Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
---
Changes in v1:
  o On review recommendation of sashiko bot, in the function
    dw_hdma_v0_core_off(), the loop iterates over registers
    as per the number of channels enabled and not on total
    number of channels supported.
  o Changed mask types to u64 for higher channel counts.
---
 drivers/dma/dw-edma/dw-edma-core.c    | 19 +++++++++++++------
 drivers/dma/dw-edma/dw-edma-core.h    |  4 ++--
 drivers/dma/dw-edma/dw-edma-pcie.c    |  8 ++++----
 drivers/dma/dw-edma/dw-hdma-v0-core.c | 23 +++++++++++++++++------
 drivers/dma/dw-edma/dw-hdma-v0-regs.h |  2 +-
 include/linux/dma/edma.h              | 10 ++++++----
 6 files changed, 43 insertions(+), 23 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index c2feb3adc79f..adf1b3939f96 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -925,9 +925,9 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
 		irq = &dw->irq[pos];
 
 		if (chan->dir == EDMA_DIR_WRITE)
-			irq->wr_mask |= BIT(chan->id);
+			irq->wr_mask |= BIT_ULL(chan->id);
 		else
-			irq->rd_mask |= BIT(chan->id);
+			irq->rd_mask |= BIT_ULL(chan->id);
 
 		irq->dw = dw;
 		memcpy(&chan->msi, &irq->msi, sizeof(chan->msi));
@@ -1079,6 +1079,8 @@ int dw_edma_probe(struct dw_edma_chip *chip)
 	struct dw_edma *dw;
 	u32 wr_alloc = 0;
 	u32 rd_alloc = 0;
+	u16 max_wr_cnt;
+	u16 max_rd_cnt;
 	int i, err;
 
 	if (!chip)
@@ -1094,20 +1096,25 @@ int dw_edma_probe(struct dw_edma_chip *chip)
 
 	dw->chip = chip;
 
-	if (dw->chip->mf == EDMA_MF_HDMA_NATIVE)
+	if (dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
 		dw_hdma_v0_core_register(dw);
-	else
+		max_wr_cnt = HDMA_MAX_WR_CH;
+		max_rd_cnt = HDMA_MAX_RD_CH;
+	} else {
 		dw_edma_v0_core_register(dw);
+		max_wr_cnt = EDMA_MAX_WR_CH;
+		max_rd_cnt = EDMA_MAX_RD_CH;
+	}
 
 	raw_spin_lock_init(&dw->lock);
 
 	dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt,
 			      dw_edma_core_ch_count(dw, EDMA_DIR_WRITE));
-	dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH);
+	dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, max_wr_cnt);
 
 	dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt,
 			      dw_edma_core_ch_count(dw, EDMA_DIR_READ));
-	dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH);
+	dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, max_rd_cnt);
 
 	if (!dw->wr_ch_cnt && !dw->rd_ch_cnt)
 		return -EINVAL;
diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h
index 902574b1ba86..d12fefbf3952 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;
 	struct dw_edma			*dw;
 };
 
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 0b30ce138503..79f653da8e0f 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;
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
index 632abb8b481c..d7a3c9a73e9c 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);
+	}
 
-	for (id = 0; id < HDMA_V0_MAX_NR_CH; id++) {
-		SET_BOTH_CH_32(dw, id, int_setup,
-			       HDMA_V0_STOP_INT_MASK | HDMA_V0_ABORT_INT_MASK);
-		SET_BOTH_CH_32(dw, id, int_clear,
-			       HDMA_V0_STOP_INT_MASK | HDMA_V0_ABORT_INT_MASK);
-		SET_BOTH_CH_32(dw, id, ch_en, 0);
+	dir = EDMA_DIR_READ;
+	for (id = 0; id < dw->rd_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);
 	}
 }
 
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-regs.h b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
index 7759ba9b4850..48e40efceb2e 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
+++ b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
@@ -11,7 +11,7 @@
 
 #include <linux/dmaengine.h>
 
-#define HDMA_V0_MAX_NR_CH			8
+#define HDMA_V0_MAX_NR_CH			64
 #define HDMA_V0_CH_EN				BIT(0)
 #define HDMA_V0_LOCAL_ABORT_INT_EN		BIT(6)
 #define HDMA_V0_REMOTE_ABORT_INT_EN		BIT(5)
diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
index 1fafd5b0e315..da7a5cc93ad4 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
 
 struct dw_edma;
 
@@ -89,12 +91,12 @@ struct dw_edma_chip {
 	u16			ll_wr_cnt;
 	u16			ll_rd_cnt;
 	/* link list address */
-	struct dw_edma_region	ll_region_wr[EDMA_MAX_WR_CH];
-	struct dw_edma_region	ll_region_rd[EDMA_MAX_RD_CH];
+	struct dw_edma_region	ll_region_wr[HDMA_MAX_WR_CH];
+	struct dw_edma_region	ll_region_rd[HDMA_MAX_RD_CH];
 
 	/* data region */
-	struct dw_edma_region	dt_region_wr[EDMA_MAX_WR_CH];
-	struct dw_edma_region	dt_region_rd[EDMA_MAX_RD_CH];
+	struct dw_edma_region	dt_region_wr[HDMA_MAX_WR_CH];
+	struct dw_edma_region	dt_region_rd[HDMA_MAX_RD_CH];
 
 	/* interrupt emulation */
 	int			db_irq;
-- 
2.43.0

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

[sashiko-bot]

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

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

[Verma, Devendra]

Public

Hi

Please reach comments inline.

Regards,
Devendra

> -----Original Message-----
> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> Sent: Wednesday, June 3, 2026 17:12
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: Frank.Li@kernel.org; dmaengine@vger.kernel.org; vkoul@kernel.org
> Subject: Re: [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels
>
> 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?
>
> [ ... ]
>

Yes, this is valid concern, shall be fixed in next version.

> > 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?
>
> [ ... ]
>

This is pre-existing bug, not caused by my commit. Though, I will try to fix this
as well.

> > 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?
>

No, the above snippet shared is specifically meant for non-HDMA IPs. The non-HDMA
and lesser variants support upto 8 channels only so the concerned raised is not applicable.
This will not cause any functionality breakage. There is no change required here.

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