| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <0e700e9b-35db-f419-813a-1277e0b7476a@amd.com>
Date: Thu, 16 Jun 2022 16:47:09 -0500
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Jiri Kosina <jikos@...nel.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
"open list:USB HID/HIDBP DRIVERS [USB KEYBOARDS, MICE, REM..."
<linux-usb@...r.kernel.org>,
"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
Richard Gong <richard.gong@....com>
Subject: Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource
On 6/16/2022 16:28, Greg KH wrote:
> On Thu, Jun 16, 2022 at 01:31:42PM -0500, Mario Limonciello wrote:
>> The USB HID transport layer doesn't set mice for wakeup by default so users
>> can not wake system from s2idle using wired USB mouse. However, users can
>> wake the same system from Modern Standby on Windows with the same wired
>> USB mouse.
>>
>> Microsoft documentation indicates that all USB mice and touchpads should
>> be waking the system from Modern Standby. To align expectations from users
>> make this behavior the same when the system is configured by the OEM and
>> the user to use s2idle in Linux.
>>
>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdesign%2Fdevice-experiences%2Fmodern-standby-wake-sources%23input-devices-1&data=05%7C01%7Cmario.limonciello%40amd.com%7C98b9958eb5304304fcbf08da4fdf1cdf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910116925045711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZI7wX9jq38V0bNZFjca2qbVZrU4frillcrZ6WEGEn%2FQ%3D&reserved=0
>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-usb%2F20220404214557.3329796-1-richard.gong%40amd.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C98b9958eb5304304fcbf08da4fdf1cdf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910116925045711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tt1eHDJqtKybfNw8XDF9ZFCuAMJJEotOB2NnGuXItA8%3D&reserved=0
>> Suggested-by: Richard Gong <richard.gong@....com>
>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>> ---
>> More people keep coming to us confused that they couldn't wake a Linux system
>> up from sleep using a mouse, so this patch is being revived.
>
> How many different devices did you test this on?
I tested it on all the mice I have at my disposal and the AMD systems I
have that support s2idle on top of 5.19-rc2. As the code path doesn't
run without s2idle any more I didn't look at that.
Mostly Logitech, a few no-name brands. Both wireless (via a proprietary
dongle) and wired.
Richard tested (the earlier version of it) on what he had available to
him. A few other people in AMD tested a variant of it with the mice
they had as well.
I know you have concerns from the previous version on test coverage and
I feel that if this is accepted it will get a lot more testing in the
various labs from other companies as well. We can put some explicit
calls to testing on this early on in in the RC cycle to try to encourage
more testing.
>
>>
>> Microsoft documentation doesn't indicate any allowlist for this behavior, and
>> they actually prescribe it for all USB mice and touchpads.
>> v1->v2:
>> * Resubmit by Mario
>> * Update commit message
>> * Only activate on systems configured by user and OEM for using s2idle
>>
>> drivers/hid/usbhid/hid-core.c | 36 ++++++++++++++++++++++++-----------
>> 1 file changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
>> index 4490e2f7252a..3a1214ecec49 100644
>> --- a/drivers/hid/usbhid/hid-core.c
>> +++ b/drivers/hid/usbhid/hid-core.c
>> @@ -12,6 +12,7 @@
>> /*
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/module.h>
>> #include <linux/slab.h>
>> #include <linux/init.h>
>> @@ -26,6 +27,7 @@
>> #include <linux/wait.h>
>> #include <linux/workqueue.h>
>> #include <linux/string.h>
>> +#include <linux/suspend.h>
>>
>> #include <linux/usb.h>
>>
>> @@ -1176,17 +1178,29 @@ static int usbhid_start(struct hid_device *hid)
>> usb_autopm_put_interface(usbhid->intf);
>> }
>>
>> - /* Some keyboards don't work until their LEDs have been set.
>> - * Since BIOSes do set the LEDs, it must be safe for any device
>> - * that supports the keyboard boot protocol.
>> - * In addition, enable remote wakeup by default for all keyboard
>> - * devices supporting the boot protocol.
>> - */
>> - if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
>> - interface->desc.bInterfaceProtocol ==
>> - USB_INTERFACE_PROTOCOL_KEYBOARD) {
>> - usbhid_set_leds(hid);
>> - device_set_wakeup_enable(&dev->dev, 1);
>> + if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
>> + switch (interface->desc.bInterfaceProtocol) {
>> + /* Some keyboards don't work until their LEDs have been set.
>> + * Since BIOSes do set the LEDs, it must be safe for any device
>> + * that supports the keyboard boot protocol.
>> + * In addition, enable remote wakeup by default for all keyboard
>> + * devices supporting the boot protocol.
>> + */
>> + case USB_INTERFACE_PROTOCOL_KEYBOARD:
>> + usbhid_set_leds(hid);
>> + device_set_wakeup_enable(&dev->dev, 1);
>> + break;
>> +#ifdef CONFIG_ACPI
>
> Why a #ifdef?
AFAICT acpi_gbl_FADT is only available when CONFIG_ACPI is defined. I
didn't think it was reasonable to make usbhid depend on ACPI.
>
>> + /* Setup remote wakeup by default for mice supporting boot
>> + * protocol if the system supports s2idle
>> + */
>> + case USB_INTERFACE_PROTOCOL_MOUSE:
>> + if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0 &&
>
> That seems odd, there's no acpi/pm call for this instead?
No, there's not. You'll find checking of this bit in about 8 other
places too.
I probably should explain the difference from this and
pm_suspend_default_s2idle:
acpi_gbl_FADT-> There is a bit in here indicating that the system
supports low power idle.
This bit is set by the OEM and is used to indicate that the system
should use the special ACPI LPS0 device and should prefer s2idle over
s3 if both are present.
pm_suspend_default_s2idle-> This means that the system has been
configured to s2idle after processing the kernel command line.
If the system offers both S3 and S2idle, users can override what's in
the FADT to set the default as they desire.
This is also how i8042 decides to set keyboard wakeups only in s2idle
mode.
>
>> + pm_suspend_default_s2idle())
>> + device_set_wakeup_enable(&dev->dev, 1);
>> + break;
>> +#endif
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists