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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
