From: Théo Lebrun theo.lebrun@bootlin.com
[ Upstream commit 32ce3bb57b6b402de2aec1012511e7ac4e7449dc ]
dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI controller. Neither embed the other; this lead to memory corruption.
On a given platform (Mobileye EyeQ5) the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex (ctlr->bus_lock_mutex) by spi_controller_suspend().
Fixes: 2087e85bb66e ("spi: cadence-quadspi: fix suspend-resume implementations") Reviewed-by: Dhruva Gole d-gole@ti.com Signed-off-by: Théo Lebrun theo.lebrun@bootlin.com Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-1-6b6af8bcbf59@bootlin.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Zhaoyang Li lizy04@hust.edu.cn --- drivers/spi/spi-cadence-quadspi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 42861bc45073..02c5f00c8a57 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1775,10 +1775,9 @@ static int cqspi_remove(struct platform_device *pdev) static int cqspi_suspend(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev); int ret;
- ret = spi_master_suspend(master); + ret = spi_master_suspend(cqspi->master); cqspi_controller_enable(cqspi, 0);
clk_disable_unprepare(cqspi->clk); @@ -1789,7 +1788,6 @@ static int cqspi_suspend(struct device *dev) static int cqspi_resume(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev);
clk_prepare_enable(cqspi->clk); cqspi_wait_idle(cqspi); @@ -1798,7 +1796,7 @@ static int cqspi_resume(struct device *dev) cqspi->current_cs = -1; cqspi->sclk = 0;
- return spi_master_resume(master); + return spi_master_resume(cqspi->master); }
static DEFINE_SIMPLE_DEV_PM_OPS(cqspi_dev_pm_ops, cqspi_suspend, cqspi_resume);
[ Sasha's backport helper bot ]
Hi,
✅ All tests passed successfully. No issues detected. No action required from the submitter.
The upstream commit SHA1 provided is correct: 32ce3bb57b6b402de2aec1012511e7ac4e7449dc
WARNING: Author mismatch between patch and upstream commit: Backport author: Zhaoyang Lilizy04@hust.edu.cn Commit author: Théo Lebruntheo.lebrun@bootlin.com
Status in newer kernel trees: 6.14.y | Present (exact SHA1) 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: 03f1573c9587)
Note: The patch differs from the upstream commit: --- 1: 32ce3bb57b6b4 < -: ------------- spi: cadence-qspi: fix pointer reference in runtime PM hooks -: ------------- > 1: 6764cfc0045d9 spi: cadence-qspi: fix pointer reference in runtime PM hooks ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.1.y | Success | Success |
On Fri, May 16, 2025 at 02:25:28PM +0800, Zhaoyang Li wrote:
From: Théo Lebrun theo.lebrun@bootlin.com
[ Upstream commit 32ce3bb57b6b402de2aec1012511e7ac4e7449dc ]
dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI controller. Neither embed the other; this lead to memory corruption.
On a given platform (Mobileye EyeQ5) the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex (ctlr->bus_lock_mutex) by spi_controller_suspend().
Fixes: 2087e85bb66e ("spi: cadence-quadspi: fix suspend-resume implementations") Reviewed-by: Dhruva Gole d-gole@ti.com Signed-off-by: Théo Lebrun theo.lebrun@bootlin.com Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-1-6b6af8bcbf59@bootlin.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Zhaoyang Li lizy04@hust.edu.cn
drivers/spi/spi-cadence-quadspi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
Turns out you used a LLM tool to generate this backport. Any specific reason why you didn't identify that and tell us you did so?
thanks,
greg k-h
After using an LLM tool to generate an initial version of the patch, we conducted a strict and thorough manual review to avoid any potential issues. We ultimately confirmed that the final patch is identical to what would have been produced by a purely human-written approach before submitting it.
At the time, we had similar concerns regarding AI-assisted contributions, but we did not observe a clear consensus within the community on this matter. As a result, we chose to mitigate any potential impact through rigorous human review.
That said, we appreciate the discussion and understand the importance of transparency in this area. We are happy to follow any community guidance or emerging best practices regarding disclosure of AI-assisted development going forward.
-- best regards, Zhaoyang Li
linux-stable-mirror@lists.linaro.org