summaryrefslogtreecommitdiff
path: root/scripts/stackusage
diff options
context:
space:
mode:
authorSergey Shtylyov <s.shtylyov@auroraos.dev>2026-06-01 17:49:01 +0300
committerUlf Hansson <ulfh@kernel.org>2026-07-06 15:22:11 +0200
commit521f39ca93cc43ce1b3eae8d44201f8f55dd9151 (patch)
tree35f5fea3520b7cb6f07e3040447b37eb19c3d005 /scripts/stackusage
parent8cdeaa50eae8dad34885515f62559ee83e7e8dda (diff)
mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe() method
In the driver's probe() method, clk_disable_unprepare() for the bus clock is called on the error path even if the prior clk_prepare_enable() call has failed (and the same thing happens in the remove() method as well) -- that would cause the prepare/enable counter imbalance. Also, the same problem can happen in the driver's suspend() method; note that the resume() method does check the clk_prepare_enable()'s result -- let's be consistent and do that in probe() method as well. BTW, I don't know for sure what does the bus clock control -- if it affects the register accesses, the driver will likely cause (e.g. on ARM) a kernel oops if it fails to prepare/enable the bus clock in the probe() method... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: e438cf49b305 ("mmc: sdhci-of-dwcmshc: add SDHCI OF Synopsys DWC MSHC driver") Fixes: bccce2ec7790 ("mmc: sdhci-of-dwcmshc: add suspend/resume support") Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions