On Tue, Sep 25, 2012 at 3:34 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
>
> Do we really need to? Remember, you are adding this new code only
> because some Genesys Logic hubs are buggy. Is there any reason to
> think other devices will have similar bugs?
Hub is a bit special because the event is handled in two steps:
- report the change by interrupt endpoint
- handle the change by get status/change and clear the change
So hub can send its remote wakeup if the change hasn't been cleared
even the event has been reported to driver(urb completed).
For other drivers, it is common that one event is handled in just one step:
- read the transfer_buffer in urb complete and handle the data
So once the urb is completed, the device may not send remote resume
any more. Or just simply don't send it until key is pressed during suspend.
For example on usb HID, see below code in hid_suspend():
if (PMSG_IS_AUTO(message) && test_bit(HID_KEYS_PRESSED,
&usbhid->iofl)) {
status = -EBUSY;
goto failed;
}
The comment said that most keyboards won't wakeup if a key is released.
If the urb is just completed during suspend(), don't we need to call
pm_wakeup_event() for it? I don't think there will be remote wakeup
for the handled action. In fact, it can be observed easily if some delay
is added before hid_cancel_delayed_stuff() inside hid_suspend().
>
> As long as the device issues a remote wakeup request at the proper time
> (i.e., whenever it is suspended with wakeup enabled and an event needs
> to be processed), this workaround isn't needed.
Also IMO, during system sleep, it is better to handle the wakeup
asap even though the remote wakeup can be generated later
suppose someone triggered one event during or before the
driver's suspend(), right?
Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
