From: Benson Leung <bleung@chromium.org>
usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
cleared when a device is closed.
In usbhid_open, usb_autopm_get_interface is called before setting the
needs_remote_wakeup flag, and usb_autopm_put_interface is called after
hid_start_in. However, when the device is closed in usbhid_close, we
simply reset the flag and the device stays awake even though it could be
suspended.
This patch adds calls to usb_autopm_get_interface and
usb_autopm_put_interface when we reset usbhid->intf->needs_remote_wakeup
flag, giving the system chance to put the device to sleep.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/usbhid/hid-core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
From: Oliver Neukum <oneukum@suse.com> Date: 2017-09-09 07:39:12
Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
From: Benson Leung <bleung@chromium.org>
usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
cleared when a device is closed.
In usbhid_open, usb_autopm_get_interface is called before setting the
needs_remote_wakeup flag, and usb_autopm_put_interface is called after
hid_start_in. However, when the device is closed in usbhid_close, we
simply reset the flag and the device stays awake even though it could be
suspended.
Hi,
but if the device is asleep, we do not want to wake it just to reset
the flag. Please use the no resume varieties. They did not exist when this
code was written and that is the reason behind the current code.
As it is your patch does more harm than good.
Regards
Oliver
Hi Oliver,
On Sat, Sep 09, 2017 at 09:35:52AM +0200, Oliver Neukum wrote:
Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
quoted
From: Benson Leung <redacted>
usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
cleared when a device is closed.
In usbhid_open, usb_autopm_get_interface is called before setting the
needs_remote_wakeup flag, and usb_autopm_put_interface is called after
hid_start_in. However, when the device is closed in usbhid_close, we
simply reset the flag and the device stays awake even though it could be
suspended.
Hi,
but if the device is asleep, we do not want to wake it just to reset
the flag. Please use the no resume varieties. They did not exist when this
code was written and that is the reason behind the current code.
Thanks for the pointer. I'll respin the patch with the no_resume version of
usb_autopm_get_interface and retest.
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Chromium OS Project
bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
Hi Oliver,
On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
Thanks for the pointer. I'll respin the patch with the no_resume version of
usb_autopm_get_interface and retest.
I went and tried this patch but with usb_autopm_get_interface_no_resume instead
and the original bug I was trying to fix with a Yubikey hid security key came
back, so something is still wrong here.
I went ahead and filed a bug to track this here:
https://bugs.chromium.org/p/chromium/issues/detail?id=764112
I'll find some time to dig into this deeper and understand why this device
ends up getting stuck in active instead of suspending when all handles are
closed.
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
On Mon, Sep 11, 2017 at 4:29 PM, Benson Leung [off-list ref] wrote:
Hi Oliver,
On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
quoted
Thanks for the pointer. I'll respin the patch with the no_resume version of
usb_autopm_get_interface and retest.
I went and tried this patch but with usb_autopm_get_interface_no_resume instead
and the original bug I was trying to fix with a Yubikey hid security key came
back, so something is still wrong here.
I went ahead and filed a bug to track this here:
https://bugs.chromium.org/p/chromium/issues/detail?id=764112
I'll find some time to dig into this deeper and understand why this device
ends up getting stuck in active instead of suspending when all handles are
closed.
Meh, it is problem in hidraw that basically does
usb_autopm_put_interface() before letting usbhid_close() to run. Once
I swap hid_hw_power() and hid_hw_close() it autosuspends properly.
I just sent out a patch.
Thanks.
--
Dmitry