On Mon, 28 Jun 2004, Oliver Neukum wrote: > Yes, but why would it be impossible to restore the state the device had > before the suspension? And equally important, why do we need to treat > a physical reinitialisation like a logical disconnect()/probe() > The more logical model would seem to be an extreme form of resetting > a device. It retains more function. > > > The very deep suspend modes can indeed have serious limitations, > > which come from trading off that "just like at suspension" state > > against saving more power. > > We should seek to limit the limitations. > The only absolute limitation I see is not large > - you cannot do remote wake up > - you cannot detect pluggings during such suspension > - you cannot resume devices which have state unknown to the driver (sg etc.)
I think this could be done, at the cost of requiring many drivers to add a significant amount of "reinitialization" code. It would be a big job. 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. 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
