drivers/spi/spi-atcspi200.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
The atcspi_exec_mem_op() function may call mutex_lock() on the
driver's mutex before it is properly initialized if a SPI memory
operation is initiated immediately after devm_spi_register_controller()
is called. The mutex initialization currently occurs after the
controller registration, which leaves a window where the mutex could
be used uninitialized.
Move the mutex initialization to the beginning of the probe function,
before any registration or resource allocation.
Fixes: 34e3815ea459 ("spi: atcspi200: Add ATCSPI200 SPI controller driver")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
changes in v3:use mutex_init
changes in v2:add miss goto free_controller;
---
drivers/spi/spi-atcspi200.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atcspi200.c b/drivers/spi/spi-atcspi200.c
index c0607193be8d..c9fc37398881 100644
--- a/drivers/spi/spi-atcspi200.c
+++ b/drivers/spi/spi-atcspi200.c
@@ -551,6 +551,8 @@ static int atcspi_probe(struct platform_device *pdev)
spi->dev = &pdev->dev;
dev_set_drvdata(&pdev->dev, host);
+ mutex_init(&spi->mutex_lock);
+
ret = atcspi_init_resources(pdev, spi, &mem_res);
if (ret)
goto free_controller;
@@ -580,11 +582,11 @@ static int atcspi_probe(struct platform_device *pdev)
else
spi->use_dma = true;
}
- mutex_init(&spi->mutex_lock);
return 0;
free_controller:
+ mutex_destroy(&spi->mutex_lock);
spi_controller_put(host);
return ret;
}
--
2.25.1
On Thu, 12 Mar 2026 10:47:55 +0800, Pei Xiao wrote:
> spi: atcspi200: fix mutex initialization order
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/1] spi: atcspi200: fix mutex initialization order
https://git.kernel.org/broonie/misc/c/869d5b4b2a80
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Thu, 12 Mar 2026 10:47:55 +0800, Pei Xiao wrote:
> The atcspi_exec_mem_op() function may call mutex_lock() on the
> driver's mutex before it is properly initialized if a SPI memory
> operation is initiated immediately after devm_spi_register_controller()
> is called. The mutex initialization currently occurs after the
> controller registration, which leaves a window where the mutex could
> be used uninitialized.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: atcspi200: fix mutex initialization order
commit: 869d5b4b2a8012f6ef6058a1055cac6922c2cb55
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
© 2016 - 2026 Red Hat, Inc.