From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: hbarnor@chromium.org
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source
Date: Mon, 30 Mar 2026 14:56:59 -0700 [thread overview]
Message-ID: <acrwy_Y6QMapp5fw@google.com> (raw)
In-Reply-To: <20260330-wakeup-v1-1-d269624fa519@chromium.org>
Hi Henry,
On Mon, Mar 30, 2026 at 12:01:50PM -0700, Henry Barnor via B4 Relay wrote:
> From: Henry Barnor <hbarnor@chromium.org>
>
> In systems using suspend-to-idle, the serio core calls atkbd_cleanup()
> during the suspend transition. Currently, this function unconditionally
> calls atkbd_disable(), setting atkbd->enabled to false.
>
> This creates a race condition during wakeup: when a key is pressed to
> wake the system, atkbd_receive_byte() is triggered. It correctly signals
> a wakeup event to the PM core, but then checks atkbd->enabled. Because
> the driver was disabled during suspend, the scancode is discarded.
> The system wakes up, but the initial keystroke is lost.
>
> This is particularly problematic for platforms like Android that rely on
> the input event itself to complete the wakeup transition and turn on the
> screen. On these systems, the device wakes up but remains in a dim state
> because the initial interaction was lost.
This is really for the Android system layer to solve.
>
> This patch modifies atkbd_cleanup() to skip disabling and resetting
> the keyboard if the device is configured as a wakeup source. This
> preserves atkbd->enabled = true through the sleep duration, ensuring
> the wake-up scancode is reported to the input subsystem.
>
> Note that this also affects the shutdown path. However, if a device is
> configured for wakeup, skipping the reset to "default" state is
> consistent with the goal of allowing the hardware to trigger a
> system-state transition. Modern BIOS/UEFI implementations perform their
> own keyboard initialization, so skipping the legacy reset on reboot
> for these devices poses minimal risk.
We unfortunately need to support devices much older than that, so we can
not be sure that this change is safe. Historically there we a lot of
instances where systems were unhappy if we attempted to enter shutdown
or suspend paths with devices in state other than freshly reset.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2026-03-30 21:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 19:01 [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source Henry Barnor via B4 Relay
2026-03-30 21:56 ` Dmitry Torokhov [this message]
2026-04-05 5:36 ` Henry Barnor
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=acrwy_Y6QMapp5fw@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=hbarnor@chromium.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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