Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Golla, Nagendra" <Nagendra.Golla@amd.com>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: vkoul@kernel.org, Frank.Li@kernel.org, michal.simek@amd.com,
	robh@kernel.org, krzk+dt@kernel.org, radhey.shyam.pandey@amd.com,
	kees@kernel.org, sakari.ailus@linux.intel.com,
	yukuai3@huawei.com, git@amd.com, dmaengine@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers
Date: Fri, 7 Aug 2026 16:32:23 +0530	[thread overview]
Message-ID: <14677ed1-2586-4d65-a078-986084b40c2a@amd.com> (raw)
In-Reply-To: <anSuuPHDh2lcAhBL@SMW015318>


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



  reply	other threads:[~2026-08-07 11:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 12:30 [PATCH 0/6] dmaengine: zynqmp_dma: Fix error paths and follow-up cleanups Golla Nagendra
2026-08-06 12:30 ` [PATCH 1/6] dmaengine: zynqmp_dma: Fix alloc_chan_resources error cleanup Golla Nagendra
2026-08-06 15:39   ` Frank Li
2026-08-06 12:30 ` [PATCH 2/6] dmaengine: zynqmp_dma: Fix chan probe error handling Golla Nagendra
2026-08-06 15:48   ` Frank Li
2026-08-06 12:30 ` [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments Golla Nagendra
2026-08-06 15:49   ` Frank Li
2026-08-06 12:30 ` [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace Golla Nagendra
2026-08-06 15:53   ` Frank Li
2026-08-06 12:30 ` [PATCH 5/6] dmaengine: zynqmp_dma: Reject zero-length memcpy transfers Golla Nagendra
2026-08-06 15:56   ` Frank Li
2026-08-07 11:02     ` Golla, Nagendra [this message]
2026-08-06 12:30 ` [PATCH 6/6] dmaengine: zynqmp_dma: Remove unused define and duplicate IRQ bit Golla Nagendra
2026-08-06 16:00   ` Frank Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14677ed1-2586-4d65-a078-986084b40c2a@amd.com \
    --to=nagendra.golla@amd.com \
    --cc=Frank.Li@kernel.org \
    --cc=Frank.li@oss.nxp.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=git@amd.com \
    --cc=kees@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=vkoul@kernel.org \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox