[PATCH AUTOSEL 6.19-6.1] dmaengine: sun6i: Choose appropriate burst length under maxburst

[PATCH AUTOSEL 6.19-6.1] dmaengine: sun6i: Choose appropriate burst length under maxburst

[Sasha Levin]

From: Chen-Yu Tsai <wens@kernel.org>

[ Upstream commit 7178c3586ab42693b28bb81014320a7783e5c435 ]

maxburst, as provided by the client, specifies the largest amount of
data that is allowed to be transferred in one burst. This limit is
normally provided to avoid a data burst overflowing the target FIFO.
It does not mean that the DMA engine can only do bursts in that size.

Let the driver pick the largest supported burst length within the
given limit. This lets the driver work correctly with some clients that
give a large maxburst value. In particular, the 8250_dw driver will give
a quarter of the UART's FIFO size as maxburst. On some systems the FIFO
size is 256 bytes, giving a maxburst of 64 bytes, while the hardware
only supports bursts of up to 16 bytes.

Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20251221080450.1813479-1-wens@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### What the commit fixes

This commit fixes a real bug where the sun6i DMA engine driver
incorrectly rejects valid DMA slave configurations. The DMA API's
`maxburst` field specifies the **maximum** burst size, not an exact
value. When a DMA client (like 8250_dw UART) provides a maxburst value
(e.g., 64) that isn't directly supported by the hardware (which only
supports 1, 4, 8, 16), the old code returned `-EINVAL`, causing DMA
transfers to fail completely.

The fix adds a `find_burst_size()` helper that selects the largest
supported burst length that doesn't exceed `maxburst`, which is the
correct DMA API semantics. This makes DMA work on real systems where
8250_dw UART gives maxburst=64 (quarter of a 256-byte FIFO) but the DMA
hardware supports bursts of at most 16.

### Stable kernel criteria assessment

1. **Obviously correct and tested**: Yes. The logic is simple - find
   largest power-of-two burst in the supported bitmask that fits within
   maxburst. Reviewed by Jernej Skrabec, applied by Vinod Koul.

2. **Fixes a real bug**: Yes. DMA transactions fail with `-EINVAL` on
   specific hardware combinations. This causes UART (and potentially
   other peripherals) to not work via DMA.

3. **Important issue**: Yes - this causes peripheral communication
   failure (UART DMA doesn't work on some Allwinner SoCs). Users with
   256-byte UART FIFOs and DMA-capable 8250_dw cannot use DMA at all.

4. **Small and contained**: Yes. Adds a ~14-line helper function,
   removes 4 lines of strict checks, and reorders 4 lines of existing
   code to call the new function first. Total change is well under 50
   lines in a single file.

5. **No new features**: Correct - this makes the driver handle the
   existing DMA API correctly. It's a bug fix to match the documented
   DMA maxburst semantics.

### Risk assessment

- **Low risk**: Changes are confined to one driver file
  (`drivers/dma/sun6i-dma.c`)
- **No regressions for existing users**: If maxburst was previously an
  exact match for hardware-supported values (1, 4, 8, or 16),
  `find_burst_size()` returns the same value as before. The behavior
  only changes for values that previously failed.
- **Well-tested helper**: `rounddown_pow_of_two` is a standard kernel
  utility available in all stable trees.
- **No dependency issues**: The `burst_lengths` infrastructure was
  introduced in 2017, present in all current stable kernels.

### User impact

Moderate-to-high for Allwinner ARM SoC users (embedded/IoT). These SoCs
are common in single-board computers (Orange Pi, Pine64, etc.) and
various embedded devices. The fix enables DMA-based UART operation where
it was previously broken.

## Verification

- **Verified** `burst_lengths` was introduced by commit d5f6d8cf31a89
  (2017-09-28), present in all stable trees.
- **Verified** `convert_burst()` only handles values 1, 4, 8, 16 (lines
  283-297), so the old code that directly passed unsupported values
  would return -EINVAL from both the explicit check AND from
  convert_burst.
- **Verified** the hardware configs show burst_lengths support
  BIT(1)|BIT(8) (A31/A23/A83t/D1) or BIT(1)|BIT(4)|BIT(8)|BIT(16)
  (H3/H6/V3s/A100), meaning a maxburst of 64 would fail on ALL variants.
- **Verified** `rounddown_pow_of_two` is available in
  `include/linux/log2.h` and is a long-standing kernel utility.
- **Verified** via git log that no other recent commits to this file are
  needed as dependencies.
- **Verified** via lore.kernel.org that the patch was reviewed by Jernej
  Skrabec and applied by maintainer Vinod Koul.
- **Could not verify** the exact 8250_dw maxburst=64 scenario from the
  8250_dw driver source (unverified, but the commit message describes a
  real hardware scenario credibly).

**YES**

 drivers/dma/sun6i-dma.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 2215ff877bf7d..f9d876deb1f05 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -583,6 +583,22 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void *dev_id)
 	return ret;
 }
 
