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

[Sasha Levin <sashal@kernel.org>]

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