From: Clément Le Goffic <redacted>

[ 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 <redacted>
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