Re: USB rejecting sleep

[David Brownell <david-b@pacbell.net>]

On Sunday 18 December 2005 12:27 pm, Benjamin Herrenschmidt wrote:
> Hi David, Alan !
> 
> What exactly changed in the recent USB stacks that is causing it to
> abort system suspend much more often ? I'm getting lots of user reports
> with 2.6.15-rc5 saying that they can't put their internal laptops to
> sleep, apparently because a driver doesn't have a suspend method
> (internal bluetooth in this case).

Which I hope _did_ generate a bug report to the maintainer of that
bluetooth code.  :)


> It's never been mandatory so far for all drivers of all connected
> devices to have a suspend method... didn't we decide back then that
> disconneting those was the right way to go ?

Right, but the system never stopped self-deadlocking when we did the
disconnect at suspend time.  My notes say "driver core suspend()
calls are made with dev->sem held, so usb_driver_release_interface()
always deadlocks when they try to claim the same lock" and presumably
that's still true.

I guess I didn't realize the consequence of not fixing that as part
of the other PM updates, once I found that the "most natural" fix
was (still?) not possible.


> Any reason we are rejecting the sleep process for these currently ? A
> locking issue that makes disconnecting not yet feasible ? What changed
> from the previous version where that worked ?

The current kernels tighten up the suspend processing and offloaded lots
of stuff to the driver core.  Previous kernels didn't have code that
could care about such stuff, at least without USB_SUSPEND enabled.

So the issue is now how to handle this error case.  I think it should
be possible to just mark the device as disconnected right as soon as
we notice it can't be suspended; resume processing will do the work,
it already does so for real disconnect.  And disconnect paths in USB
drivers are now pretty solid.

- Dave