> 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:
>
> ==> Device plugged in and initialised.
> Machine suspended.
> Device unplugged.
> Machine resumed.
>
> ==> Device plugged in and initialised.
> Machine suspended.
> Device unplugged.
> Different device plugged in.
> Machine resumed.
>
> ==> Machine suspended.
> Device plugged in.
> Machine resumed.
>
> ==> Device plugged in and initialised.
> Machine suspended.
> Device unplugged.
> Same device plugged in.
> Machine resumed.
>
> 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
> to be common. All it needs is for the user to suspend, disconnect
> everything to pack it away, get on a plane with it, fly somewhere, plug
> it all back in and resume.
The first three cases must be dealt with like normal hotplugging just
deferred to the time we wake up. Unfortunately to deal with sleep mode at
all we need to be able to recognise previously connected devices or at
least device types. Replugging in itself should not be different to
handling power loss during sleep mode.
> Basically, we need to guarantee that on resume, all CURRENTLY PLUGGED IN
> hardware gets initialised to a known state, and anything short of that
> is just plain buggy. This includes the case where on resume, devices are
> found plugged into different ports than on suspend.
That is very hard. In fact it is basically impossible unless the device
has a serial number. We must not assume that a configuration in one
location is valid in another location.
There is usually no way you can tell that a device found at a different
port on resumption is the same.
In addition not only must we assure that devices are in a known state and
preferably as close as possible to their state before suspension, but we
must do so seamlessly to all tasks running before suspension.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
