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.