On Friday 27 May 2005 10:12 am, Alan Stern wrote: > 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?
Because the point of suspending a _hub_ is to use the USB "suspend" state! :) It's not like any other kind of USB device driver; like an HCD, it's integral to the operation of the stack, not any single function. > 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. It's true that khubd disconnects "could" go in parallel with whatever task is doing the wakeups; though I don't keep track of what the locking does there any more. - Dave ------------------------------------------------------- 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
