> I think the hub driver's power management code may be at fault. It needs > to cancel the status interrupt URB when suspending and resubmit it when > waking up; right now it probably does neither one. > > Or maybe I'm wrong about that. Perhaps it's okay to leave the URB active. > If that's the case, then the root hub power management code needs to be > changed to restart the status URB timer after a wakeup. > > I'm not sure how the design is intended to work, but either way something > needs to be fixed.
Could well be. I need to spend some time auditing power management in the USB drivers in general. The idea here is that a sub-driver (USB device driver) should make sure it has no more pending URBs when returning from suspend() and the HCD driver should just cancel pending URBs if still any and reject any one that would be submited before it's woken up. It's especially very important on OHCI to not touch chip registers (like enabling bulk queue etc...) after the chip have been put to suspend state. On some chips, that can cause random bus mastering to main memory during sleep, which can cause all sorts of interesting results especially when the north bridge is asleep... Ben. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
