Strange... But obviously you did see it eventually.
I wonder if that's really the best thing. How would we then learn
about drivers trying to register or unregister a device during a sleep
transition?
Do you think it might be possible instead to somehow allow these
unregistrations to go through, while still failing or blocking
registrations? It shouldn't be too hard to modify the driver core so
that it calls the driver's remove() method without trying to acquire
dev->sem if your in_suspend_context() test succeeds.
I have to admit, I still don't understand what's going on with the MMC
driver. Why is there a workqueue involved? If the workqueue fails to
unregister the device, why should it bother the suspend routine? After
all, if the suspend routine can afford to wait for the workqueue to
finish then it could just as well afford to do the unregistration
itself.
We'll have to get more information from the bug reporter to figure out
what really happened there.
Ultimately it may turn out some drivers just aren't very careful about
when they try to register new devices. Doing the registration by way
of a workqueue can be problematic if the workqueue happens to run
during a system sleep transition. That will still be true if you
revert the acquire-all-semaphores patch.
Alan Stern
--
