From: "Limonciello, Mario" <Mario.Limonciello@amd.com>
To: Oliver Neukum <oneukum@suse.com>,
Greg KH <gregkh@linuxfoundation.org>,
Michael Wu <michael@allwinnertech.com>
Cc: "jikos@kernel.org" <jikos@kernel.org>,
"benjamin.tissoires@redhat.com" <benjamin.tissoires@redhat.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Gong, Richard" <Richard.Gong@amd.com>
Subject: RE: [PATCH] HID: usbhid: enable remote wakeup for mice
Date: Tue, 28 Feb 2023 18:50:18 +0000 [thread overview]
Message-ID: <MN0PR12MB61017A45BEF80013FD7B77D5E2AC9@MN0PR12MB6101.namprd12.prod.outlook.com> (raw)
In-Reply-To: <f2142d88-259f-302d-da61-e0fc39d1f041@suse.com>
[Public]
> -----Original Message-----
> From: Oliver Neukum <oneukum@suse.com>
> Sent: Tuesday, February 28, 2023 03:03
> To: Limonciello, Mario <Mario.Limonciello@amd.com>; Oliver Neukum
> <oneukum@suse.com>; Greg KH <gregkh@linuxfoundation.org>; Michael
> Wu <michael@allwinnertech.com>
> Cc: jikos@kernel.org; benjamin.tissoires@redhat.com; linux-
> usb@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; Gong, Richard <Richard.Gong@amd.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.
next prev parent reply other threads:[~2023-02-28 18:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 1:39 [PATCH] HID: usbhid: enable remote wakeup for mice Michael Wu
2023-02-22 6:04 ` Greg KH
2023-02-22 19:50 ` Limonciello, Mario
2023-02-23 11:41 ` Oliver Neukum
2023-02-23 11:18 ` Michael Wu
2023-02-23 11:23 ` Greg KH
2023-02-23 12:01 ` Oliver Neukum
2023-02-23 19:41 ` Limonciello, Mario
2023-02-28 9:03 ` Oliver Neukum
2023-02-28 18:50 ` Limonciello, Mario [this message]
2023-02-28 19:05 ` Greg KH
2023-02-28 19:07 ` Limonciello, Mario
2023-02-24 7:02 ` Michael Wu
2023-02-22 8:59 ` Sergei Shtylyov
2023-02-23 4:01 ` Michael Wu
2023-02-22 9:34 ` Oliver Neukum
2023-02-23 11:22 ` Michael Wu
2023-02-23 11:47 ` Oliver Neukum
-- strict thread matches above, loose matches on Subject: below --
2011-10-14 7:54 Benson Leung
2011-10-14 8:18 ` Oliver Neukum
2011-10-14 13:56 ` Alan Stern
2011-10-14 14:00 ` Jiri Kosina
2011-10-14 14:58 ` Benson Leung
2011-10-14 15:09 ` Alan Stern
2011-10-15 9:43 ` Oliver Neukum
2011-10-15 19:07 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN0PR12MB61017A45BEF80013FD7B77D5E2AC9@MN0PR12MB6101.namprd12.prod.outlook.com \
--to=mario.limonciello@amd.com \
--cc=Richard.Gong@amd.com \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael@allwinnertech.com \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).