Sujit Reddy Thumma wrote:
Hi Ulf,
I see similar issue with your patch in 3.2 "mmc: core: Prevent too long
response times for suspend".
if (mmc_try_claim_host(host)) {
<snip>
/* if CONFIG_MMC_UNSAFE_RESUME is not set, remove() callback would get
blocked until mmcqd gets mmc_claim_host() causing deadlock here */
if (host->bus_ops->remove)
host->bus_ops->remove(host);
<snip>
You are definitely right. I did not test my patch properly, without
CONFIG_MMC_UNSAFE_RESUME, I realize now.
} else {
err = -EBUSY;
}
}
Proabably, we can do something like this:
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5278ffb..0177d4a 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2309,6 +2309,7 @@ int mmc_suspend_host(struct mmc_host *host)
* We simply "remove" the card in this
case.
* It will be redetected on resume.
*/
+ mmc_do_release_host(host);
if (host->bus_ops->remove)
host->bus_ops->remove(host);
mmc_claim_host(host);
@@ -2317,8 +2318,9 @@ int mmc_suspend_host(struct mmc_host *host)
mmc_release_host(host);
host->pm_flags = 0;
err = 0;
+ } else {
+ mmc_do_release_host(host);
}
- mmc_do_release_host(host);
Your changes looks feasible! Thanks for fixing this issue!
} else {
err = -EBUSY;
}
Please let me know if you agree. I can post a patch for this.
BR
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
