On Thu, 26 May 2005, David Brownell wrote: > > Interesting. Apparently the usb_generic_suspend() and > > usb_generic_resume() routines don't mind calling USB drivers' suspend and > > resume methods even if CONFIG_USB_SUSPEND isn't set. I'd say that's a > > bug. > > Actually I'm not so sure. I generally describe USB_SUSPEND as relating > to whether or not the USB "suspend" state is used -- selective suspend > and resume support. Calling driver suspend() and resume() methods is > orthogonal to that ... except that to use the USB "suspend" state, any > drivers should have been properly suspended.
Then how come the hub_suspend and hub_resume methods in hub.c don't exist when CONFIG_USB_SUSPEND isn't set? I have to agree, however, that this particular problem looks like it's caused by something else. Perhaps a disconnect is racing with resume during the restart sequence. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
