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

Signed-off-by: Henry Barnor <hbarnor@chromium.org>
---
 drivers/input/keyboard/atkbd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 4560d3964eee..1fba1932412e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -958,6 +958,9 @@ static void atkbd_cleanup(struct serio *serio)
 {
 	struct atkbd *atkbd = atkbd_from_serio(serio);
 
+	if (device_may_wakeup(&serio->dev))
+		return;
+
 	atkbd_disable(atkbd);
 	ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_DEF);
 }

---
base-commit: 6d4b67a2a76a4ff2393fe88119ae4332821b82b4
change-id: 20260310-wakeup-ec57a88a0162

Best regards,
-- 
Henry Barnor <hbarnor@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