Hi Oliver.
>> 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.
That deferring may not always be possible. As an example, take a system
in use by a friend of mine, basically a laptop with the keyboard not
part of the main unit, but on the end of a USB lead that has to be
disconnected to get it in its carrycase - and it has FOUR USB ports on
the main case. As it happens, Simon uses it exclusively under Win2K, and
that doesn't care what port the keyboard is plugged into on resume. If
he chose to run it under Linux, would that care?
> 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.
We also need to be able to recognise previously connected device types
even if they're on different ports when we resume. That's a direct
consequence of the social environment that USB operates in.
>> 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.
Not in the slightest - or did you miss the fact that I said "to a known
state" and NOT "to the state it was in when we suspended". Basically,
there has to be interaction between the resume logic and the hotplug
logic on resume, simply because of the fact that the hardware on resume
isn't necessarily that present on suspend.
> 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 that case, there's also no way to determine that a device found at
the same location is the same device. If so, then resume basically
comprises the following as far as USB is concerned, and anything short
of this is just plain buggy:
1. Disconnect all USB devices.
2. Scan the USB bus for devices, and
reconnect each one as it is found.
Remember, one of the basic design aims of USB was that the location a
device is plugged in is irrelevant to the user. The Linux USB drivers
need to be totally transparent to where a particular device is plugged
in, otherwise they're essentially useless.
> 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.
That has to be the primary purpose of the USB subsystem.
Best wishes from Riley.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
