From: Bartu Alev <bartualev@gmail.com>
To: "Corentin Chary" <corentin.chary@gmail.com>,
"Luke D. Jones" <luke@ljones.dev>,
"Denis Benato" <denis.benato@linux.dev>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Antheas Kapenekakis" <lkml@antheas.dev>,
"Benjamin Tissoires" <bentiss@kernel.org>
Cc: Denis Benato <benato.denis96@gmail.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, Bartu Alev <bartualev@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH 1/2] platform/x86: asus-wmi: clamp keyboard brightness hotkey updates
Date: Sun, 25 Oct 2026 21:29:36 +0300 [thread overview]
Message-ID: <20261025-b4-asus-kbd-fixes-v1-1-fa4dcf7d2a69@gmail.com> (raw)
In-Reply-To: <20261025-b4-asus-kbd-fixes-v1-0-fa4dcf7d2a69@gmail.com>
Brightness hotkeys (NOTIFY_KBD_BRTUP and NOTIFY_KBD_BRTDWN) pass an
incremented or decremented level into kbd_led_set_by_kbd(). The driver
assumes the new level stays within valid bounds before queuing work to
update the hardware register:
scoped_guard(spinlock_irqsave, &asus_ref.lock) {
asus->kbd_led_wk = value;
asus->kbd_led_notify = true;
}
Unlike asus_hid_event(), kbd_led_set_by_kbd() never clamps this value.
Pressing brightness-down while the backlight is already off stores -1
in asus->kbd_led_wk. Subsequent presses decrement the counter further
(-2, -3, and so on). When kbd_led_update_all() runs, its "value >= 0"
check drops the work item, leaving the hardware state untouched while
clearing asus->kbd_led_notify.
Userspace listeners receive the unclamped value through
led_classdev_notify_brightness_hw_changed(). Because that interface takes
an unsigned int, the negative integer wraps to 4294967295, returning
-ENODATA to sysfs readers. The keyboard remains unresponsive to upward
brightness hotkeys until the user presses brightness-up enough times to
cancel every negative decrement. At maximum brightness, brightness-up
leaks 4 to userspace, which exceeds max_brightness (3).
Clamp the input in kbd_led_set_by_kbd() to [0, ASUS_EV_MAX_BRIGHTNESS].
In kbd_led_update_all(), refresh the local value from asus->kbd_led_wk
under asus_ref.lock before notifying userspace, so coalesced work items
emit the clamped state instead of the initial snapshot. Stable trees
need this because negative values break sysfs reporting and make the
brightness hotkeys appear dead until the counter climbs back to zero.
Fixes: 7525566abd360 ("platform/x86: asus-wmi: add keyboard brightness event handler")
Cc: stable@vger.kernel.org
Cc: Antheas Kapenekakis <lkml@antheas.dev>
Signed-off-by: Bartu Alev <bartualev@gmail.com>
---
drivers/platform/x86/asus-wmi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index b33ebdb21aa21..2478361b9b531 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1807,8 +1807,10 @@ static void kbd_led_update_all(struct work_struct *work)
if (value >= 0)
do_kbd_led_set(&asus->kbd_led, value);
if (notify) {
- scoped_guard(spinlock_irqsave, &asus_ref.lock)
+ scoped_guard(spinlock_irqsave, &asus_ref.lock) {
asus->kbd_led_notify = false;
+ value = asus->kbd_led_wk;
+ }
led_classdev_notify_brightness_hw_changed(&asus->kbd_led, value);
}
}
@@ -1961,7 +1963,7 @@ static int kbd_led_set(struct led_classdev *led_cdev, enum led_brightness value)
static void kbd_led_set_by_kbd(struct asus_wmi *asus, enum led_brightness value)
{
scoped_guard(spinlock_irqsave, &asus_ref.lock) {
- asus->kbd_led_wk = value;
+ asus->kbd_led_wk = clamp_val(value, 0, ASUS_EV_MAX_BRIGHTNESS);
asus->kbd_led_notify = true;
}
queue_work(asus->led_workqueue, &asus->kbd_led_work);
--
2.56.0
next prev parent reply other threads:[~2026-10-25 18:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 18:29 [PATCH 0/2] platform/x86: asus-wmi: fix and unify keyboard brightness key handling Bartu Alev
2026-10-25 18:29 ` Bartu Alev [this message]
2026-10-25 18:29 ` [PATCH 2/2] platform/x86: asus-wmi: unify WMI and HID keyboard brightness stepping Bartu Alev
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=20261025-b4-asus-kbd-fixes-v1-1-fa4dcf7d2a69@gmail.com \
--to=bartualev@gmail.com \
--cc=benato.denis96@gmail.com \
--cc=bentiss@kernel.org \
--cc=corentin.chary@gmail.com \
--cc=denis.benato@linux.dev \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@antheas.dev \
--cc=luke@ljones.dev \
--cc=platform-driver-x86@vger.kernel.org \
--cc=stable@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
all inboxes | Powered by JetHome®