linux-kernel - Re: [PATCH] HID: usbhid: enable remote wakeup for mice

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Feb 2023 10:03:22 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     "Limonciello, Mario" <Mario.Limonciello@....com>,
        Oliver Neukum <oneukum@...e.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Michael Wu <michael@...winnertech.com>
Cc:     "jikos@...nel.org" <jikos@...nel.org>,
        "benjamin.tissoires@...hat.com" <benjamin.tissoires@...hat.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Gong, Richard" <Richard.Gong@....com>
Subject: Re: [PATCH] HID: usbhid: enable remote wakeup for mice

On 23.02.23 20:41, Limonciello, Mario wrote:

Hi,

>> As a system wakeup source a mouse that generates events when
>> it is moved, however, would make the system unsuspendable, whenever
>> even
>> a bit of vibration is acting on the system.
>> And as S4 is used in many setups to prevent an uncontrolled shutdown
>> at low power, this must work.
> 
> At least in my version of the series, this is part of the reason that it was
> only intended to be used with s2idle.

Yes, that is sensible. If these patches are to be taken at all, that will
be a necessary condition to meet. But it is not sufficient.
  
> The kernel driver is well aware of what power state you're in the suspend
> callback (pm_suspend_target_state).
> 
> What about if we agreed to treat this one special by examining that?
> 
> If the sysfs is set to "enabled"

If user space needs to manipulate sysfs at all, we can have user space
tell kernel space exactly what to do. Hence I see no point in
conditional interpretations values in sysfs at that point.

We are discussing the kernel's default here.

> * During suspend if your target is s2idle -> program it
> * During suspend if your target is mem -> disable it
> * During suspend if your target is hibernate -> disable it

To my mind these defaults make sense.
However, do they make much more sense than what we are doing now?

> With that type of policy on how to handle the suspend call in place
> perhaps we could set it to enabled by default?

It pains me to say, but I am afraid in that regard the only
decision that will not cause ugly surprises is to follow Windows.
Yet, what is wrong about the current defaults?
  
> Turning on "autosuspend" for USB mice makes them behave pretty
> similarly to how they work when they're marked for remote wakeup.

Because it is exactly the same mechanism.
  
> On some mice the lasers turn off, and they only wakeup when you
> press a button or roll a wheel.

Yes. And _some_ is the exact problem. If we could tell, _how_ mice
react, this discussion were unnecessary.

	Regards
		Oliver