[PATCH AUTOSEL 6.19-6.1] dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings
Sasha Levin
sashal at kernel.org
Wed Feb 18 18:04:16 PST 2026
From: Clément Le Goffic <clement.legoffic at 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 at foss.st.com>
Reviewed-by: Clément Le Goffic <legoffic.clement at gmail.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay at foss.st.com>
Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com
Signed-off-by: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Sasha Levin <sashal at 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
More information about the linux-arm-kernel
mailing list