From: ohad@wizery.com (Ohad Ben-Cohen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] sdio: fix suspend/resume regression
Date: Wed, 13 Oct 2010 09:31:56 +0200 [thread overview]
Message-ID: <1286955116-22793-1-git-send-email-ohad@wizery.com> (raw)
In-Reply-To: <1286788315.3101.11.camel@sven>
Fix SDIO suspend/resume regression introduced by
4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e "mmc: fix all hangs related to
mmc/sd card insert/removal during suspend/resume":
[ 5647.295953] PM: Syncing filesystems ... done.
[ 5647.318792] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 5647.337048] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 5647.356915] Suspending console(s) (use no_console_suspend to debug)
[ 5647.366651] pm_op(): platform_pm_suspend+0x0/0x5c returns -38
[ 5647.366671] PM: Device pxa2xx-mci.0 failed to suspend: error -38
[ 5647.367082] PM: Some devices failed to suspend
4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e moved the card removal/insertion
mechanism out of MMC's suspend/resume path and into pm notifiers
(mmc_pm_notify), and that broke SDIO's expectation that mmc_suspend_host()
will remove the card, and squash the error, in case -ENOSYS is returned
from the bus suspend handler (mmc_sdio_suspend() in this case).
mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
function drivers does not have suspend/resume handlers - in that case
it is agreed to force removal of the entire card.
This patch fixes this regression by trivially bringing back that part of
mmc_suspend_host(), which was removed by 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e.
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: <stable@kernel.org>
--
It may still be desired to further clean this area up by using the card
removal mechanism in mmc_pm_notify() for SDIO as well.
To use mmc_pm_notify's card-removal code also for SDIO, we need it
to check if all the SDIO functions have suspend handlers. That
would probably make us add a new bus_ops handler (something like
host->bus_ops->remove_card_on_suspend ?).
It's starting to get a bit complicated though, and I'm not sure it
would make the code a lot more readable.
In addition, this would still not work for drivers like libertas sdio,
which do have a suspend handler, but sometimes let it return -ENOSYS,
expecting mmc_suspend_host() to remove the card and squash the error.
For those cases, we still need the old card-removal logic in mmc_suspend_host().
This brings up a question whether libertas_sdio really needs this
functionality; When MMC_PM_KEEP_POWER is not needed, can't it just return 0
(and as a result the card will be powered down, but not removed) ?
Until we have an agreement on this, I suggest we at least fix the
regression with this patch.
Thanks Sven Neumann for reporting and testing the issue and this patch.
drivers/mmc/core/core.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c94565d..515ff39 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1682,6 +1682,19 @@ int mmc_suspend_host(struct mmc_host *host)
if (host->bus_ops && !host->bus_dead) {
if (host->bus_ops->suspend)
err = host->bus_ops->suspend(host);
+ if (err == -ENOSYS || !host->bus_ops->resume) {
+ /*
+ * We simply "remove" the card in this case.
+ * It will be redetected on resume.
+ */
+ if (host->bus_ops->remove)
+ host->bus_ops->remove(host);
+ mmc_claim_host(host);
+ mmc_detach_bus(host);
+ mmc_release_host(host);
+ host->pm_flags = 0;
+ err = 0;
+ }
}
mmc_bus_put(host);
--
1.7.0.4
next prev parent reply other threads:[~2010-10-13 7:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 7:30 2.6.35.6 fails to suspend (pxa2xx-mci.0) Sven Neumann
2010-10-04 7:48 ` Eric Miao
2010-10-06 18:59 ` Maciej Rutecki
2010-10-06 23:55 ` Daniel Mack
2010-10-07 0:18 ` Rafael J. Wysocki
2010-10-07 15:03 ` Sven Neumann
2010-10-07 21:23 ` Rafael J. Wysocki
2010-10-08 8:23 ` Sven Neumann
2010-10-08 20:08 ` Rafael J. Wysocki
2010-10-09 1:07 ` Ohad Ben-Cohen
2010-10-09 23:20 ` Sven Neumann
2010-10-11 8:31 ` Sven Neumann
2010-10-11 8:45 ` Ohad Ben-Cohen
2010-10-11 9:11 ` Sven Neumann
2010-10-13 7:31 ` Ohad Ben-Cohen [this message]
2010-10-13 7:54 ` [PATCH] sdio: fix suspend/resume regression Vitaly Wool
2010-10-13 8:55 ` Ohad Ben-Cohen
2010-10-13 9:06 ` Vitaly Wool
2010-10-13 9:46 ` Ohad Ben-Cohen
2010-10-13 20:00 ` Nicolas Pitre
2010-10-13 20:08 ` Nicolas Pitre
2010-10-14 15:28 ` Ohad Ben-Cohen
2010-10-14 2:24 ` Chris Ball
2010-10-14 4:49 ` Ohad Ben-Cohen
2010-10-21 23:47 ` Maxim Levitsky
2010-10-21 23:55 ` Nicolas Pitre
2010-10-22 0:25 ` Maxim Levitsky
2010-10-21 23:57 ` Nicolas Pitre
2010-10-23 10:09 ` Ohad Ben-Cohen
2010-10-23 14:18 ` Maxim Levitsky
2010-10-23 14:44 ` Ohad Ben-Cohen
2010-10-11 8:10 ` 2.6.35.6 fails to suspend (pxa2xx-mci.0) Sven Neumann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1286955116-22793-1-git-send-email-ohad@wizery.com \
--to=ohad@wizery.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).