On Wed, 12 Oct 2011, Oliver Neukum wrote: > Am Mittwoch, 12. Oktober 2011, 16:33:13 schrieb Alan Stern: > > > I admit to not being very familiar with the way usbhid handles > > autosuspend. However in general, if a suspend fails because the driver > > is busy, then when the driver stops being busy it should initiate the > > next round of autosuspend. In this case, when the key release has been > > fully processed, the driver should call usb_put_interface_async() or > > something similar, which would restart the timer. > > I see. I can do this although it is not very elegant, because > the pm counters at this point ought to be 0 already. Well, if the usage counter is 0 then you wouldn't want to call usb_put_interface_async(). On the other hand, if the usage counter is 0 then by definition the device isn't in use, so you shouldn't need to fail an autosuspend request -- not unless it races with an I/O event. To anticipate your next question, how should such a race be hanlded? Here's one way: I/O event occurs; interrupt handler is called. Handler sets a device_busy flag. Autosuspend attempt occurs because the usage counter is 0. Suspend routine returns -EBUSY because device_busy is set. Handler calls usb_get_interface_async(). The device is active, so the handler goes on to process the event. Handler calls usb_put_interface_async(). > Arguably a driver is the wrong layer to do this. Are you suggesting the usb_runtime_suspend() should call usb_mark_last_busy() and pm_runtime_autosuspend() if usb_suspend_both() returns -EBUSY or -EAGAIN? This would allow a driver to block autosuspend attempts while leaving the usage counter set to 0. 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
