kernel/linux.git/drivers/dma/stm32, branch v6.19.11

dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings

2026-03-04T12:20:39+00:00

[ 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 Reviewed-by: Clément Le Goffic Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: stm32-dma3: use module_platform_driver

2026-03-04T12:20:38+00:00

[ 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 Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251121-dma3_improv-v2-1-76a207b13ea6@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: stm32: dmamux: clean up route allocation error labels

2025-12-14T09:17:24+00:00

Error labels should be named after what they do (and not after wherefrom they are jumped to). Signed-off-by: Johan Hovold Reviewed-by: Amelie Delaunay Link: https://patch.msgid.link/20251117161258.10679-13-johan@kernel.org Signed-off-by: Vinod Koul

dmaengine: stm32: dmamux: fix OF node leak on route allocation failure

2025-12-14T09:17:24+00:00

Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures. Fixes: df7e762db5f6 ("dmaengine: Add STM32 DMAMUX driver") Cc: stable@vger.kernel.org # 4.15 Cc: Pierre-Yves MORDRET Signed-off-by: Johan Hovold Reviewed-by: Amelie Delaunay Link: https://patch.msgid.link/20251117161258.10679-12-johan@kernel.org Signed-off-by: Vinod Koul

dmaengine: stm32: dmamux: fix device leak on route allocation

2025-12-14T09:17:24+00:00

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: df7e762db5f6 ("dmaengine: Add STM32 DMAMUX driver") Cc: stable@vger.kernel.org # 4.15 Cc: Pierre-Yves MORDRET Signed-off-by: Johan Hovold Reviewed-by: Amelie Delaunay Link: https://patch.msgid.link/20251117161258.10679-11-johan@kernel.org Signed-off-by: Vinod Koul

dmaengine: stm32: Don't use %pK through printk

2025-06-26T22:27:55+00:00

In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh Reviewed-by: Amelie Delaunay Link: https://lore.kernel.org/r/20250618-restricted-pointers-dma-v2-1-bc39dafc201d@linutronix.de Signed-off-by: Vinod Koul

dmaengine: stm32-dma: configure next sg only if there are more than 2 sgs

2025-06-26T22:25:15+00:00

DMA operates in Double Buffer Mode (DBM) when the transfer is cyclic and there are at least two periods. When DBM is enabled, the DMA toggles between two memory targets (SxM0AR and SxM1AR), indicated by the SxSCR.CT bit (Current Target). There is no need to update the next memory address if two periods are configured, as SxM0AR and SxM1AR are already properly set up before the transfer begins in the stm32_dma_start_transfer() function. This avoids unnecessary updates to SxM0AR/SxM1AR, thereby preventing potential Transfer Errors. Specifically, when the channel is enabled, SxM0AR and SxM1AR can only be written if SxSCR.CT=1 and SxSCR.CT=0, respectively. Otherwise, a Transfer Error interrupt is triggered, and the stream is automatically disabled. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20250624-stm32_dma_dbm_fix-v1-1-337c40d6c93e@foss.st.com Signed-off-by: Vinod Koul

dmaengine: stm32-dma3: clamp AXI burst using match data

2024-10-21T17:21:45+00:00

STM32 DMA3 can be interconnected with AXI3 or AXI4 busses. In case it is interconnected with AXI3, the maximum burst length supported by AXI3 protocol is 16 beats, which is lower than the maximum burst length supported by STM32 DMA3. So the programmed burst has to be shortened when AXI port is used. Introduce struct stm32_dma3_pdata to specify the specific configurations (e.g. AXI maximum burst length) required by the SoC, so implied by the SoC specific compatible. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20241016-dma3-mp25-updates-v3-6-8311fe6f228d@foss.st.com Signed-off-by: Vinod Koul

dmaengine: stm32-dma3: prevent LL refactoring thanks to DT configuration

2024-10-21T17:21:45+00:00

stm32-dma3 driver refactors the linked-list in order to address the memory with the highest possible data width. It means that it can introduce up to 2 linked-list items. One with a transfer length multiple of channel maximum burst length and so with the highest possible data width. And an extra one with the latest bytes, with lower data width. Some devices (e.g. FMC ECC) don't support having several transfers instead of only one. So add the possibility to prevent linked-list refactoring, when bit 17 of the 'DMA transfer requirements' bit mask is set in device tree. When NOPACK feature is used (bit 16 pf the 'DMA transfer requirements' bit mask in device tree), linked-list refactoring can be avoided, since the memory data width and burst will be aligned with the device ones. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20241016-dma3-mp25-updates-v3-5-8311fe6f228d@foss.st.com Signed-off-by: Vinod Koul

dmaengine: stm32-dma3: refactor HW linked-list to optimize memory accesses

2024-10-21T17:21:45+00:00

Current behavior splits the buffer/sg in n * STM32_DMA3_MAX_BLOCK_SIZE + 1 for the remainder without optimization. New behavior splits the buffer/sg in n * STM32_DMA3_MAX_BLOCK_SIZE + 1 for (x * chan->max_burst) + 1 for the remainder. Depending on channel FIFO size, optimal double-word (word if only 8-byte FIFO size) bursts can be programmed before managing the very last remainder with lower data width. In case of _prep_slave_sg, and depending on the channel Transfer Complete event configuration, the user is warned about the refactored linked-list, not having the same items count than the initial sg_list. This warning is shown only if the configuration is successful. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20241016-dma3-mp25-updates-v3-3-8311fe6f228d@foss.st.com Signed-off-by: Vinod Koul