[PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[Devendra K Verma]

From: Devendra K Verma <devverma@amd.com>

Add Device ID for AMD (Xilinx) CPM6 DMA IP.
This IP enables 64 Read and 64 Write Channels.

Adding the relevant dw_edma_pcie_data to use
8 Read and 8 Write Channels for initial commit.

Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
---
 drivers/dma/dw-edma/dw-edma-pcie.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 0b30ce138503..4ba368d18cb1 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -27,6 +27,7 @@
 
 /* AMD MDB (Xilinx) specific defines */
 #define PCI_DEVICE_ID_XILINX_B054		0xb054
+#define PCI_DEVICE_ID_XILINX_B00F		0xb00f
 
 #define DW_PCIE_XILINX_MDB_VSEC_DMA_ID		0x6
 #define DW_PCIE_XILINX_MDB_VSEC_ID		0x20
@@ -125,6 +126,19 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
 	.rd_ch_cnt			= 8,
 };
 
+static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
+	/* MDB registers location */
+	.rg.bar				= BAR_0,
+	.rg.off				= SZ_4K,	/*  4 Kbytes */
+	.rg.sz				= SZ_8K,	/*  8 Kbytes */
+
+	/* Other */
+	.mf				= EDMA_MF_HDMA_NATIVE,
+	.irqs				= 1,
+	.wr_ch_cnt			= 8,
+	.rd_ch_cnt			= 8,
+};
+
 static void dw_edma_set_chan_region_offset(struct dw_edma_pcie_data *pdata,
 					   enum pci_barno bar, off_t start_off,
 					   off_t ll_off_gap, size_t ll_size,
@@ -547,6 +561,8 @@ static const struct pci_device_id dw_edma_pcie_id_table[] = {
 	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
 	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
 	  (kernel_ulong_t)&xilinx_mdb_data },
+	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
+	  (kernel_ulong_t)&xilinx_cpm6_dma_data },
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
-- 
2.43.0

Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing pci_free_irq_vectors() cleanup on error paths in dw_edma_pcie_probe() leading to IRQ resource leaks.
--

commit a523468dbe7999a5962895c3e0d73662a2938006
Author: Devendra K Verma <devverma@amd.com>

dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

Add Device ID for AMD (Xilinx) CPM6 DMA IP to enable 64 Read and 64 Write
Channels. Adds the relevant dw_edma_pcie_data to use 8 Read and 8 Write
Channels for the initial commit.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 0b30ce1385036..4ba368d18cb1d 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c

[ ... ]

> @@ -547,6 +561,8 @@ static const struct pci_device_id dw_edma_pcie_id_table[] = {
>  	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
>  	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
>  	  (kernel_ulong_t)&xilinx_mdb_data },
> +	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
> +	  (kernel_ulong_t)&xilinx_cpm6_dma_data },

[Severity: High]
This is a pre-existing issue, but adding this new device ID exposes the new
device to an IRQ resource leak in dw_edma_pcie_probe().

When the device is probed, dw_edma_pcie_probe() successfully allocates IRQs via
pci_alloc_irq_vectors(). However, several subsequent error paths return directly
without calling pci_free_irq_vectors().

For example, if the pcim_iomap_table() lookup fails:

drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
    ...
	chip->reg_base = pcim_iomap_table(pdev)[vsec_data->rg.bar];
	if (!chip->reg_base)
		return -ENOMEM;
    ...
}

Or if the main eDMA probe fails later on:

drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
    ...
	err = dw_edma_probe(chip);
	if (err) {
		pci_err(pdev, "eDMA probe failed\n");
		return err;
	}
    ...
}

Does this code leak the allocated IRQ vectors in these error paths? Because IRQs
are a strictly limited resource, repeated probe failures (such as deferred probe
or unbind/rebind cycles) could silently exhaust the system's IRQ capacity. 

Would it make sense to ensure pci_free_irq_vectors() is called on all error
paths after successful allocation before enabling new devices?

>  	{ }
>  };
>  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);

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

RE: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[Verma, Devendra]

Public

The pre-existing issues need to be taken up in a separate series.
The changes require separate testing which is not related to the
current patch.

Regards,
Devendra

> -----Original Message-----
> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> Sent: Wednesday, June 3, 2026 20:15
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: dmaengine@vger.kernel.org; vkoul@kernel.org; Frank.Li@kernel.org;
> linux-pci@vger.kernel.org
> Subject: Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA
> DeviceID
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
>
> Pre-existing issues:
> - [High] Missing pci_free_irq_vectors() cleanup on error paths in
> dw_edma_pcie_probe() leading to IRQ resource leaks.
> --
>
> commit a523468dbe7999a5962895c3e0d73662a2938006
> Author: Devendra K Verma <devverma@amd.com>
>
> dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID
>
> Add Device ID for AMD (Xilinx) CPM6 DMA IP to enable 64 Read and 64 Write
> Channels. Adds the relevant dw_edma_pcie_data to use 8 Read and 8 Write
> Channels for the initial commit.
>
> > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
> > b/drivers/dma/dw-edma/dw-edma-pcie.c
> > index 0b30ce1385036..4ba368d18cb1d 100644
> > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>
> [ ... ]
>
> > @@ -547,6 +561,8 @@ static const struct pci_device_id
> dw_edma_pcie_id_table[] = {
> >     { PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
> >     { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> >       (kernel_ulong_t)&xilinx_mdb_data },
> > +   { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
> > +     (kernel_ulong_t)&xilinx_cpm6_dma_data },
>
> [Severity: High]
> This is a pre-existing issue, but adding this new device ID exposes the new
> device to an IRQ resource leak in dw_edma_pcie_probe().
>
> When the device is probed, dw_edma_pcie_probe() successfully allocates
> IRQs via pci_alloc_irq_vectors(). However, several subsequent error paths
> return directly without calling pci_free_irq_vectors().
>
> For example, if the pcim_iomap_table() lookup fails:
>
> drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
>     ...
>       chip->reg_base = pcim_iomap_table(pdev)[vsec_data->rg.bar];
>       if (!chip->reg_base)
>               return -ENOMEM;
>     ...
> }
>
> Or if the main eDMA probe fails later on:
>
> drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
>     ...
>       err = dw_edma_probe(chip);
>       if (err) {
>               pci_err(pdev, "eDMA probe failed\n");
>               return err;
>       }
>     ...
> }
>
> Does this code leak the allocated IRQ vectors in these error paths? Because
> IRQs are a strictly limited resource, repeated probe failures (such as deferred
> probe or unbind/rebind cycles) could silently exhaust the system's IRQ
> capacity.
>
> Would it make sense to ensure pci_free_irq_vectors() is called on all error
> paths after successful allocation before enabling new devices?
>
> >     { }
> >  };
> >  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260603143158.3243500-
> 1-devendra.verma@amd.com?part=1

Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[Vinod Koul]

On 04-06-26, 12:12, Verma, Devendra wrote:
> Public

Pls do _not_ Top Post!

> 
> The pre-existing issues need to be taken up in a separate series.
> The changes require separate testing which is not related to the
> current patch.

While I agree to that and it wont block the review but would be good if
you can fix that as well. Sure affects your users...

