* [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels
@ 2026-06-03 11:06 Devendra K Verma
2026-06-03 11:42 ` sashiko-bot
0 siblings, 1 reply; 3+ messages in thread
From: Devendra K Verma @ 2026-06-03 11:06 UTC (permalink / raw)
To: bhelgaas, mani, vkoul, Frank.Li
Cc: dmaengine, linux-kernel, michal.simek, devendra.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
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels
2026-06-03 11:06 [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels Devendra K Verma
@ 2026-06-03 11:42 ` sashiko-bot
2026-06-03 12:41 ` Verma, Devendra
0 siblings, 1 reply; 3+ messages in thread
From: sashiko-bot @ 2026-06-03 11:42 UTC (permalink / raw)
To: Devendra K Verma; +Cc: Frank.Li, dmaengine, vkoul
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
^ permalink raw reply [flat|nested] 3+ messages in thread* RE: [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels
2026-06-03 11:42 ` sashiko-bot
@ 2026-06-03 12:41 ` Verma, Devendra
0 siblings, 0 replies; 3+ messages in thread
From: Verma, Devendra @ 2026-06-03 12:41 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: Frank.Li@kernel.org, dmaengine@vger.kernel.org, vkoul@kernel.org,
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-03 12:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-03 11:06 [PATCH v2] dmaengine: dw-edma: Enable HDMA 64R/W Channels Devendra K Verma
2026-06-03 11:42 ` sashiko-bot
2026-06-03 12:41 ` Verma, Devendra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox