[PATCH 0/6] dmaengine: zynqmp_dma: Fix error paths and follow-up cleanups

[PATCH 0/6] dmaengine: zynqmp_dma: Fix error paths and follow-up cleanups

[Golla Nagendra]

This series fixes error-path cleanup issues in alloc/probe flows and
applies follow-up cleanups in the Xilinx ZynqMP DMA driver.

Patch 1 fixes alloc_chan_resources() rollback after runtime PM has been
acquired, including software descriptor pool cleanup on coherent
allocation failure.

Patch 2 fixes channel probe/remove error handling by preserving
platform_get_irq() errors, initializing/staging chan->irq safely, and
registering the channel node only after IRQ setup succeeds.

Patch 3 updates stale kerneldoc comments to match current behavior.

Patch 4 applies minor whitespace formatting cleanup in
zynqmp_dma_chan_probe().

Patch 5 rejects zero-length memcpy preparations and documents the return
behavior.

Patch 6 removes an unused define and drops a duplicate interrupt enable
bit from the default IRQ mask.


Golla Nagendra (6):
  dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup
  dmaengine: zynqmp_dma: Fix chan probe error handling
  dmaengine: zynqmp_dma: Fix stale kerneldoc comments
  dmaengine: zynqmp_dma: Fix minor whitespace
  dmaengine: zynqmp_dma: Reject zero-length memcpy transfers
  dmaengine: zynqmp_dma: Remove unused define and duplicate IRQ bit

 drivers/dma/xilinx/zynqmp_dma.c | 72 +++++++++++++++++++++------------
 1 file changed, 46 insertions(+), 26 deletions(-)

-- 
2.43.7

[PATCH 1/6] dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup

[Golla Nagendra]

Channel resource allocation can fail after runtime PM has been acquired
and after part of the descriptor state has been initialized. Without
proper rollback, the error path leaks a runtime PM reference and, on
coherent allocation failure, also leaks the software descriptor pool.

Fix this by balancing runtime PM usage before returning an error and
releasing any partially allocated software descriptor pool.

Fixes: 8982d48af36d ("dmaengine: zynqmp_dma: Fix PM reference leak in zynqmp_dma_alloc_chan_resourc()")
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index f6a812e49ddc..b7c561280694 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -483,8 +483,10 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
 		return ret;
 
 	chan->sw_desc_pool = kzalloc_objs(*desc, ZYNQMP_DMA_NUM_DESCS);
-	if (!chan->sw_desc_pool)
-		return -ENOMEM;
+	if (!chan->sw_desc_pool) {
+		ret = -ENOMEM;
+		goto err_pm;
+	}
 
 	chan->idle = true;
 	chan->desc_free_cnt = ZYNQMP_DMA_NUM_DESCS;
@@ -502,8 +504,10 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
 					       (2 * ZYNQMP_DMA_DESC_SIZE(chan) *
 					       ZYNQMP_DMA_NUM_DESCS),
 					       &chan->desc_pool_p, GFP_KERNEL);
-	if (!chan->desc_pool_v)
-		return -ENOMEM;
+	if (!chan->desc_pool_v) {
+		ret = -ENOMEM;
+		goto err_free_sw_desc_pool;
+	}
 
 	for (i = 0; i < ZYNQMP_DMA_NUM_DESCS; i++) {
 		desc = chan->sw_desc_pool + i;
@@ -516,6 +520,13 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
 	}
 
 	return ZYNQMP_DMA_NUM_DESCS;
+
+err_free_sw_desc_pool:
+	kfree(chan->sw_desc_pool);
+	chan->sw_desc_pool = NULL;
+err_pm:
+	pm_runtime_put_autosuspend(chan->dev);
+	return ret;
 }
 
 /**
-- 
2.43.7

[PATCH 2/6] dmaengine: zynqmp_dma: Fix chan probe error handling

[Golla Nagendra]

Keep the real platform_get_irq() error value by returning ret directly,
initialize chan->irq to -1, and only assign chan->irq after
devm_request_irq() succeeds. In remove, free IRQ only for valid numbers
and delete device_node only when linked.

Move channel list registration to after successful IRQ registration,
initialize device_node list head during probe setup, and kill the
tasklet in the outer probe failure path when channel probe fails.

Fixes: b0cc417c1637 ("dmaengine: Add Xilinx zynqmp dma engine driver support")
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index b7c561280694..f7e4a177bd17 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -205,7 +205,7 @@ struct zynqmp_dma_desc_sw {
  * @desc_pool_p: Physical allocated descriptor base
  * @desc_free_cnt: Descriptor available count
  * @dev: The dma device
- * @irq: Channel IRQ
+ * @irq: Linux IRQ number, or -1 when not registered
  * @is_dmacoherent: Tells whether dma operations are coherent or not
  * @tasklet: Cleanup work after irq
  * @idle : Channel status;
@@ -896,10 +896,11 @@ static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
 	if (!chan)
 		return;
 
-	if (chan->irq)
+	if (chan->irq >= 0)
 		devm_free_irq(chan->zdev->dev, chan->irq, chan);
 	tasklet_kill(&chan->tasklet);
-	list_del(&chan->common.device_node);
+	if (!list_empty(&chan->common.device_node))
+		list_del(&chan->common.device_node);
 }
 
 /**
@@ -915,13 +916,14 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
 	struct zynqmp_dma_chan *chan;
 	struct device_node *node = pdev->dev.of_node;
 	const struct zynqmp_dma_config *match_data;
-	int err;
+	int err, ret;
 
 	chan = devm_kzalloc(zdev->dev, sizeof(*chan), GFP_KERNEL);
 	if (!chan)
 		return -ENOMEM;
 	chan->dev = zdev->dev;
 	chan->zdev = zdev;
+	chan->irq = -1;
 
 	chan->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(chan->regs))
@@ -954,22 +956,26 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
 	INIT_LIST_HEAD(&chan->pending_list);
 	INIT_LIST_HEAD(&chan->done_list);
 	INIT_LIST_HEAD(&chan->free_list);
+	INIT_LIST_HEAD(&chan->common.device_node);
 
 	dma_cookie_init(&chan->common);
 	chan->common.device = &zdev->common;
-	list_add_tail(&chan->common.device_node, &zdev->common.channels);
-
 	zynqmp_dma_init(chan);
-	chan->irq = platform_get_irq(pdev, 0);
-	if (chan->irq < 0)
-		return -ENXIO;
-	err = devm_request_irq(&pdev->dev, chan->irq, zynqmp_dma_irq_handler, 0,
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		return ret;
+
+	err = devm_request_irq(&pdev->dev, ret, zynqmp_dma_irq_handler, 0,
 			       "zynqmp-dma", chan);
 	if (err)
 		return err;
 
+	chan->irq = ret;
+
 	chan->desc_size = sizeof(struct zynqmp_dma_desc_ll);
 	chan->idle = true;
+	list_add_tail(&chan->common.device_node, &zdev->common.channels);
+
 	return 0;
 }
 
@@ -1134,6 +1140,8 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
 	ret = zynqmp_dma_chan_probe(zdev, pdev);
 	if (ret) {
 		dev_err_probe(&pdev->dev, ret, "Probing channel failed\n");
+		if (zdev->chan)
+			tasklet_kill(&zdev->chan->tasklet);
 		goto err_disable_pm;
 	}
 
-- 
2.43.7

[PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments

[Golla Nagendra]

Correct kerneldoc comments that no longer matched the code.

Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index f7e4a177bd17..c5b05fd52e9d 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -208,7 +208,7 @@ struct zynqmp_dma_desc_sw {
  * @irq: Linux IRQ number, or -1 when not registered
  * @is_dmacoherent: Tells whether dma operations are coherent or not
  * @tasklet: Cleanup work after irq
- * @idle : Channel status;
+ * @idle: Channel status
  * @desc_size: Size of the low level descriptor
  * @err: Channel has errors
  * @bus_width: Bus width
@@ -435,7 +435,7 @@ zynqmp_dma_get_descriptor(struct zynqmp_dma_chan *chan)
 }
 
 /**
- * zynqmp_dma_free_descriptor - Issue pending transactions
+ * zynqmp_dma_free_descriptor - Return a descriptor to the free pool
  * @chan: ZynqMP DMA channel pointer
  * @sdesc: Transaction descriptor pointer
  */
@@ -617,7 +617,6 @@ static void zynqmp_dma_start_transfer(struct zynqmp_dma_chan *chan)
 	zynqmp_dma_start(chan);
 }
 
-
 /**
  * zynqmp_dma_chan_desc_cleanup - Cleanup the completed descriptors
  * @chan: ZynqMP DMA channel
@@ -908,7 +907,7 @@ static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
  * @zdev: Driver specific device structure
  * @pdev: Pointer to the platform_device structure
  *
- * Return: '0' on success and failure value on error
+ * Return: 0 on success and negative error code on failure
  */
 static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
 			   struct platform_device *pdev)
@@ -1042,11 +1041,11 @@ static int __maybe_unused zynqmp_dma_runtime_suspend(struct device *dev)
 }
 
 /**
- * zynqmp_dma_runtime_resume - Runtime suspend method for the driver
+ * zynqmp_dma_runtime_resume - Runtime resume method for the driver
  * @dev:	Address of the device structure
  *
- * Put the driver into low power mode.
- * Return: 0 always
+ * Enable device clocks.
+ * Return: 0 on success and failure value on error
  */
 static int __maybe_unused zynqmp_dma_runtime_resume(struct device *dev)
 {
-- 
2.43.7

[PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace

[Golla Nagendra]

Fix minor whitespace formatting in zynqmp_dma_chan_probe().

Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index c5b05fd52e9d..2d56ea08ce45 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -947,7 +947,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
 	if (match_data)
 		chan->irq_offset = match_data->offset;
 
-	chan->is_dmacoherent =  of_property_read_bool(node, "dma-coherent");
+	chan->is_dmacoherent = of_property_read_bool(node, "dma-coherent");
 	zdev->chan = chan;
 	tasklet_setup(&chan->tasklet, zynqmp_dma_do_tasklet);
 	spin_lock_init(&chan->lock);
@@ -959,6 +959,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
 
 	dma_cookie_init(&chan->common);
 	chan->common.device = &zdev->common;
+
 	zynqmp_dma_init(chan);
 	ret = platform_get_irq(pdev, 0);
 	if (ret < 0)
-- 
2.43.7

[PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers

[Golla Nagendra]

Zero-length prep_memcpy() needlessly consumed a descriptor slot. Reject
zero-length memcpy at prep time and document the behaviour.

Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index 2d56ea08ce45..e70874d65123 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -836,7 +836,8 @@ static void zynqmp_dma_synchronize(struct dma_chan *dchan)
  * @len: Transfer length
  * @flags: transfer ack flags
  *
- * Return: Async transaction descriptor on success and NULL on failure
+ * Return: Async transaction descriptor on success and NULL on failure or
+ *	   zero length transfer
  */
 static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
 				struct dma_chan *dchan, dma_addr_t dma_dst,
@@ -851,6 +852,9 @@ static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
 
 	chan = to_chan(dchan);
 
+	if (!len)
+		return NULL;
+
 	desc_cnt = DIV_ROUND_UP(len, ZYNQMP_DMA_MAX_TRANS_LEN);
 
 	spin_lock_irqsave(&chan->lock, irqflags);
-- 
2.43.7

[PATCH 6/6] dmaengine: zynqmp_dma: Remove unused define and duplicate IRQ bit

[Golla Nagendra]

Remove the unused ZYNQMP_DMA_SRC_ISSUE_RST_VAL define.
ZYNQMP_DMA_DST_DSCR_DONE was also set twice in the default interrupt enable
mask; remove the duplicate bit.

Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
 drivers/dma/xilinx/zynqmp_dma.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index e70874d65123..fd2dee4ea17f 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -112,8 +112,7 @@
 #define ZYNQMP_DMA_INT_DONE	(ZYNQMP_DMA_DONE | ZYNQMP_DMA_DST_DSCR_DONE)
 #define ZYNQMP_DMA_INT_EN_DEFAULT_MASK	(ZYNQMP_DMA_INT_DONE | \
 					ZYNQMP_DMA_INT_ERR | \
-					ZYNQMP_DMA_INT_OVRFL | \
-					ZYNQMP_DMA_DST_DSCR_DONE)
+					ZYNQMP_DMA_INT_OVRFL)
 
 /* Max number of descriptors per channel */
 #define ZYNQMP_DMA_NUM_DESCS	32
@@ -128,8 +127,6 @@
 /* Reset values for data attributes */
 #define ZYNQMP_DMA_AXCACHE_VAL		0xF
 
-#define ZYNQMP_DMA_SRC_ISSUE_RST_VAL	0x1F
-
 #define ZYNQMP_DMA_IDS_DEFAULT_MASK	0xFFF
 
 /* Bus width in bits */
-- 
2.43.7

Re: [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace

[sashiko-bot]

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

Pre-existing issues:
- [High] PM runtime usage counter and hardware clocks leak in `zynqmp_dma_probe` error path.
--

--- Patch [4]: [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace ---
commit 990948221cda48a26b5380f5bdf1dcf6dfa5ba05
Author: Golla Nagendra <nagendra.golla@amd.com>

dmaengine: zynqmp_dma: Fix minor whitespace

This commit fixes minor whitespace formatting in zynqmp_dma_chan_probe().

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c

[ ... ]

> @@ -959,6 +959,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  
>  	dma_cookie_init(&chan->common);
>  	chan->common.device = &zdev->common;
> +
>  	zynqmp_dma_init(chan);
>  	ret = platform_get_irq(pdev, 0);
>  	if (ret < 0)

[Severity: High]
This isn't a bug introduced by this patch, but if platform_get_irq() fails
here and returns an error like -EPROBE_DEFER, does the caller leak the PM
runtime usage count and hardware clocks?

Looking at the caller zynqmp_dma_probe(), the error path seems to miss
dropping the usage count (e.g., via pm_runtime_put_noidle() or
pm_runtime_put_sync()):

zynqmp_dma_probe() {
        ...
        ret = zynqmp_dma_chan_probe(zdev, pdev);
        if (ret)
                goto err_disable_pm;
        ...
err_disable_pm:
        if (!pm_runtime_enabled(zdev->dev))
                zynqmp_dma_runtime_suspend(zdev->dev);
        pm_runtime_disable(zdev->dev);
        return ret;
}

Since probe deferral is a common event during system boot, could repeated
deferrals continually leak the PM usage count and permanently leave the DMA
hardware clocks enabled, preventing the device from being runtime suspended?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806123014.2120447-1-nagendra.golla@amd.com?part=4

Re: [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments

[sashiko-bot]

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

Pre-existing issues:
- [High] Double-free and list corruption due to dropping the lock during safe list traversal in zynqmp_dma_chan_desc_cleanup.
--

--- Patch [3]: [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments ---
commit 3c8d64c77aae165a12708426042a7a72be1ba044
Author: Golla Nagendra <nagendra.golla@amd.com>

dmaengine: zynqmp_dma: Fix stale kerneldoc comments

This commit updates various kerneldoc comments across the zynqmp_dma driver.
It corrects parameter descriptions and return values that no longer matched
the actual code implementation.

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f7e4a177bd17e..c5b05fd52e9d8 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c

[ ... ]

> @@ -617,7 +617,6 @@ static void zynqmp_dma_start_transfer(struct zynqmp_dma_chan *chan)
>  	zynqmp_dma_start(chan);
>  }
>  
> -
>  /**
>   * zynqmp_dma_chan_desc_cleanup - Cleanup the completed descriptors
>   * @chan: ZynqMP DMA channel

[Severity: High]
This is a pre-existing issue, but can dropping the lock during safe list
traversal in zynqmp_dma_chan_desc_cleanup() cause a double-free or list
corruption?

If CPU1 is running zynqmp_dma_chan_desc_cleanup(), it drops chan->lock
to invoke the callback:

	list_for_each_entry_safe(desc, next, &chan->done_list, node) {
		...
		if (dmaengine_desc_callback_valid(&cb)) {
			spin_unlock_irqrestore(&chan->lock, irqflags);
			dmaengine_desc_callback_invoke(&cb, NULL);
			spin_lock_irqsave(&chan->lock, irqflags);
		}

While the lock is dropped, if a concurrent call to
zynqmp_dma_device_terminate_all() on CPU2 acquires the lock and frees
the descriptors, it would move all items from done_list to free_list.

When CPU1 reacquires the lock, it calls zynqmp_dma_free_descriptor(chan, desc)
on the already freed desc. This would double-increment chan->desc_free_cnt.
Furthermore, the loop would continue using the cached next pointer which
is now part of the free_list, potentially causing it to traverse the wrong
list and process freed descriptors.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806123014.2120447-1-nagendra.golla@amd.com?part=3

Re: [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Dropping the channel lock during descriptor cleanup allows a concurrent `terminate_all` call to silently corrupt list traversal, resulting in double-frees and infinite loops.
- [High] DMA hardware is not stopped in `zynqmp_dma_device_terminate_all`, risking memory corruption when descriptors are freed.
- [High] Unbinding the device via sysfs while a DMA client is active will cause a Use-After-Free due to `devm_kzalloc` misuse.
- [High] Integer overflow and truncation in `desc_cnt` calculation allows an arbitrarily large transfer length to bypass descriptor availability checks, leading to list corruption.
--

--- Patch [5]: [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers ---
commit 6cf35d097f62dcd5d2c9ce20c7eb0a221c5be776
Author: Golla Nagendra <nagendra.golla@amd.com>

dmaengine: zynqmp_dma: Reject zero-length memcpy transfers

Zero-length prep_memcpy() needlessly consumed a descriptor slot. Reject
zero-length memcpy at prep time and document the behaviour.

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index 2d56ea08ce45a..e70874d651231 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
[ ... ]
> @@ -851,6 +852,9 @@ static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
>  
>  	chan = to_chan(dchan);
>  
> +	if (!len)
> +		return NULL;
> +
>  	desc_cnt = DIV_ROUND_UP(len, ZYNQMP_DMA_MAX_TRANS_LEN);
>  
>  	spin_lock_irqsave(&chan->lock, irqflags);

[Severity: High]
This isn't a bug introduced by this patch, but does this size calculation allow
arbitrary lengths to bypass descriptor availability checks?

If a client driver passes a very large len (e.g., SIZE_MAX) to
zynqmp_dma_prep_memcpy(), the calculation
DIV_ROUND_UP(len, ZYNQMP_DMA_MAX_TRANS_LEN) might overflow the 64-bit integer,
resulting in a quotient of 0.

The check (desc_cnt > chan->desc_free_cnt) would then pass, and the subsequent
loop could unconditionally pop from the free_list billions of times, leading to
list underflow and out-of-bounds writes.

While reviewing this code, I also noticed a few other pre-existing issues in
this driver:

[Severity: High]
This is a pre-existing issue, but does zynqmp_dma_device_terminate_all()
safely stop the hardware before freeing descriptors?

drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_device_terminate_all() {
    ...
    writel(ZYNQMP_DMA_IDS_DEFAULT_MASK, chan->regs + ZYNQMP_DMA_IDS);
    zynqmp_dma_free_descriptors(chan);
    return 0;
}

If a DMA client calls dmaengine_terminate_all() while a transfer is active,
the driver masks interrupts and recycles the software descriptors back to
free_list.

However, it doesn't appear to write to the hardware registers (e.g., clearing
ZYNQMP_DMA_ENABLE in ZYNQMP_DMA_CTRL2) to stop the physical DMA engine. If a
new transfer is requested, the software will reallocate the freed descriptors
while the hardware concurrently manipulates them, which could cause race
conditions and memory corruption.

[Severity: High]
This is a pre-existing issue, but could unbinding the device via sysfs while a
DMA client is active cause a use-after-free?

drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_chan_probe() {
    ...
    chan = devm_kzalloc(zdev->dev, sizeof(*chan), GFP_KERNEL);
    ...
}

The driver allocates its core structures (zdev and chan) using devm_kzalloc().

If unbound via sysfs, zynqmp_dma_remove() is called and
dma_async_device_unregister() is invoked. The devres framework then
automatically frees the zdev and chan structures.

An active client still holds a pointer to the channel because
dma_async_device_unregister() does not wait for clients to release their
references, meaning subsequent client access would dereference freed memory.

[Severity: Critical]
This is a pre-existing issue, but is it safe to drop the channel lock during
descriptor cleanup in zynqmp_dma_chan_desc_cleanup()?

drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_chan_desc_cleanup() {
    ...
    list_for_each_entry_safe(desc, next, &chan->done_list, node) {
        ...
        if (dmaengine_desc_callback_valid(&cb)) {
            spin_unlock_irqrestore(&chan->lock, irqflags);
            dmaengine_desc_callback_invoke(&cb, NULL);
            spin_lock_irqsave(&chan->lock, irqflags);
        }
        zynqmp_dma_free_descriptor(chan, desc);
    }
    ...
}

The loop iterates over chan->done_list using list_for_each_entry_safe() and
drops chan->lock to invoke the client callback.

If a client driver concurrently calls zynqmp_dma_device_terminate_all(), which
takes the lock and moves all descriptors from done_list to free_list, the
cached next pointer is now in free_list when the lock is reacquired.

The loop would continue traversing the free_list, double-freeing descriptors
and dereferencing the free_list head, resulting in a system panic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806123014.2120447-1-nagendra.golla@amd.com?part=5

Re: [PATCH 1/6] dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup

[sashiko-bot]

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

Pre-existing issues:
- [High] Stale list iteration pointers after dropping and reacquiring the lock in zynqmp_dma_chan_desc_cleanup.
--

--- Patch [1]: [PATCH 1/6] dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup ---
commit 8086a707a0f2604d248437e0453b7591161223d9
Author: Golla Nagendra <nagendra.golla@amd.com>

dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup

Channel resource allocation can fail after runtime PM has been acquired
and after part of the descriptor state has been initialized. Without
proper rollback, the error path leaks a runtime PM reference and, on
coherent allocation failure, also leaks the software descriptor pool.

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f6a812e49ddca..b7c5612806948 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c

[ ... ]

> @@ -516,6 +520,13 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
>  	}
>  
>  	return ZYNQMP_DMA_NUM_DESCS;
> +
> +err_free_sw_desc_pool:
> +	kfree(chan->sw_desc_pool);
> +	chan->sw_desc_pool = NULL;
> +err_pm:
> +	pm_runtime_put_autosuspend(chan->dev);
> +	return ret;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but looking at
zynqmp_dma_chan_desc_cleanup() in drivers/dma/xilinx/zynqmp_dma.c,
can dropping the lock during iteration lead to list corruption?

drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_chan_desc_cleanup() {
    ...
    list_for_each_entry_safe(desc, next, &chan->done_list, node) {
        ...
        if (dmaengine_desc_callback_valid(&cb)) {
            spin_unlock_irqrestore(&chan->lock, irqflags);
            dmaengine_desc_callback_invoke(&cb, NULL);
            spin_lock_irqsave(&chan->lock, irqflags);
        }
    ...
}

If a DMA client invokes dmaengine_terminate_all() from the callback,
zynqmp_dma_device_terminate_all() will acquire the lock and move all pending
and done descriptors (including the cached next pointer) to chan->free_list.

When the callback returns and the lock is reacquired, would the loop iterator
operate on nodes linked in the free_list instead of done_list?

Since the loop condition checks against &chan->done_list, could this iterate
past the end of the list and trigger an out-of-bounds dereference?

Additionally, would calling zynqmp_dma_free_descriptor() again on a descriptor
already moved to free_list cause desc_free_cnt to exceed its maximum limit
and corrupt the allocator state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806123014.2120447-1-nagendra.golla@amd.com?part=1

Re: [PATCH 2/6] dmaengine: zynqmp_dma: Fix chan probe error handling

[sashiko-bot]

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

Pre-existing issues:
- [High] Dropping a spinlock inside `list_for_each_entry_safe` in `zynqmp_dma_chan_desc_cleanup` allows concurrent modification by `zynqmp_dma_device_terminate_all`, leading to list corruption and out-of-bounds memory accesses.
--

--- Patch [2]: [PATCH 2/6] dmaengine: zynqmp_dma: Fix chan probe error handling ---
commit d9496c3d465362f9e2e30dc80285227c14d66d2b
Author: Golla Nagendra <nagendra.golla@amd.com>

dmaengine: zynqmp_dma: Fix chan probe error handling

This commit improves the channel probe error handling in the zynqmp_dma driver.
It fixes the IRQ registration by ensuring the correct error value is returned
and that IRQ freeing in the remove path only occurs for valid numbers.
Additionally, it delays channel list registration until after successful IRQ
setup and cleans up the tasklet on probe failure.

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index b7c5612806948..f7e4a177bd17e 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing issue
while reviewing the file.

In zynqmp_dma_chan_desc_cleanup():

	list_for_each_entry_safe(desc, next, &chan->done_list, node) {
		struct dmaengine_desc_callback cb;

		dmaengine_desc_get_callback(&desc->async_tx, &cb);
		if (dmaengine_desc_callback_valid(&cb)) {
			spin_unlock_irqrestore(&chan->lock, irqflags);
			dmaengine_desc_callback_invoke(&cb, NULL);
			spin_lock_irqsave(&chan->lock, irqflags);
		}

		/* Run any dependencies, then free the descriptor */
		zynqmp_dma_free_descriptor(chan, desc);
	}

Does dropping the spinlock inside list_for_each_entry_safe() expose the traversal
state to concurrent modifications?

If a client driver calls dmaengine_terminate_async() concurrently,
zynqmp_dma_device_terminate_all() will acquire chan->lock and move all
descriptors from chan->done_list to chan->free_list (including the cached
'next' pointer).

When the lock is reacquired, the loop will blindly continue traversal on
chan->free_list instead of chan->done_list.

Since the loop termination checks against &chan->done_list, could it iterate
past the list head and treat it as a descriptor, leading to out-of-bounds
memory accesses?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806123014.2120447-1-nagendra.golla@amd.com?part=2

Re: [PATCH 1/6] dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:09PM +0530, Golla Nagendra wrote:
> Channel resource allocation can fail after runtime PM has been acquired
> and after part of the descriptor state has been initialized. Without
> proper rollback, the error path leaks a runtime PM reference and, on
> coherent allocation failure, also leaks the software descriptor pool.
>
> Fix this by balancing runtime PM usage before returning an error and
> releasing any partially allocated software descriptor pool.
>
> Fixes: 8982d48af36d ("dmaengine: zynqmp_dma: Fix PM reference leak in zynqmp_dma_alloc_chan_resourc()")
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---
>  drivers/dma/xilinx/zynqmp_dma.c | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f6a812e49ddc..b7c561280694 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -483,8 +483,10 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
>  		return ret;
>
>  	chan->sw_desc_pool = kzalloc_objs(*desc, ZYNQMP_DMA_NUM_DESCS);
> -	if (!chan->sw_desc_pool)
> -		return -ENOMEM;
> +	if (!chan->sw_desc_pool) {
> +		ret = -ENOMEM;
> +		goto err_pm;
> +	}
>
>  	chan->idle = true;
>  	chan->desc_free_cnt = ZYNQMP_DMA_NUM_DESCS;
> @@ -502,8 +504,10 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
>  					       (2 * ZYNQMP_DMA_DESC_SIZE(chan) *
>  					       ZYNQMP_DMA_NUM_DESCS),
>  					       &chan->desc_pool_p, GFP_KERNEL);
> -	if (!chan->desc_pool_v)
> -		return -ENOMEM;
> +	if (!chan->desc_pool_v) {
> +		ret = -ENOMEM;
> +		goto err_free_sw_desc_pool;

This is seperated problem. Need use new patch to fix it.

Frank

> +	}
>
>  	for (i = 0; i < ZYNQMP_DMA_NUM_DESCS; i++) {
>  		desc = chan->sw_desc_pool + i;
> @@ -516,6 +520,13 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
>  	}
>
>  	return ZYNQMP_DMA_NUM_DESCS;
> +
> +err_free_sw_desc_pool:
> +	kfree(chan->sw_desc_pool);
> +	chan->sw_desc_pool = NULL;
> +err_pm:
> +	pm_runtime_put_autosuspend(chan->dev);
> +	return ret;
>  }
>
>  /**
> --
> 2.43.7
>

Re: [PATCH 2/6] dmaengine: zynqmp_dma: Fix chan probe error handling

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:10PM +0530, Golla Nagendra wrote:
> Keep the real platform_get_irq() error value by returning ret directly,
> initialize chan->irq to -1, and only assign chan->irq after
> devm_request_irq() succeeds. In remove, free IRQ only for valid numbers
> and delete device_node only when linked.
>
> Move channel list registration to after successful IRQ registration,
> initialize device_node list head during probe setup, and kill the
> tasklet in the outer probe failure path when channel probe fails.
>
> Fixes: b0cc417c1637 ("dmaengine: Add Xilinx zynqmp dma engine driver support")
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---
>  drivers/dma/xilinx/zynqmp_dma.c | 28 ++++++++++++++++++----------
>  1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index b7c561280694..f7e4a177bd17 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -205,7 +205,7 @@ struct zynqmp_dma_desc_sw {
>   * @desc_pool_p: Physical allocated descriptor base
g>   * @desc_free_cnt: Descriptor available count
>   * @dev: The dma device
> - * @irq: Channel IRQ
> + * @irq: Linux IRQ number, or -1 when not registered
>   * @is_dmacoherent: Tells whether dma operations are coherent or not
>   * @tasklet: Cleanup work after irq
>   * @idle : Channel status;
> @@ -896,10 +896,11 @@ static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
>  	if (!chan)
>  		return;
>
> -	if (chan->irq)
> +	if (chan->irq >= 0)
>  		devm_free_irq(chan->zdev->dev, chan->irq, chan);
>  	tasklet_kill(&chan->tasklet);
> -	list_del(&chan->common.device_node);
> +	if (!list_empty(&chan->common.device_node))
> +		list_del(&chan->common.device_node);
>  }
>
>  /**
> @@ -915,13 +916,14 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  	struct zynqmp_dma_chan *chan;
>  	struct device_node *node = pdev->dev.of_node;
>  	const struct zynqmp_dma_config *match_data;
> -	int err;
> +	int err, ret;
>
>  	chan = devm_kzalloc(zdev->dev, sizeof(*chan), GFP_KERNEL);
>  	if (!chan)
>  		return -ENOMEM;
>  	chan->dev = zdev->dev;
>  	chan->zdev = zdev;
> +	chan->irq = -1;
>
>  	chan->regs = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(chan->regs))
> @@ -954,22 +956,26 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  	INIT_LIST_HEAD(&chan->pending_list);
>  	INIT_LIST_HEAD(&chan->done_list);
>  	INIT_LIST_HEAD(&chan->free_list);
> +	INIT_LIST_HEAD(&chan->common.device_node);
>
>  	dma_cookie_init(&chan->common);
>  	chan->common.device = &zdev->common;
> -	list_add_tail(&chan->common.device_node, &zdev->common.channels);
> -
>  	zynqmp_dma_init(chan);
> -	chan->irq = platform_get_irq(pdev, 0);
> -	if (chan->irq < 0)
> -		return -ENXIO;
> -	err = devm_request_irq(&pdev->dev, chan->irq, zynqmp_dma_irq_handler, 0,
> +	ret = platform_get_irq(pdev, 0);
> +	if (ret < 0)
> +		return ret;
> +
> +	err = devm_request_irq(&pdev->dev, ret, zynqmp_dma_irq_handler, 0,
>  			       "zynqmp-dma", chan);
>  	if (err)
>  		return err;
>
> +	chan->irq = ret;
> +
>  	chan->desc_size = sizeof(struct zynqmp_dma_desc_ll);
>  	chan->idle = true;
> +	list_add_tail(&chan->common.device_node, &zdev->common.channels);
> +
>  	return 0;
>  }
>
> @@ -1134,6 +1140,8 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
>  	ret = zynqmp_dma_chan_probe(zdev, pdev);
>  	if (ret) {
>  		dev_err_probe(&pdev->dev, ret, "Probing channel failed\n");
> +		if (zdev->chan)
> +			tasklet_kill(&zdev->chan->tasklet);

there are already have goto, tear down move goto section.

Frank
>  		goto err_disable_pm;
>  	}
>
> --
> 2.43.7
>

Re: [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:11PM +0530, Golla Nagendra wrote:
> Correct kerneldoc comments that no longer matched the code.
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/dma/xilinx/zynqmp_dma.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f7e4a177bd17..c5b05fd52e9d 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -208,7 +208,7 @@ struct zynqmp_dma_desc_sw {
>   * @irq: Linux IRQ number, or -1 when not registered
>   * @is_dmacoherent: Tells whether dma operations are coherent or not
>   * @tasklet: Cleanup work after irq
> - * @idle : Channel status;
> + * @idle: Channel status
>   * @desc_size: Size of the low level descriptor
>   * @err: Channel has errors
>   * @bus_width: Bus width
> @@ -435,7 +435,7 @@ zynqmp_dma_get_descriptor(struct zynqmp_dma_chan *chan)
>  }
>
>  /**
> - * zynqmp_dma_free_descriptor - Issue pending transactions
> + * zynqmp_dma_free_descriptor - Return a descriptor to the free pool
>   * @chan: ZynqMP DMA channel pointer
>   * @sdesc: Transaction descriptor pointer
>   */
> @@ -617,7 +617,6 @@ static void zynqmp_dma_start_transfer(struct zynqmp_dma_chan *chan)
>  	zynqmp_dma_start(chan);
>  }
>
> -
>  /**
>   * zynqmp_dma_chan_desc_cleanup - Cleanup the completed descriptors
>   * @chan: ZynqMP DMA channel
> @@ -908,7 +907,7 @@ static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
>   * @zdev: Driver specific device structure
>   * @pdev: Pointer to the platform_device structure
>   *
> - * Return: '0' on success and failure value on error
> + * Return: 0 on success and negative error code on failure
>   */
>  static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  			   struct platform_device *pdev)
> @@ -1042,11 +1041,11 @@ static int __maybe_unused zynqmp_dma_runtime_suspend(struct device *dev)
>  }
>
>  /**
> - * zynqmp_dma_runtime_resume - Runtime suspend method for the driver
> + * zynqmp_dma_runtime_resume - Runtime resume method for the driver
>   * @dev:	Address of the device structure
>   *
> - * Put the driver into low power mode.
> - * Return: 0 always
> + * Enable device clocks.
> + * Return: 0 on success and failure value on error
>   */
>  static int __maybe_unused zynqmp_dma_runtime_resume(struct device *dev)
>  {
> --
> 2.43.7
>

Re: [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:12PM +0530, Golla Nagendra wrote:
> Fix minor whitespace formatting in zynqmp_dma_chan_probe().
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---
>  drivers/dma/xilinx/zynqmp_dma.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index c5b05fd52e9d..2d56ea08ce45 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -947,7 +947,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  	if (match_data)
>  		chan->irq_offset = match_data->offset;
>
> -	chan->is_dmacoherent =  of_property_read_bool(node, "dma-coherent");
> +	chan->is_dmacoherent = of_property_read_bool(node, "dma-coherent");

You should not parse this common property, call of_dma_is_coherent() ?

Frank

>  	zdev->chan = chan;
>  	tasklet_setup(&chan->tasklet, zynqmp_dma_do_tasklet);
>  	spin_lock_init(&chan->lock);
> @@ -959,6 +959,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>
>  	dma_cookie_init(&chan->common);
>  	chan->common.device = &zdev->common;
> +
>  	zynqmp_dma_init(chan);
>  	ret = platform_get_irq(pdev, 0);
>  	if (ret < 0)
> --
> 2.43.7
>

Re: [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:13PM +0530, Golla Nagendra wrote:
> Zero-length prep_memcpy() needlessly consumed a descriptor slot. Reject
> zero-length memcpy at prep time and document the behaviour.
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---

Is it caller problem, which pass down zero len? or are there special usage,
such as memory barrier.

Frank

>  drivers/dma/xilinx/zynqmp_dma.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index 2d56ea08ce45..e70874d65123 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -836,7 +836,8 @@ static void zynqmp_dma_synchronize(struct dma_chan *dchan)
>   * @len: Transfer length
>   * @flags: transfer ack flags
>   *
> - * Return: Async transaction descriptor on success and NULL on failure
> + * Return: Async transaction descriptor on success and NULL on failure or
> + *	   zero length transfer
>   */
>  static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
>  				struct dma_chan *dchan, dma_addr_t dma_dst,
> @@ -851,6 +852,9 @@ static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
>
>  	chan = to_chan(dchan);
>
> +	if (!len)
> +		return NULL;
> +
>  	desc_cnt = DIV_ROUND_UP(len, ZYNQMP_DMA_MAX_TRANS_LEN);
>
>  	spin_lock_irqsave(&chan->lock, irqflags);
> --
> 2.43.7
>

Re: [PATCH 6/6] dmaengine: zynqmp_dma: Remove unused define and duplicate IRQ bit

[Frank Li]

On Thu, Aug 06, 2026 at 06:00:14PM +0530, Golla Nagendra wrote:
> Remove the unused ZYNQMP_DMA_SRC_ISSUE_RST_VAL define.
> ZYNQMP_DMA_DST_DSCR_DONE was also set twice in the default interrupt enable
> mask; remove the duplicate bit.
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/dma/xilinx/zynqmp_dma.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index e70874d65123..fd2dee4ea17f 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -112,8 +112,7 @@
>  #define ZYNQMP_DMA_INT_DONE	(ZYNQMP_DMA_DONE | ZYNQMP_DMA_DST_DSCR_DONE)
>  #define ZYNQMP_DMA_INT_EN_DEFAULT_MASK	(ZYNQMP_DMA_INT_DONE | \
>  					ZYNQMP_DMA_INT_ERR | \
> -					ZYNQMP_DMA_INT_OVRFL | \
> -					ZYNQMP_DMA_DST_DSCR_DONE)
> +					ZYNQMP_DMA_INT_OVRFL)
>
>  /* Max number of descriptors per channel */
>  #define ZYNQMP_DMA_NUM_DESCS	32
> @@ -128,8 +127,6 @@
>  /* Reset values for data attributes */
>  #define ZYNQMP_DMA_AXCACHE_VAL		0xF
>
> -#define ZYNQMP_DMA_SRC_ISSUE_RST_VAL	0x1F
> -
>  #define ZYNQMP_DMA_IDS_DEFAULT_MASK	0xFFF
>
>  /* Bus width in bits */
> --
> 2.43.7
>

Re: [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers

[Golla, Nagendra]

Hi Frank,

On 8/6/2026 9:26 PM, Frank Li wrote:
> On Thu, Aug 06, 2026 at 06:00:13PM +0530, Golla Nagendra wrote:
>> Zero-length prep_memcpy() needlessly consumed a descriptor slot. Reject
>> zero-length memcpy at prep time and document the behaviour.
>>
>> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
>> ---
> 
Thanks for the review
> Is it caller problem, which pass down zero len? or are there special usage,
> such as memory barrier.
> 

This is a caller-side issue. In this driver, prep_memcpy() expects a 
non-zero len.
When len is 0, the path allocate/fetch a descriptor and append it to the 
transfer flow, but it represents a zero-byte transaction (no meaningful 
data movement). There is no intended driver-side special use of 
zero-length memcpy (such as a barrier/fence).
So rejecting zero-length requests makes the behavior explicit and avoids 
consuming
descriptor resources for a no-op transfer.

Thanks,
Nagendra
> Frank
> 
>>   drivers/dma/xilinx/zynqmp_dma.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
>> index 2d56ea08ce45..e70874d65123 100644
>> --- a/drivers/dma/xilinx/zynqmp_dma.c
>> +++ b/drivers/dma/xilinx/zynqmp_dma.c
>> @@ -836,7 +836,8 @@ static void zynqmp_dma_synchronize(struct dma_chan *dchan)
>>    * @len: Transfer length
>>    * @flags: transfer ack flags
>>    *
>> - * Return: Async transaction descriptor on success and NULL on failure
>> + * Return: Async transaction descriptor on success and NULL on failure or
>> + *	   zero length transfer
>>    */
>>   static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
>>   				struct dma_chan *dchan, dma_addr_t dma_dst,
>> @@ -851,6 +852,9 @@ static struct dma_async_tx_descriptor *zynqmp_dma_prep_memcpy(
>>
>>   	chan = to_chan(dchan);
>>
>> +	if (!len)
>> +		return NULL;
>> +
>>   	desc_cnt = DIV_ROUND_UP(len, ZYNQMP_DMA_MAX_TRANS_LEN);
>>
>>   	spin_lock_irqsave(&chan->lock, irqflags);
>> --
>> 2.43.7
>>