dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
@ 2025-09-18 14:27 Guodong Xu
  2025-09-18 16:20 ` Arnd Bergmann
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Guodong Xu @ 2025-09-18 14:27 UTC (permalink / raw)
  To: Vinod Koul, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
	Justin Stitt, Yixun Lan
  Cc: dmaengine, linux-kernel, llvm, linux-riscv, spacemit, elder,
	Naresh Kamboju, Arnd Bergmann, Guodong Xu

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>
---
Hi Vinod, Arnd, and all,

This patch fixes a build failure in the mmp_pdma driver when using
clang-20, as reported by Naresh Kamboju [1]. The error,
a -Wshift-count-overflow warning, is caused by a known issue in the clang
compiler. When the DMA_BIT_MASK(64) macro is used in a static initializer,
it triggers a long-standing bug in how clang evaluates compile-time
constants [2, 3]. Thanks to Nathan Chancellor for providing these links.

While investigating this, Arnd Bergmann pointed out that the driver's
logic for setting the DMA mask was unnecessarily complex. This logic,
which was inherited from the original Marvel PDMA driver when adding
support for SpacemiT K1 DMA, could be simplified. A better solution is to
set each device's DMA mask directly based on its hardware capability.

This patch implements Arnd's suggestion. It refactors the driver to store
the controller's DMA width (either 32 or 64 bits) and generates the mask
at runtime within the probe() function.

This approach also avoids the clang false error reporting.

This patch is based on dmaengine.git next [4].

Thanks,
Guodong Xu

[1] https://lore.kernel.org/lkml/CA+G9fYsPcMfW-e_0_TRqu4cnwqOqYF3aJOeKUYk6Z4qRStdFvg@mail.gmail.com/
[2] https://github.com/ClangBuiltLinux/linux/issues/92
[3] https://github.com/llvm/llvm-project/issues/38137
[4] https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next
---
 drivers/dma/mmp_pdma.c | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index d07229a748868b8115892c63c54c16130d88e326..86661eb3cde1ff6d6d8f02b6f0d4142878b5a890 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -152,8 +152,8 @@ struct mmp_pdma_phy {
  *
  * Controller Configuration:
  * @run_bits:   Control bits in DCSR register for channel start/stop
- * @dma_mask:   DMA addressing capability of controller. 0 to use OF/platform
- *              settings, or explicit mask like DMA_BIT_MASK(32/64)
+ * @dma_width:  DMA addressing width in bits (32 or 64). Determines the
+ *              DMA mask capability of the controller hardware.
  */
 struct mmp_pdma_ops {
 	/* Hardware Register Operations */
@@ -173,7 +173,7 @@ struct mmp_pdma_ops {
 
 	/* Controller Configuration */
 	u32 run_bits;
-	u64 dma_mask;
+	u32 dma_width;
 };
 
 struct mmp_pdma_device {
@@ -1172,7 +1172,7 @@ static const struct mmp_pdma_ops marvell_pdma_v1_ops = {
 	.get_desc_src_addr = get_desc_src_addr_32,
 	.get_desc_dst_addr = get_desc_dst_addr_32,
 	.run_bits = (DCSR_RUN),
-	.dma_mask = 0,			/* let OF/platform set DMA mask */
+	.dma_width = 32,
 };
 
 static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
@@ -1185,7 +1185,7 @@ static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
 	.get_desc_src_addr = get_desc_src_addr_64,
 	.get_desc_dst_addr = get_desc_dst_addr_64,
 	.run_bits = (DCSR_RUN | DCSR_LPAEEN),
-	.dma_mask = DMA_BIT_MASK(64),	/* force 64-bit DMA addr capability */
+	.dma_width = 64,
 };
 
 static const struct of_device_id mmp_pdma_dt_ids[] = {
@@ -1314,13 +1314,9 @@ static int mmp_pdma_probe(struct platform_device *op)
 	pdev->device.directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
 	pdev->device.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
 
-	/* Set DMA mask based on ops->dma_mask, or OF/platform */
-	if (pdev->ops->dma_mask)
-		dma_set_mask(pdev->dev, pdev->ops->dma_mask);
-	else if (pdev->dev->coherent_dma_mask)
-		dma_set_mask(pdev->dev, pdev->dev->coherent_dma_mask);
-	else
-		dma_set_mask(pdev->dev, DMA_BIT_MASK(64));
+	/* Set DMA mask based on controller hardware capabilities */
+	dma_set_mask_and_coherent(pdev->dev,
+				  DMA_BIT_MASK(pdev->ops->dma_width));
 
 	ret = dma_async_device_register(&pdev->device);
 	if (ret) {

---
base-commit: cc0bacac6de7763a038550cf43cb94634d8be9cd
change-id: 20250904-mmp-pdma-simplify-dma-addressing-f6aef03e07c3

Best regards,
-- 
Guodong Xu <guodong@riscstar.com>


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
  2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
@ 2025-09-18 16:20 ` Arnd Bergmann
  2025-09-30 22:10 ` Nathan Chancellor
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2025-09-18 16:20 UTC (permalink / raw)
  To: Guodong Xu, Vinod Koul, Nathan Chancellor, Nick Desaulniers,
	Bill Wendling, Justin Stitt, Yixun Lan
  Cc: dmaengine, linux-kernel, llvm, linux-riscv, spacemit, elder,
	Naresh Kamboju

On Thu, Sep 18, 2025, at 16:27, 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>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Thanks for fixing this!

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
  2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
  2025-09-18 16:20 ` Arnd Bergmann
