Hi Martin.
>> 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...
> 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.
First, let me state quite clearly that whilst I'm a more than competent
C programmer, I'm no expert on USB, and I'm simply approaching this from
the perspective of the user. Seen from that viewpoint, the situation is
quite clear, and that's what the Linux drivers have to deal with. Let's
start with a definition of the user's perspective on the whole issue:
If the user presses the SUSPEND button, causing their
machine to turn itself off as far as they can tell,
does whatever they will with the machine, and at some
later time (possibly months later) presses the RESUME
button, they expect the machine to turn itself on and
make itself ready for them to do productive work.
Keeping that in mind, let's take some scenarios that are already here
and need to be dealt with by the USB subsystem:
1. Simon's laptop has no keyboard on the body of the laptop,
and is supplied with a separate one with a USB connector
with which Simon plugs it into one of the four USB ports
on the laptop's body. Simon also has a USB modem which he
takes with him and plugs in whenever he needs it, and a
USB barcode reader that is used regularly. The port each
gets connected to is determined mainly by the order he
plugs them in before pressing the resume button.
2. Philip's laptop normally runs with a USB Zip-250 drive to
prepare and update databases for his customers, with his
customer base being spread around Europe. When he packs
it up for transport from one customer to another, he needs
to comply with the requirements of the airline he is flying
with, so the drive gets unplugged between customers.
Simon and Philip are both friends of mine, and the systems referred to
actually exist. Both are currently using Win2K based systems, and they
have no problems using the SUSP/RESM button between sessions, and never
worry about which port they plug the various USB items into. As Simon
put it recently, "With Windows 2000, they just work".
Basically, how does the current Linux USB subsystem handle those two
scenarios? The descriptions I've seen on this list basically claim that
it doesn't handle them at all, and if so, it's seriously faulty and
needs to be dealt with.
Best wishes from Riley.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
