From: sashiko-bot@kernel.org
To: "Benoît Monin" <benoit.monin@bootlin.com>
Cc: Frank.Li@kernel.org, imx@lists.linux.dev, vkoul@kernel.org,
dmaengine@vger.kernel.org
Subject: Re: [PATCH v5 2/2] dmaengine: fsl-edma: Support dynamic scatter/gather chaining
Date: Thu, 02 Jul 2026 12:45:52 +0000 [thread overview]
Message-ID: <20260702124553.3E52F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702-fsl-edma-dyn-sg-v5-2-16787185be49@bootlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Double-execution of DMA descriptors due to state machine desync when interrupts coalesce.
- [Critical] Channel deadlock due to dynamic descriptor linking bypassing `issue_pending()`.
--
commit a67c20eb8f20e15fe2cadb092322588069fe328e
Author: Benoît Monin <benoit.monin@bootlin.com>
dmaengine: fsl-edma: Support dynamic scatter/gather chaining
Implement dynamic linking of scatter/gather transfers to enable
chaining multiple DMA descriptors without stopping the channel.
This avoids waiting for the channel to go idle if there is another
transaction already issued.
> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -58,7 +58,10 @@ void fsl_edma_tx_chan_handler(struct fsl_edma_chan *fsl_chan)
> list_del(&fsl_chan->edesc->vdesc.node);
> vchan_cookie_complete(&fsl_chan->edesc->vdesc);
> fsl_chan->edesc = NULL;
> - fsl_chan->status = DMA_COMPLETE;
> + if (!(fsl_edma_drvflags(fsl_chan) & FSL_EDMA_DRV_SPLIT_REG) ||
> + (edma_readl_chreg(fsl_chan, ch_csr) & EDMA_V3_CH_CSR_DONE)) {
> + fsl_chan->status = DMA_COMPLETE;
> + }
[Severity: Critical]
Does checking the channel-global DONE flag here cause chained descriptors
to execute twice if interrupts coalesce?
For example, if descriptors A and B are chained and the hardware finishes
both before the interrupt handler runs, won't the handler complete A,
see DONE is set, and mark the channel DMA_COMPLETE?
If that happens, wouldn't fsl_edma_xfer_desc() then fetch B from the
issued list and restart the hardware, executing B a second time?
[ ... ]
> @@ -673,6 +676,68 @@ struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
> +static dma_cookie_t fsl_edma_tx_submit(struct dma_async_tx_descriptor *tx)
> +{
> + struct virt_dma_desc *vd = container_of(tx, struct virt_dma_desc, tx);
> + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(tx->chan);
> + struct fsl_edma_desc *fsl_desc = to_fsl_edma_desc(vd);
> + struct virt_dma_chan *vc = to_virt_chan(tx->chan);
> + dma_cookie_t cookie;
> +
> + guard(spinlock_irqsave)(&fsl_chan->vchan.lock);
> +
> + fsl_edma_link_sg(fsl_chan, fsl_desc);
> + cookie = dma_cookie_assign(tx);
> + list_move_tail(&vd->node, &vc->desc_submitted);
> +
> + return cookie;
> +}
[Severity: Critical]
Can this cause a channel deadlock by executing unissued descriptors?
Since hardware linking happens in fsl_edma_tx_submit() rather than waiting
for the issue_pending() callback, if the hardware completes the newly linked
descriptor before the client calls issue_pending(), won't the interrupt
handler fire but find edesc is NULL?
In fsl_edma_tx_chan_handler():
if (!fsl_chan->edesc) {
/* terminate_all called before */
spin_unlock(&fsl_chan->vchan.lock);
return;
}
Wouldn't this drop the completion and leave the channel stuck when
issue_pending() is eventually called, since the channel status is still left
as DMA_IN_PROGRESS?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-fsl-edma-dyn-sg-v5-0-16787185be49@bootlin.com?part=2
next prev parent reply other threads:[~2026-07-02 12:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 12:34 [PATCH v5 0/2] dmaengine: fsl-edma: Scatter/gather improvements Benoît Monin
2026-07-02 12:34 ` [PATCH v5 1/2] dmaengine: fsl-edma: Implement device_prep_peripheral_dma_vec Benoît Monin
2026-07-02 12:47 ` sashiko-bot
2026-07-02 12:34 ` [PATCH v5 2/2] dmaengine: fsl-edma: Support dynamic scatter/gather chaining Benoît Monin
2026-07-02 12:45 ` sashiko-bot [this message]
2026-07-02 13:17 ` 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=20260702124553.3E52F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=benoit.monin@bootlin.com \
--cc=dmaengine@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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.