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

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 <[email protected]>
>> ---
> 
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
>>