Re: [rft]power management for usbtouch

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Jun 30, 2008 at 11:47:28AM -0400, Alan Stern wrote:
> On Mon, 30 Jun 2008, Dmitry Torokhov wrote:
> 
> > > > 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