[PATCH] USB: OHCI resume/reset stops deadlocking in PM code
System-wide PM resume now happily deadlocks if one of the resuming devices tries to remove devices which vanished during the suspend(*). IMO that's unreasonable both because devices can/do vanish, and because 2.4 didn't deadlock in those cases; but no patch to fix that has been merged. The result is that ever since merging the "new" PM code, some OHCI-based systems deadlock on resume. So this patch handles the "lost power during resume" case differently: it doesn't disconnect the root hub (or its children) directly. Instead, it does part of that work immediately, and defers the rest to khubd: - add a "pending" list for live urbs, and use it after reset to abort pending URBs (and reclaim "live" EDs/TDs) - immediately mark all devices NOTATTACHED, so any operations on the devices before khubd handles the disconnects, including resume() callbacks, will fail - kick root hub so it can do the cleanup It also handles "fminterval" init/reinit a bit better, mostly to work better in some remote wakeup scenarios addressed in later patches: - save any initial value the boot firmware provided - use it during initialization (and eventually, remote wakeup) Other changes: - use better jiffies calculation for scheduled delays - the allocator does more of the one-time initialization - initialize hcd.can_wakeup according to boot firmware - move some inlines to the header - minor cleanups (*) http://marc.theaimsgroup.com/?l=linux-kernel&m=106606272103414&w=2 reported against 2.6.0-test7.
Showing
Please register or sign in to comment