linux-kernel - Re: Built in PS2 keyboard in new ASUS/acer laptops can not wake up system after s2idle

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] [day] [month] [year] [list]

Date:   Fri, 17 Aug 2018 10:04:19 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Drake <drake@...lessm.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Chris Chiu <chiu@...lessm.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        linux-input@...r.kernel.org, Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>
Subject: Re: Built in PS2 keyboard in new ASUS/acer laptops can not wake up
 system after s2idle

On Fri, Aug 17, 2018 at 4:29 AM Daniel Drake <drake@...lessm.com> wrote:
>
> On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
> >> keyboard wake up the system as expected. We considered to work out a DMI
> >> based quirk for this. But based on the information that EC would not signal SCI
> >> event for WiskyLake models, we'd like to know if there's any generic solution?
> >> Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
> >> wake up?
> >
> > A udev rule sounds like a good idea to me.
>
> What would the udev rule look like though?
>
> Match for Intel CPU generation (WhiskyLake) and laptop chassis type
> and then enable i8042 wakeups? While that seems like the most accurate
> reflection of the situation which we are seeing across multiple
> vendors, it doesn't feel right and seems unlikely to be accepted by
> systemd upstream.
>
> In previous designs, pressing a key while the system was in S3 sleep
> would cause a SCI interrupt due to the firing of the EC GPE, which
> effectively meant that keyboard wakeups were on by default and could
> not be disabled. Also USB keyboards have wakeups on by default (see
> usbhid_start()). Just these new platforms have this
> unfortunate/accidental behaviour change...
>
> Would it make sense to turn i8042 wakeups on by default on the kernel
> side? I don't know if any particular conditions are applied, but that
> would appear to be the default Win10 behaviour here.

Yes, it would, but that might prevent some systems from suspending at
all in theory if there are keyboard interrupts on them occurring
during system-wide suspend, for example.

Otherwise, it would just be a matter of calling device_wakeup_enable()
at init time for the keyboard port (as long as you know which one of
them is the keyboard).