From: Nathan Chancellor <nathan@kernel.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Yixun Lan <dlan@gentoo.org>,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, elder@riscstar.com,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Arnd Bergmann <arnd@arndb.de>, Guodong Xu <guodong@riscstar.com>
Subject: Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
Date: Mon, 13 Oct 2025 10:00:55 -0700 [thread overview]
Message-ID: <20251013170055.GA3968340@ax162> (raw)
In-Reply-To: <20250930221001.GA66006@ax162>
Hi Vinod,
On Tue, Sep 30, 2025 at 03:10:01PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 18, 2025 at 10:27:27PM +0800, Guodong Xu wrote:
> > The driver's existing logic for setting the DMA mask for "marvell,pdma-1.0"
> > was flawed. It incorrectly relied on pdev->dev->coherent_dma_mask instead
> > of declaring the hardware's fixed addressing capability. A cleaner and
> > more correct approach is to define the mask directly based on the hardware
> > limitations.
> >
> > The MMP/PXA PDMA controller is a 32-bit DMA engine. This is supported by
> > datasheets and various dtsi files for PXA25x, PXA27x, PXA3xx, and MMP2,
> > all of which are 32-bit systems.
> >
> > This patch simplifies the driver's logic by replacing the 'u64 dma_mask'
> > field with a simpler 'u32 dma_width' to store the addressing capability
> > in bits. The complex if/else block in probe() is then replaced with a
> > single, clear call to dma_set_mask_and_coherent(). This sets a fixed
> > 32-bit DMA mask for "marvell,pdma-1.0" and a 64-bit mask for
> > "spacemit,k1-pdma," matching each device's hardware capabilities.
> >
> > Finally, this change also works around a specific build error encountered
> > with clang-20 on x86_64 allyesconfig. The shift-count-overflow error is
> > caused by a known clang compiler issue where the DMA_BIT_MASK(n) macro's
> > ternary operator is not correctly evaluated in static initializers. By
> > moving the macro's evaluation into the probe() function, the driver avoids
> > this compiler bug.
> >
> > Fixes: 5cfe585d8624 ("dmaengine: mmp_pdma: Add SpacemiT K1 PDMA support with 64-bit addressing")
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Closes: https://lore.kernel.org/lkml/CA+G9fYsPcMfW-e_0_TRqu4cnwqOqYF3aJOeKUYk6Z4qRStdFvg@mail.gmail.com
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
>
> Tested-by: Nathan Chancellor <nathan@kernel.org> # build
>
> It would be great if this could be picked up before the 6.18 DMA pull
> request so that I do not have to patch our CI to avoid this issue.
This patch resolves a (bogus) clang warning that breaks the build with
-Werror. Can you please queue this for a future DMA fixes pull request?
This has been available for almost a month and really should have made
the original 6.18 pull request but I dropped the ball on pinging again
before it went out since I was dealing with Kbuild this cycle.
Cheers,
Nathan
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Yixun Lan <dlan@gentoo.org>,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, elder@riscstar.com,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Arnd Bergmann <arnd@arndb.de>, Guodong Xu <guodong@riscstar.com>
Subject: Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
Date: Mon, 13 Oct 2025 10:00:55 -0700 [thread overview]
Message-ID: <20251013170055.GA3968340@ax162> (raw)
In-Reply-To: <20250930221001.GA66006@ax162>
Hi Vinod,
On Tue, Sep 30, 2025 at 03:10:01PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 18, 2025 at 10:27:27PM +0800, Guodong Xu wrote:
> > The driver's existing logic for setting the DMA mask for "marvell,pdma-1.0"
> > was flawed. It incorrectly relied on pdev->dev->coherent_dma_mask instead
> > of declaring the hardware's fixed addressing capability. A cleaner and
> > more correct approach is to define the mask directly based on the hardware
> > limitations.
> >
> > The MMP/PXA PDMA controller is a 32-bit DMA engine. This is supported by
> > datasheets and various dtsi files for PXA25x, PXA27x, PXA3xx, and MMP2,
> > all of which are 32-bit systems.
> >
> > This patch simplifies the driver's logic by replacing the 'u64 dma_mask'
> > field with a simpler 'u32 dma_width' to store the addressing capability
> > in bits. The complex if/else block in probe() is then replaced with a
> > single, clear call to dma_set_mask_and_coherent(). This sets a fixed
> > 32-bit DMA mask for "marvell,pdma-1.0" and a 64-bit mask for
> > "spacemit,k1-pdma," matching each device's hardware capabilities.
> >
> > Finally, this change also works around a specific build error encountered
> > with clang-20 on x86_64 allyesconfig. The shift-count-overflow error is
> > caused by a known clang compiler issue where the DMA_BIT_MASK(n) macro's
> > ternary operator is not correctly evaluated in static initializers. By
> > moving the macro's evaluation into the probe() function, the driver avoids
> > this compiler bug.
> >
> > Fixes: 5cfe585d8624 ("dmaengine: mmp_pdma: Add SpacemiT K1 PDMA support with 64-bit addressing")
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Closes: https://lore.kernel.org/lkml/CA+G9fYsPcMfW-e_0_TRqu4cnwqOqYF3aJOeKUYk6Z4qRStdFvg@mail.gmail.com
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
>
> Tested-by: Nathan Chancellor <nathan@kernel.org> # build
>
> It would be great if this could be picked up before the 6.18 DMA pull
> request so that I do not have to patch our CI to avoid this issue.
This patch resolves a (bogus) clang warning that breaks the build with
-Werror. Can you please queue this for a future DMA fixes pull request?
This has been available for almost a month and really should have made
the original 6.18 pull request but I dropped the ball on pinging again
before it went out since I was dealing with Kbuild this cycle.
Cheers,
Nathan
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-10-13 17:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
2025-09-18 14:27 ` Guodong Xu
2025-09-18 16:20 ` Arnd Bergmann
2025-09-18 16:20 ` Arnd Bergmann
2025-09-30 22:10 ` Nathan Chancellor
2025-09-30 22:10 ` Nathan Chancellor
2025-10-13 17:00 ` Nathan Chancellor [this message]
2025-10-13 17:00 ` Nathan Chancellor
2025-10-06 12:41 ` Naresh Kamboju
2025-10-06 12:41 ` Naresh Kamboju
2025-10-16 12:55 ` Vinod Koul
2025-10-16 12:55 ` Vinod Koul
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=20251013170055.GA3968340@ax162 \
--to=nathan@kernel.org \
--cc=arnd@arndb.de \
--cc=dlan@gentoo.org \
--cc=dmaengine@vger.kernel.org \
--cc=elder@riscstar.com \
--cc=guodong@riscstar.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=naresh.kamboju@linaro.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=spacemit@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.