+static u32 find_burst_size(const u32 burst_lengths, u32 maxburst)
+{
+	if (!maxburst)
+		return 1;
+
+	if (BIT(maxburst) & burst_lengths)
+		return maxburst;
+
+	/* Hardware only does power-of-two bursts. */
+	for (u32 burst = rounddown_pow_of_two(maxburst); burst > 0; burst /= 2)
+		if (BIT(burst) & burst_lengths)
+			return burst;
+
+	return 1;
+}
+
 static int set_config(struct sun6i_dma_dev *sdev,
 			struct dma_slave_config *sconfig,
 			enum dma_transfer_direction direction,
@@ -616,15 +632,13 @@ static int set_config(struct sun6i_dma_dev *sdev,
 		return -EINVAL;
 	if (!(BIT(dst_addr_width) & sdev->slave.dst_addr_widths))
 		return -EINVAL;
-	if (!(BIT(src_maxburst) & sdev->cfg->src_burst_lengths))
-		return -EINVAL;
-	if (!(BIT(dst_maxburst) & sdev->cfg->dst_burst_lengths))
-		return -EINVAL;
 
 	src_width = convert_buswidth(src_addr_width);
 	dst_width = convert_buswidth(dst_addr_width);
-	dst_burst = convert_burst(dst_maxburst);
-	src_burst = convert_burst(src_maxburst);
+	src_burst = find_burst_size(sdev->cfg->src_burst_lengths, src_maxburst);
+	dst_burst = find_burst_size(sdev->cfg->dst_burst_lengths, dst_maxburst);
+	dst_burst = convert_burst(dst_burst);
+	src_burst = convert_burst(src_burst);
 
 	*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
 		DMA_CHAN_CFG_DST_WIDTH(dst_width);
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] dmaengine: stm32-dma3: use module_platform_driver

[Sasha Levin]

From: Amelie Delaunay <amelie.delaunay@foss.st.com>

[ Upstream commit 0d41ed4ea496fabbb4dc21171e32d9a924c2a661 ]

Without module_platform_driver(), stm32-dma3 doesn't have a
module_exit procedure. Once stm32-dma3 module is inserted, it
can't be removed, marked busy.
Use module_platform_driver() instead of subsys_initcall() to register
(insmod) and unregister (rmmod) stm32-dma3 driver.

Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://patch.msgid.link/20251121-dma3_improv-v2-1-76a207b13ea6@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Interesting - all three STM32 DMA drivers use `subsys_initcall()`. The
other two (stm32-dma and stm32-mdma) also lack module_exit. This commit
only changes stm32-dma3.

## Analysis Summary

### What the commit fixes
The stm32-dma3 driver registers using `subsys_initcall()` but has no
`module_exit()` function. This means the module can be loaded (`insmod`)
but never unloaded (`rmmod`), as the kernel marks it as busy due to
having no exit/cleanup path.

### Change implications
The fix replaces `subsys_initcall()` (priority level 4) with
`module_platform_driver()` which uses `module_init()` /
`device_initcall()` (priority level 6). This is a **behavioral change**
- the driver will now:
1. Initialize later in the boot sequence (device_initcall instead of
   subsys_initcall)
2. Be unloadable via rmmod

### Risk Assessment
- **Positive**: Fixes inability to unload the module - this is a genuine
  bug fix
- **Risk**: The init level change from `subsys_initcall` (level 4) to
  `device_initcall` (level 6) could cause probe ordering issues. DMA
  controllers are often needed early by other subsystems. However, with
  device tree and deferred probing in modern kernels, this should be
  handled. The fact that 54 other DMA drivers use
  `module_platform_driver()` successfully supports this.
- **Scope**: Very small change - removes 6 lines, adds 1 line. Single
  file, single driver.
- **Affected stable trees**: Only 6.11+ (driver introduced in
  v6.11-rc1), so this would apply to v6.12.y and v6.13.y stable trees.

### Stable criteria assessment
- **Fixes a real bug**: Yes - module cannot be unloaded
- **Obviously correct**: Mostly. The `module_platform_driver()` macro is
  the standard pattern used by the majority of DMA drivers. However, the
  init level change adds a small risk.
- **Small and contained**: Yes - 7 lines changed in one file
- **No new features**: The ability to unload a module is restoring
  expected behavior, not a new feature
- **Tested**: Has a Reviewed-by tag from Eugen Hristev

### Concerns
1. The initialization order change (`subsys_initcall` →
   `device_initcall`) is the main concern. DMA engines are
   infrastructure that other drivers depend on. If anything probes
   before the DMA controller is ready and doesn't handle deferred
   probing correctly, this could cause regressions.
2. However, this is mitigated by the fact that modern device tree
   platforms and probe deferral should handle this gracefully.
3. The bug (inability to rmmod) primarily affects development/debugging
   workflows and modular kernel configurations, not production embedded
   systems that typically build DMA drivers in.

## Verification

- **git log** confirmed stm32-dma3.c was introduced by commit
  f561ec8b2b33d, which is in v6.11-rc1
- **Read of current source** (line 1917-1922) confirmed the
  `subsys_initcall` without `module_exit` pattern matches the pre-patch
  state
- **Grep of drivers/dma/stm32/** confirmed all three STM32 DMA drivers
  use subsys_initcall - this commit only changes stm32-dma3
- **Grep of drivers/dma/** found 21 DMA drivers using subsys_initcall
  and 54 using module_platform_driver, confirming module_platform_driver
  is the dominant pattern
- **git tag** confirmed the driver exists only in 6.11+ stable trees
- The `.remove` callback (`stm32_dma3_remove`) is already defined in the
  platform_driver struct (line 1909), confirming the removal path was
  intended to work

## Conclusion

This fixes a real bug (module cannot be unloaded) with a minimal, well-
understood change using a standard kernel macro. The risk is the init
level change, but this follows the pattern of the majority of DMA
drivers. The fix is small, reviewed, and appropriate for stable. The
driver only exists in 6.11+, limiting the scope of backport. For
embedded/STM32 developers who load the DMA3 driver as a module, this is
a meaningful fix.

**YES**

 drivers/dma/stm32/stm32-dma3.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/dma/stm32/stm32-dma3.c b/drivers/dma/stm32/stm32-dma3.c
index 50e7106c5cb73..9500164c8f688 100644
--- a/drivers/dma/stm32/stm32-dma3.c
+++ b/drivers/dma/stm32/stm32-dma3.c
@@ -1914,12 +1914,7 @@ static struct platform_driver stm32_dma3_driver = {
 	},
 };
 
-static int __init stm32_dma3_init(void)
-{
-	return platform_driver_register(&stm32_dma3_driver);
-}
-
-subsys_initcall(stm32_dma3_init);
+module_platform_driver(stm32_dma3_driver);
 
 MODULE_DESCRIPTION("STM32 DMA3 controller driver");
 MODULE_AUTHOR("Amelie Delaunay <amelie.delaunay@foss.st.com>");
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings

[Sasha Levin]

From: Clément Le Goffic <clement.legoffic@foss.st.com>

[ Upstream commit aaf3bc0265744adbc2d364964ef409cf118d193d ]

m2m_hw_period is initialized only when chan_config->m2m_hw is true. This
triggers a warning:
‘m2m_hw_period’ may be used uninitialized [-Wmaybe-uninitialized]
Although m2m_hw_period is only used when chan_config->m2m_hw is true and
ignored otherwise, initialize it unconditionally to 0.

ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not
empty. This triggers a warning:
‘ccr’ may be used uninitialized [-Wmaybe-uninitialized]
Indeed, it could be used uninitialized if the sg list is empty. Initialize
it to 0.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
Reviewed-by: Clément Le Goffic <legoffic.clement@gmail.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I can see `sg_len` is passed from the DMA framework's `prep_slave_sg`
callback. While the DMA framework generally doesn't call this with
`sg_len == 0`, there's no explicit guard against it in this function.
The `stm32_mdma_alloc_desc` with `sg_len == 0` might succeed (allocating
a descriptor with 0 nodes), allowing execution to reach
`stm32_mdma_setup_xfer` with an empty list.

### Verification

- **Read the actual code**: Confirmed `ccr` is used at lines 777-779
  after the for_each_sg loop, and if `sg_len == 0`, `ccr` is never
  initialized by `stm32_mdma_set_xfer_param()`.
- **Caller analysis**: `stm32_mdma_setup_xfer` is called from
  `stm32_mdma_prep_slave_sg` at line 809 with `sg_len` from the DMA
  framework - no explicit guard for `sg_len == 0`.
- **m2m_hw_period**: Confirmed at lines 737-738 and 749-750/758-759 that
  it's only used when `chan_config->m2m_hw` is true (false positive
  warning).
- **Risk assessment**: The change is a trivial initialization, zero
  regression risk.
- **Could NOT verify**: Whether any real-world code path actually passes
  `sg_len == 0` to `prep_slave_sg` (unverified, but defensive
  initialization is correct practice).

### Conclusion

This is a very low-risk fix that:
1. Silences compiler warnings (useful for clean builds)
2. Fixes a real (if potentially rare) uninitialized variable bug for
   `ccr`

The fix is trivially correct, one line, zero regression risk, and fixes
a genuine code correctness issue. While it's borderline because the
primary framing is "fix warnings" and the affected driver is
STM32-specific, the `ccr` uninitialized variable is a real bug that
could cause DMA hardware misconfiguration, and the fix has absolutely no
downside.

**YES**

 drivers/dma/stm32/stm32-mdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32/stm32-mdma.c b/drivers/dma/stm32/stm32-mdma.c
index 080c1c725216c..b87d41b234df1 100644
--- a/drivers/dma/stm32/stm32-mdma.c
+++ b/drivers/dma/stm32/stm32-mdma.c
@@ -731,7 +731,7 @@ static int stm32_mdma_setup_xfer(struct stm32_mdma_chan *chan,
 	struct stm32_mdma_chan_config *chan_config = &chan->chan_config;
 	struct scatterlist *sg;
 	dma_addr_t src_addr, dst_addr;
-	u32 m2m_hw_period, ccr, ctcr, ctbr;
+	u32 m2m_hw_period = 0, ccr = 0, ctcr, ctbr;
 	int i, ret = 0;
 
 	if (chan_config->m2m_hw)
-- 
2.51.0