On Sun, 2005-12-18 at 12:58 -0800, David Brownell wrote:
> 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. :)
I'm working on it :)
> 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.
Ok.
> 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.
Makes sense. Just wanted to be sure.
> 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.
Ok, and so at the parent hub level, we can do either the actual suspend
of the port, or even power the port off if the device got into this
"latent disconnect" state.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
