On Mon, Jun 30, 2008 at 11:47:28AM -0400, Alan Stern wrote:

On Mon, 30 Jun 2008, Dmitry Torokhov wrote:

quoted

quoted

quoted

Forcing a disconnection during suspend might be a good idea.  But if 
you do, is there any reason to consider manual suspension different 
from system sleep?

During system sleep user space is asleep and cannot make demands
on drivers. If you force a device to sleep, the driver cannot work. Therefore
it should not be bound to such a device. It's cleaner to disconnect.

I'd agree with this. Otherwise we need somehow to be able to resync
the state of the device (like have LEDs and repeat rate reset,
re-upload force-feedback effects, etc, etc) once device is resumed.
So... what is the consensus? Do we need to worry about manual
device-level suspension or it will be reworked/removed?

My feeling is that we will leave manual suspension in the kernel.  The
code passed to the USB driver's suspend method will be changed so that
the method can tell whether it is being called for a system sleep vs.
an autosuspend vs. a manual suspend.

Ok, I see... So what does a device do when it is suspended and a
request comes in? Does it automatically resume and service the request
(and potentially goes back to sleep)? Does it queue the request for
later? Ignore it? Is it a system-wide policy or up to the device
[class]?

-- 
Dmitry