aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mmc/core/sdio.c
diff options
context:
space:
mode:
authorUlf Hansson <ulf.hansson@linaro.org>2019-09-08 12:12:33 +0200
committerUlf Hansson <ulf.hansson@linaro.org>2019-09-11 16:10:19 +0200
commit51133850bce2a9e5060c6931ee58ceb685578dbf (patch)
tree325b49618771c912cbaa73bb4c379dfb9e578fdb /drivers/mmc/core/sdio.c
parentmmc: core: WARN if SDIO IRQs are enabled for non-powered card in suspend (diff)
downloadlinux-dev-51133850bce2a9e5060c6931ee58ceb685578dbf.tar.xz
linux-dev-51133850bce2a9e5060c6931ee58ceb685578dbf.zip
mmc: core: Fixup processing of SDIO IRQs during system suspend/resume
System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile behaviour. Some problems have been taken care of so far, but more issues remains. For example, calling the ->ack_sdio_irq() callback to let host drivers re-enable the SDIO IRQs is a bad idea, unless the IRQ have been consumed, which may not be the case during system suspend/resume. This may lead to that a host driver re-signals the same SDIO IRQ over and over again, causing a storm of IRQs and gives a ping-pong effect towards the sdio_irq_work(). Moreover, calling the ->enable_sdio_irq() callback at system resume to re-enable already enabled SDIO IRQs for the host, causes the runtime PM count for some host drivers to become in-balanced. This then leads to the host to remain runtime resumed, no matter if it's needed or not. To fix these problems, let's check if process_sdio_pending_irqs() actually consumed the SDIO IRQ, before we continue to ack the IRQ by invoking the ->ack_sdio_irq() callback. Additionally, there should be no need to re-enable SDIO IRQs as the host driver already knows if they were enabled at system suspend, thus also whether it needs to re-enable them at system resume. For this reason, drop the call to ->enable_sdio_irq() during system resume. In regards to these changes there is yet another issue, which is when there is an SDIO IRQ being signaled by the host driver, but after the SDIO card has been system suspended. Currently these IRQs are just thrown away, while we should at least make sure to try to consume them when the SDIO card has been system resumed. Fix this by queueing a sdio_irq_work() after we system resumed the SDIO card. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Diffstat (limited to 'drivers/mmc/core/sdio.c')
-rw-r--r--drivers/mmc/core/sdio.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index c557f1519b77..26cabd53ddc5 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -1015,7 +1015,7 @@ static int mmc_sdio_resume(struct mmc_host *host)
if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD))
wake_up_process(host->sdio_irq_thread);
else if (host->caps & MMC_CAP_SDIO_IRQ)
- host->ops->enable_sdio_irq(host, 1);
+ queue_delayed_work(system_wq, &host->sdio_irq_work, 0);
}
out: