From: Frank Li <Frank.li@oss.nxp.com>
To: Rosen Penev <rosenp@gmail.com>
Cc: dmaengine@vger.kernel.org, Vinod Koul <vkoul@kernel.org>,
Frank Li <Frank.Li@kernel.org>, Saeed Bishara <saeed@marvell.com>,
Lennert Buytenhek <buytenh@marvell.com>,
Maciej Sosnowski <maciej.sosnowski@intel.com>,
Dan Williams <djbw@kernel.org>, Nicolas Pitre <nico@marvell.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dmaengine: mv_xor: use writel() instead of relaxed variant
Date: Wed, 16 Sep 2026 14:06:41 -0500 [thread overview]
Message-ID: <aqrowa1TFhIDA-17@SMW015318> (raw)
In-Reply-To: <20260916182405.12985-1-rosenp@gmail.com>
On Wed, Sep 16, 2026 at 11:24:05AM -0700, Rosen Penev wrote:
> Fix the ordering guarantees between descriptor memory writes and the
> MMIO accesses that expose them to the engine. The descriptor pool is
> allocated with dma_alloc_wc(), so writes sit in the CPU write buffers
> and must be drained before the engine is allowed to read them.
>
> Program the next-descriptor pointer with writel() instead of
> writel_relaxed(); the full accessor drains prior memory writes before
> the MMIO write.
>
> In mv_xor_tx_submit() the appended chain link must be visible before the
> busy-status register is read. Use a full mb() so the engine cannot fetch a
> stale chain link and stall the channel after the CPU decides it is still
> busy.
>
> Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
> Assisted-by: LLM
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/dma/mv_xor.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index c4e0dce3ca64..0de2b1ad5c30 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -103,7 +103,10 @@ static u32 mv_chan_get_current_desc(struct mv_xor_chan *chan)
> static void mv_chan_set_next_descriptor(struct mv_xor_chan *chan,
> u32 next_desc_addr)
> {
> - writel_relaxed(next_desc_addr, XOR_NEXT_DESC(chan));
> + /* writel drains descriptor writes to DRAM before the engine
> + * is pointed at them
> + */
> + writel(next_desc_addr, XOR_NEXT_DESC(chan));
I remember this my comments before, should be v2 version?
> }
>
> static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
> @@ -410,6 +413,11 @@ mv_xor_tx_submit(struct dma_async_tx_descriptor *tx)
> /* fix up the hardware chain */
> mv_desc_set_next_desc(old_chain_tail, sw_desc->async_tx.phys);
>
> + /* make the new link visible to the engine before we read
> + * the channel state, the device may fetch it at any point
> + */
> + mb();
> +
The first is readl_relaxed() in mv_chan_is_busy(), all io readl and writel
is ordered.
which part need mb() here?
Frank
> /* if the channel is not busy */
> if (!mv_chan_is_busy(mv_chan)) {
> u32 current_desc = mv_chan_get_current_desc(mv_chan);
> --
> 2.55.0
>
next prev parent reply other threads:[~2026-09-16 19:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 18:24 [PATCH] dmaengine: mv_xor: use writel() instead of relaxed variant Rosen Penev
2026-09-16 19:06 ` Frank Li [this message]
2026-09-16 21:46 ` Rosen Penev
2026-09-16 22:33 ` Frank Li
2026-09-17 23:45 ` Rosen Penev
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=aqrowa1TFhIDA-17@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=Frank.Li@kernel.org \
--cc=buytenh@marvell.com \
--cc=djbw@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.sosnowski@intel.com \
--cc=nico@marvell.com \
--cc=rosenp@gmail.com \
--cc=saeed@marvell.com \
--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.