On Tue, 25 Sep 2012, Ming Lei wrote:
> 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().
For this case, I think hid_suspend() needs to test whether wakeup is
enabled and a key is pressed. If both of those are true, we should
call pm_wakeup_event(). We should not call pm_wakeup_event() if wakeup
is not enabled.
I'm afraid that some drivers might return -EBUSY when they shouldn't,
that is, when wakeup is not enabled or a wakeup condition is not
present. (The core can test udev->do_remote_wakeup but it can't test
for a wakeup condition.) If we can guarantee that this never happens
then yes, usb_suspend_interface() could call pm_wakeup_event().
On the other hand, for the particular case of a usb keyboard, I'm not
sure this is the right thing to do. Suppose you try to suspend the
system by typing "echo ram >/sys/power/state" and pressing Enter.
Before you can release the Enter key, the suspend will fail. You'd
have to type something like "sleep 1 ; echo ram >/sys/power/state".
> 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?
I don't think that makes much difference. When the system is going to
sleep, people don't expect it to react quickly to anything.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
