Well, the patch itself isn't really adequate; it was just a first pass
intended to illustrate the nature of the problem.
The problems in the MMC subsystem go deeper.
The first is the way it uses flush_workqueue(). This is almost always
a bad function to call, because it introduces unnecessary dependencies.
cancel_delayed_work_sync() is much better.
But even changing that won't solve the second issue, which is a genuine
bug. There is a race between detect events and suspend events. The
mmc_suspend_host() routine starts out by flushing the kmmcd workqueue
before calling the host's suspend routine. So what happens if another
detect event occurs in between?
This whole area of synchronization between card insertion, card
removal, suspend, and resume needs to be thought out better.
Especially keeping in mind that device registration or unregistration
during a system sleep is likely to block until the sleep is over.
Lastly, there are some other questions about confusing aspects of the
subsystem. What's the story with __mmc_claim_host()? Is it really
nothing more than an abortable mutex_lock()? Why does it ever need to
be aborted? Why is its second argument an atomic_t instead of a normal
int?
Why are mmc_detect() and related routines described in comments as
"Card detection callback from host"? They don't handle card
_detection_ -- they handle card _removal_.
What's the purpose of the card-counting loop in
host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
Alan Stern
--