@ 2025-09-30 22:10 ` Nathan Chancellor
  2025-10-13 17:00   ` Nathan Chancellor
  2025-10-06 12:41 ` Naresh Kamboju
  2025-10-16 12:55 ` Vinod Koul
  3 siblings, 1 reply; 6+ messages in thread
From: Nathan Chancellor @ 2025-09-30 22:10 UTC (permalink / raw)
  To: Guodong Xu, Vinod Koul
  Cc: Nick Desaulniers, Bill Wendling, Justin Stitt, Yixun Lan,
	dmaengine, linux-kernel, llvm, linux-riscv, spacemit, elder,
	Naresh Kamboju, Arnd Bergmann

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.

>  drivers/dma/mmp_pdma.c | 20 ++++++++------------
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
> index d07229a748868b8115892c63c54c16130d88e326..86661eb3cde1ff6d6d8f02b6f0d4142878b5a890 100644
> --- a/drivers/dma/mmp_pdma.c
> +++ b/drivers/dma/mmp_pdma.c
> @@ -152,8 +152,8 @@ struct mmp_pdma_phy {
>   *
>   * Controller Configuration:
>   * @run_bits:   Control bits in DCSR register for channel start/stop
> - * @dma_mask:   DMA addressing capability of controller. 0 to use OF/platform
> - *              settings, or explicit mask like DMA_BIT_MASK(32/64)
> + * @dma_width:  DMA addressing width in bits (32 or 64). Determines the
> + *              DMA mask capability of the controller hardware.
>   */
>  struct mmp_pdma_ops {
>  	/* Hardware Register Operations */
> @@ -173,7 +173,7 @@ struct mmp_pdma_ops {
>  
>  	/* Controller Configuration */
>  	u32 run_bits;
> -	u64 dma_mask;
> +	u32 dma_width;
>  };
>  
>  struct mmp_pdma_device {
> @@ -1172,7 +1172,7 @@ static const struct mmp_pdma_ops marvell_pdma_v1_ops = {
>  	.get_desc_src_addr = get_desc_src_addr_32,
>  	.get_desc_dst_addr = get_desc_dst_addr_32,
>  	.run_bits = (DCSR_RUN),
> -	.dma_mask = 0,			/* let OF/platform set DMA mask */
> +	.dma_width = 32,
>  };
>  
>  static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
> @@ -1185,7 +1185,7 @@ static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
>  	.get_desc_src_addr = get_desc_src_addr_64,
>  	.get_desc_dst_addr = get_desc_dst_addr_64,
>  	.run_bits = (DCSR_RUN | DCSR_LPAEEN),
> -	.dma_mask = DMA_BIT_MASK(64),	/* force 64-bit DMA addr capability */
> +	.dma_width = 64,
>  };
>  
>  static const struct of_device_id mmp_pdma_dt_ids[] = {
> @@ -1314,13 +1314,9 @@ static int mmp_pdma_probe(struct platform_device *op)
>  	pdev->device.directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
>  	pdev->device.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
>  
> -	/* Set DMA mask based on ops->dma_mask, or OF/platform */
> -	if (pdev->ops->dma_mask)
> -		dma_set_mask(pdev->dev, pdev->ops->dma_mask);
> -	else if (pdev->dev->coherent_dma_mask)
> -		dma_set_mask(pdev->dev, pdev->dev->coherent_dma_mask);
> -	else
> -		dma_set_mask(pdev->dev, DMA_BIT_MASK(64));
> +	/* Set DMA mask based on controller hardware capabilities */
> +	dma_set_mask_and_coherent(pdev->dev,
> +				  DMA_BIT_MASK(pdev->ops->dma_width));
>  
>  	ret = dma_async_device_register(&pdev->device);
>  	if (ret) {
> 
> ---
> base-commit: cc0bacac6de7763a038550cf43cb94634d8be9cd
> change-id: 20250904-mmp-pdma-simplify-dma-addressing-f6aef03e07c3
> 
> Best regards,
> -- 
> Guodong Xu <guodong@riscstar.com>
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
  2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
  2025-09-18 16:20 ` Arnd Bergmann
  2025-09-30 22:10 ` Nathan Chancellor
@ 2025-10-06 12:41 ` Naresh Kamboju
  2025-10-16 12:55 ` Vinod Koul
  3 siblings, 0 replies; 6+ messages in thread
From: Naresh Kamboju @ 2025-10-06 12:41 UTC (permalink / raw)
  To: Guodong Xu
  Cc: Vinod Koul, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
	Justin Stitt, Yixun Lan, dmaengine, linux-kernel, llvm,
	linux-riscv, spacemit, elder, Arnd Bergmann

On Thu, 18 Sept 2025 at 19:57, Guodong Xu <guodong@riscstar.com> 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>

Patch applied on top of Linux next-20251003 tag and build test pass.

Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>

- Naresh

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
  2025-09-30 22:10 ` Nathan Chancellor
@ 2025-10-13 17:00   ` Nathan Chancellor
  0 siblings, 0 replies; 6+ messages in thread
From: Nathan Chancellor @ 2025-10-13 17:00 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Nick Desaulniers, Bill Wendling, Justin Stitt, Yixun Lan,
	dmaengine, linux-kernel, llvm, linux-riscv, spacemit, elder,
	Naresh Kamboju, Arnd Bergmann, Guodong Xu

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dmaengine: mmp_pdma: fix DMA mask handling
  2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
                   ` (2 preceding siblings ...)
  2025-10-06 12:41 ` Naresh Kamboju
@ 2025-10-16 12:55 ` Vinod Koul
  3 siblings, 0 replies; 6+ messages in thread
From: Vinod Koul @ 2025-10-16 12:55 UTC (permalink / raw)
  To: Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
	Yixun Lan, Guodong Xu
  Cc: dmaengine, linux-kernel, llvm, linux-riscv, spacemit, elder,
	Naresh Kamboju, Arnd Bergmann


On Thu, 18 Sep 2025 22:27:27 +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.
> 
> [...]

Applied, thanks!

[1/1] dmaengine: mmp_pdma: fix DMA mask handling
      commit: 88ebb29d3244e515a92c2331434bb73fef7efdc6

Best regards,
-- 
~Vinod



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-10-16 12:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-18 14:27 [PATCH] dmaengine: mmp_pdma: fix DMA mask handling Guodong Xu
2025-09-18 16:20 ` Arnd Bergmann
2025-09-30 22:10 ` Nathan Chancellor
2025-10-13 17:00   ` Nathan Chancellor
2025-10-06 12:41 ` Naresh Kamboju
2025-10-16 12:55 ` Vinod Koul

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).