On Mon, 30 Jun 2008, Dmitry Torokhov wrote: > On Mon, Jun 30, 2008 at 12:16:13PM -0400, Alan Stern wrote: > > On Mon, 30 Jun 2008, Dmitry Torokhov wrote: > > > > > > 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]? > > > > What sort of request do you mean? If a device is suspended, it _can't_ > > receive any data (requests or otherwise) over the USB bus. > > > > If a device receives data over some other channel (like a mouse getting > > a button click) while it is suspended, its behavior depends on the > > settings at the time it was suspended. If remote wakeup was disabled > > then the device does essentially nothing (maybe it remembers the data > > for later, maybe not). If remote wakeup was enabled then the device > > should send a wakeup request to the host. > > > > I was talking about system-initiated requests... Setting LED on a keyboard, > setting rate on a mouse, uploading a force-feedback effect, writing a > sector on a disk, etc... Then I don't understand the original question, since it's impossible for the system to send a request to a suspended device. Did you perhaps intend to ask what a _driver_ does when its device is suspended and it receives an I/O request? The action depends on the reason for the suspend: If the device was suspended for a system sleep, the request should be deferred until the device is resumed when the system wakes up. If the device was autosuspended, the driver should autoresume the device and then transmit the request. If the device was manually suspended, the driver should fail the request. In practice, what is most likely to happen is that the driver will always try to autoresume the device. Then: If a system sleep is in progress, the autoresume is supposed to block until the system wakes up (but this behavior has not yet been implemented -- generally no requests can arrive during a system sleep anyway because userspace is frozen). If the device is autosuspended, the autoresume works and the driver can transmit the request. If the device is manually suspended, the autoresume fails and so the driver fails the request. Alan Stern -- 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
