On 5/04/24 00:13, Ulf Hansson wrote:
On Thu, 4 Apr 2024 at 20:42, Adrian Hunter adrian.hunter@intel.com wrote:
On 28/03/24 16:20, Adrian Hunter wrote:
On 27/03/24 17:17, Ulf Hansson wrote:
On Tue, 26 Mar 2024 at 11:25, Adrian Hunter adrian.hunter@intel.com wrote:
On 21/03/24 16:30, Mantas Pucka wrote:
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
Cc: stable@vger.kernel.org Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by: Mantas Pucka mantas@8devices.com
Acked-by: Adrian Hunter adrian.hunter@intel.com
Looks like this problem may exist for other sdhci drivers too. In particular for those that enables runtime PM, don't set SDHCI_QUIRK_NO_LED and don't use sdhci_runtime|suspend_resume_host().
Don't know if there is a better way to address this, if not on a case by case basis. Do you have any thoughts about this?
Yes probably case by case, but I will look at it.
There seem to be 3 that use runtime pm but not sdhci_runtime_suspend_host():
- dwcmshc_runtime_suspend() : only turns off the card clock
via SDHCI_CLOCK_CONTROL register, so registers are presumably still accessible
gl9763e_runtime_suspend() : ditto
sdhci_tegra_runtime_suspend() : disables the functional
clock via clk_disable_unprepare(), so registers are presumably still accessible
sdhci_msm_runtime_suspend() is different because it also turns off the interface clock.
But it looks like there are no similar cases.
Not sure we should care, but it still looks a bit fragile to me. We may also have a power-domain hooked up to the device, that could get power gated too, in which case it's likely affecting the access to registers.
Thought some more about this, but there isn't an easy way to know if drivers are catering for SDIO card interrupt or SD card detect interrupt.