On Sun, 16 Dec 2001, Riley Williams wrote: > If we're talking USB here (and in some cases even if we're not), we need > to deal with more than that. Specifically, we need to be able to deal > with the following sequences: > [several sequences to unplug/replug same/different device while suspended] > > The first three sequences means that we can't guarantee that on resume, > the devices available will be identical to those on suspend. The last > sequence means that even if it is, we may need to do more than just > reload firmware - and in the case of notebooks, this sequence is going
Depends on whether the host is still able to monitor the bus state during suspend. If the HC / root hub ports are unable to monitor the bus state - f.e. when the HC itself gets suspended in D3cold state? - we must assume the device was disconnected anyway (and the HC would be required to detect a new connect on resume). But I'm pretty unsure, whether the HC shall be able to monitor the USB in D3cold or not - at least any host state which supports remote wakeup from usb requires the HC to monitor the USB state! If the bus state is monitored, there is no problem with your sequences. Note that usb device/hub suspend is pretty much different from disconnect: suspend goes through USB idle state (>3ms) while disconnect is signaled by SE0. Thus the host can pretty well distinguish what happened with the suspended device. Whenever the host sees a disconnect, it must not even try to resume the device, regardless what it finds when resuming the USB. Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
