All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-03-30 21:57 UTC|newest]

Thread overview: 4+ 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
2026-03-30 19:01 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.