From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f182.google.com (mail-dy1-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AAEF3A759C for ; Mon, 30 Mar 2026 21:57:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774907826; cv=none; b=LCPRHEE+Dkfyzrh/ZpBBKhZ4+XfKw4khVaYLprxDTh0wdUXXZLNW6Jc15TXkNYN1BFWlUlu4LRA/SGSVnCAVTh+6ZFsaPg+8AbXWCC4uWtPXTYP4Q66Vy/lyaJdORFraKym8yba8d2huMZ6JumgEXbqfnB4pipeNK5FrDgtvyXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774907826; c=relaxed/simple; bh=9woQ7/fKlrxTFeXRYDNkyTlKx3TV9a+ou2v1wOwQDog=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EfSUGcMBfoWUUkLBMEk7Vt8i5ToELcIjlGJlk7sBaPorI2OXpQZq8+E3kFpFVKIyZDYvDZ+CMI3eGigRGQi/LH12/3awuvdzg5JSUdLK7axr26ACjd10+u2DRIzywVX9D6KNJtpse+tvMfCXYHY+x6Ytl/nNb8MOQo/Rap1f9dg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=seFMp8lr; arc=none smtp.client-ip=74.125.82.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="seFMp8lr" Received: by mail-dy1-f182.google.com with SMTP id 5a478bee46e88-2c56aa62931so813311eec.0 for ; Mon, 30 Mar 2026 14:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774907822; x=1775512622; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=I+Bb0pi9FepnSALzc4+JxhpF660Vu7lbr+LdKjGQZik=; b=seFMp8lrtylW+pvH2BuFRSF0zK/F/cC0yqyd+EYJbhr2x1bo6Qlq5pjgkVabNju7tS K1BBJWLhGQDfoVSSoJJBINlc0+kHwtFL/CJN9N4/ioVIQzuPl+2+lXTnxIqItOWmz+Os pitUWQAuGt8a/B0BFMTePHNJkUfvRA6Y8WI/QpuhZoI/GfJlNvjqxjClOus/H4DPe+BA mpxa7JUxF6vb1FDV25fyPGkBQYwFy6wk9+YwvMx3DG1YPUkS3OJP8mE6BIhQtoAPlBWg qZ6ocSAVaNddnEtR13Y9jHp4kjPNlfQD/NDtTQD6a9ua1y14NTCtwszI7s0IJpeC97Og anhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774907822; x=1775512622; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I+Bb0pi9FepnSALzc4+JxhpF660Vu7lbr+LdKjGQZik=; b=nR+zrBvyBFk+YnbFgB1lkO8S8ZnWbEdDubuhfDyq6KTEsvONodHIkVlSIYlM7MpQcN LJG9AKKPj4tlJbGJYonRUUCTI3i/fAwD21tPO40MujybXGDfMh+53x5C0KbTT6/GnkhC pPelSrlZQzp6JtX9wE+e+7E/gB0y3e+SZMdHZ0SkzPVGy4zOoUelSijC0RWHA/sU/3b0 lZ75fuX1fN7jPNgGypsmgjWe/fmb4WNpUz0i6ZMleTwlddP8EQD9xcDQj5pDMbpEQZU1 m8756xSoDM5wDdi3NywkuHSDuS1vA50OdBiFxThfZy6w0MkwCXa5rLY+3PAVYvRr5P5i jEHQ== X-Forwarded-Encrypted: i=1; AJvYcCVi/PGsxCjQx61COq3KnWTdQCOJG88JcKLnP3tRJb/hpdlh8UkaoHSHOfiAsUVZAiHHPs2WWiluS/dBpNY=@vger.kernel.org X-Gm-Message-State: AOJu0YyES0puBqV8WL5BCjXg/5G5xdAF0fDGjKDkfFBHuMXhT10aoQ54 7VonbX6OOn5RqWqcggoU2l9b9SuTZdqTjPb4RP6mOaQ9YvjwkNuZe+pflgbg6Q== X-Gm-Gg: ATEYQzwijc2ztlLQN/XBvKCp80QFuK2p001Xhcie+zQsUWPev370MF/FU5HoUj7lG3F Xu6wRu7dd/rQet+lxwOiqc/kz23QPrrpRLowLoecB+YMvaoQJVEAFKpo70lA8ibGt1cS2w6P4NP btRwCDYf3uHrlcBlLwgo+CuHkmKW9tKpj5ArKUYaONTLMXnhrNn8/1mrSqyxoR1t/7WaTemcD5P 8rSM4gaf4Zf9lcXm2vCTRdDZ0bDFTalafD5oMwCCEN1Z6vSdtWMyxUZcY00CccFR1Di5MoPzjoT /g/yj0fw7de4+2LB/p0qJN41P7orwnznMdTzcBpZV0LFe5vsEjpY9GGsMDn2jylVXvsBBuH6ijZ /tH46j4Zq9BKWMr9eFOQxsdrWS1uT9CzKxtuCPr5YhE4wwKdbVp7VGSsXLCrnwc0sw2ZYuYCHrT JGd/nDNLpbnngmaaVtoHi1Sy+TJ1R3wz50Mgy2TBtGXs+dgm207zG0yweu7rLdFbNp X-Received: by 2002:a05:7300:324c:b0:2c1:27c:75bd with SMTP id 5a478bee46e88-2c185a67c89mr8201566eec.0.1774907822346; Mon, 30 Mar 2026 14:57:02 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:7f4e:2749:b37a:e9d5]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2c3c68b2721sm7776979eec.14.2026.03.30.14.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 14:57:01 -0700 (PDT) Date: Mon, 30 Mar 2026 14:56:59 -0700 From: Dmitry Torokhov 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 Message-ID: References: <20260330-wakeup-v1-1-d269624fa519@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > > 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