> 
> Regards,
> Devendra
> 
> > -----Original Message-----
> > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > Sent: Wednesday, June 3, 2026 20:15
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: dmaengine@vger.kernel.org; vkoul@kernel.org; Frank.Li@kernel.org;
> > linux-pci@vger.kernel.org
> > Subject: Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA
> > DeviceID
> >
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> > to consider:
> >
> > Pre-existing issues:
> > - [High] Missing pci_free_irq_vectors() cleanup on error paths in
> > dw_edma_pcie_probe() leading to IRQ resource leaks.
> > --
> >
> > commit a523468dbe7999a5962895c3e0d73662a2938006
> > Author: Devendra K Verma <devverma@amd.com>
> >
> > dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID
> >
> > Add Device ID for AMD (Xilinx) CPM6 DMA IP to enable 64 Read and 64 Write
> > Channels. Adds the relevant dw_edma_pcie_data to use 8 Read and 8 Write
> > Channels for the initial commit.
> >
> > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > index 0b30ce1385036..4ba368d18cb1d 100644
> > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> >
> > [ ... ]
> >
> > > @@ -547,6 +561,8 @@ static const struct pci_device_id
> > dw_edma_pcie_id_table[] = {
> > >     { PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
> > >     { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> > >       (kernel_ulong_t)&xilinx_mdb_data },
> > > +   { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
> > > +     (kernel_ulong_t)&xilinx_cpm6_dma_data },
> >
> > [Severity: High]
> > This is a pre-existing issue, but adding this new device ID exposes the new
> > device to an IRQ resource leak in dw_edma_pcie_probe().
> >
> > When the device is probed, dw_edma_pcie_probe() successfully allocates
> > IRQs via pci_alloc_irq_vectors(). However, several subsequent error paths
> > return directly without calling pci_free_irq_vectors().
> >
> > For example, if the pcim_iomap_table() lookup fails:
> >
> > drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
> >     ...
> >       chip->reg_base = pcim_iomap_table(pdev)[vsec_data->rg.bar];
> >       if (!chip->reg_base)
> >               return -ENOMEM;
> >     ...
> > }
> >
> > Or if the main eDMA probe fails later on:
> >
> > drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
> >     ...
> >       err = dw_edma_probe(chip);
> >       if (err) {
> >               pci_err(pdev, "eDMA probe failed\n");
> >               return err;
> >       }
> >     ...
> > }
> >
> > Does this code leak the allocated IRQ vectors in these error paths? Because
> > IRQs are a strictly limited resource, repeated probe failures (such as deferred
> > probe or unbind/rebind cycles) could silently exhaust the system's IRQ
> > capacity.
> >
> > Would it make sense to ensure pci_free_irq_vectors() is called on all error
> > paths after successful allocation before enabling new devices?
> >
> > >     { }
> > >  };
> > >  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
> >
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260603143158.3243500-
> > 1-devendra.verma@amd.com?part=1

-- 
~Vinod

Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6-DMA DeviceID

[Frank Li]

On Wed, Jun 03, 2026 at 08:01:58PM +0530, Devendra K Verma wrote:
> From: Devendra K Verma <devverma@amd.com>
>
> Add Device ID for AMD (Xilinx) CPM6 DMA IP.
> This IP enables 64 Read and 64 Write Channels.
>
> Adding the relevant dw_edma_pcie_data to use
> 8 Read and 8 Write Channels for initial commit.

Nit: wrap at 75 char

>
> Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> ---
>  drivers/dma/dw-edma/dw-edma-pcie.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 0b30ce138503..4ba368d18cb1 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -27,6 +27,7 @@
>
>  /* AMD MDB (Xilinx) specific defines */
>  #define PCI_DEVICE_ID_XILINX_B054		0xb054
> +#define PCI_DEVICE_ID_XILINX_B00F		0xb00f
>
>  #define DW_PCIE_XILINX_MDB_VSEC_DMA_ID		0x6
>  #define DW_PCIE_XILINX_MDB_VSEC_ID		0x20
> @@ -125,6 +126,19 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>  	.rd_ch_cnt			= 8,
>  };
>
> +static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> +	/* MDB registers location */
> +	.rg.bar				= BAR_0,
> +	.rg.off				= SZ_4K,	/*  4 Kbytes */
> +	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> +
> +	/* Other */
> +	.mf				= EDMA_MF_HDMA_NATIVE,
> +	.irqs				= 1,
> +	.wr_ch_cnt			= 8,
> +	.rd_ch_cnt			= 8,
> +};
> +
>  static void dw_edma_set_chan_region_offset(struct dw_edma_pcie_data *pdata,
>  					   enum pci_barno bar, off_t start_off,
>  					   off_t ll_off_gap, size_t ll_size,
> @@ -547,6 +561,8 @@ static const struct pci_device_id dw_edma_pcie_id_table[] = {
>  	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
>  	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
>  	  (kernel_ulong_t)&xilinx_mdb_data },
> +	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
> +	  (kernel_ulong_t)&xilinx_cpm6_dma_data },

Please .driver_data = (kernel_ulong_t)&xilinx_cpm6_dma_data

Now Uwe Kleine-König is cleanup this.

See similar thread
https://lore.kernel.org/linux-i3c/20260504143324.2122737-2-u.kleine-koenig@baylibre.com/

Frank

>  	{ }
>  };
>  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
> --
> 2.43.0
>