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]

Message-ID: <MN0PR12MB61017A45BEF80013FD7B77D5E2AC9@MN0PR12MB6101.namprd12.prod.outlook.com>
Date:   Tue, 28 Feb 2023 18:50:18 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     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

[Public]



> -----Original Message-----
> From: Oliver Neukum <oneukum@...e.com>
> Sent: Tuesday, February 28, 2023 03:03
> 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; benjamin.tissoires@...hat.com; linux-
> usb@...r.kernel.org; linux-input@...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.

Ack.

> 
> > 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.

Right, I was meaning if the kernel defaulted to enabled or if userspace
changed it to enabled to follow this behavior.

> 
> > * 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?

If you're talking about purely "policy default", I think it makes more sense.

Userspace can still change it, and it better aligns with what Windows does
out of the box.

> 
> > 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?

I still keep getting inquiries about this where teams that work on the same
hardware for Windows and Linux complain about this difference during
their testing.

I keep educating them to change it in sysfs (or to use a udev rule), but
you have to question if you keep getting something asked about policy
over and over if it's actually the right policy.