All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Frank Li" <Frank.Li@nxp.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
Date: Wed, 06 May 2026 22:17:04 +0000	[thread overview]
Message-ID: <20260506221705.53B33C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260506-dma_prep_config-v4-4-85b3d22babff@nxp.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The return value of dw_edma_device_config() is ignored, leading to silent preparation failures and corrupted state.
- [High] Lockless modification of shared channel configuration causes a race condition during concurrent descriptor preparation.
--

commit 72239068fd086ad95d773ab05d33c4df60a82fea
Author: Frank Li <Frank.Li@nxp.com>

dmaengine: dw-edma: Use new .device_prep_config_sg() callback

This commit introduces the .device_prep_config_sg() callback for the
dw-edma driver. It combines configuration and scatter-gather descriptor
preparation into a single step.

> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index c2feb3adc79fa..f7f58b0010e26 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
[ ... ]
> @@ -577,10 +577,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  }
>  
>  static struct dma_async_tx_descriptor *
> -dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> -			     unsigned int len,
> -			     enum dma_transfer_direction direction,
> -			     unsigned long flags, void *context)
> +dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> +			      unsigned int len,
> +			      enum dma_transfer_direction direction,
> +			      unsigned long flags,
> +			      struct dma_slave_config *config)
>  {
>  	struct dw_edma_transfer xfer;
>  
> @@ -591,6 +592,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
>  	xfer.flags = flags;
>  	xfer.type = EDMA_XFER_SCATTER_GATHER;
>  
> +	if (config)
> +		dw_edma_device_config(dchan, config);

dw_edma_device_config() can return an error code like -EINVAL if the
configuration is invalid. Does ignoring this return value cause the transfer
to be scheduled with a corrupted or stale state? Should this return NULL if
the configuration fails?

Also, the new .device_prep_config_sg callback is often used to allow lockless
descriptor preparation. However, dw_edma_device_config() modifies shared
channel state:

dw_edma_device_config() {
	...
	chan->non_ll = false;
	...
	memcpy(&chan->config, config, sizeof(*config));
	chan->configured = true;
	...
}

If multiple threads prepare transfers concurrently, can this cause a data
race resulting in corrupted descriptors?

> +
>  	return dw_edma_device_transfer(&xfer);
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506-dma_prep_config-v4-0-85b3d22babff@nxp.com?part=4

  reply	other threads:[~2026-05-06 22:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 20:44 [PATCH v4 0/9] dmaengine: Add new API to combine configuration and descriptor preparation Frank Li
2026-05-06 20:44 ` [PATCH v4 1/9] dmaengine: Add API to combine configuration and preparation (sg and single) Frank Li
2026-05-06 21:39   ` sashiko-bot
2026-05-12 14:00   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 2/9] dmaengine: Add safe API to combine configuration and preparation Frank Li
2026-05-06 22:02   ` sashiko-bot
2026-05-12 14:03   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code Frank Li
2026-05-06 20:44 ` [PATCH v4 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback Frank Li
2026-05-06 22:17   ` sashiko-bot [this message]
2026-05-12 14:03   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer() Frank Li
2026-05-06 22:36   ` sashiko-bot
2026-05-12 14:04   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer Frank Li
2026-05-12 14:05   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API Frank Li
2026-05-06 23:05   ` sashiko-bot
2026-05-12 14:06   ` Manivannan Sadhasivam
2026-05-06 20:44 ` [PATCH v4 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code Frank Li
2026-05-06 23:26   ` sashiko-bot
2026-05-06 20:44 ` [PATCH v4 9/9] crypto: atmel: Use dmaengine_prep_config_single() API Frank Li
2026-05-06 23:31   ` sashiko-bot

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=20260506221705.53B33C2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.