On Tue, 29 Jun 2004, Oliver Neukum wrote: > > It would even be possible to detect connect changes during a power-off > > suspend, by comparing the "before" and "after" states of the hubs. Once > > the power has been restored for (say) 5 seconds, khubd could check whether > > any previously-connected ports are no longer connected and call > > usb_disconnect() for them. Also, during those 5 seconds khubd could > > monitor new connections to make sure they match the usb_devices that used > > to be on those ports -- sort of like usb_reset_device() does, comparing > > descriptors. It wouldn't be perfect, but it ought to work pretty well. > > Simpler even. It's gone when resume() fails.
No. What I described happens before resume() gets called. After all, you can't call resume() for a device that hasn't been enumerated since the power was restored. That's the division of labor between usbcore and the drivers: It's usbcore's responsibility to enumerate and configure devices, and the drivers take it from there. Come to think of it, there really is almost no difference between an unsolicited device reset and a power-off suspend (except that one is quicker than the other). No difference at all as far as anything in the USB stack is concerned, it seems to me. We've already talked about possibilities for implementing one; if we do it right then we'll have both of them. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
