* Re: [PATCH] HID: hid-lg-g15: Add hw_brightness_changed support for the G510 keyboard
From: Jiri Kosina @ 2025-10-14 9:50 UTC (permalink / raw)
To: Hans de Goede; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20251001211941.4415-1-hansg@kernel.org>
On Wed, 1 Oct 2025, Hans de Goede wrote:
> Add hw_brightness_changed support for the G510 keyboard, so that e.g.
> GNOME will show an OSD notification when toggling the backlight on/off
> with the button the keyboard.
>
> Note that it is not possible to turn the backlight back on by writing
> /sys/class/leds/.../brightness it can only be turned on by pressing
> the button on the keyboard. To reflect this /sys/class/leds/.../brightness
> will always report the last brightness value independent of the on/off
> toggle built into the keyboard.
>
> Signed-off-by: Hans de Goede <hansg@kernel.org>
Applied on top of hid.git#for-6.19/logitech, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: Add ALWAYS_POLL quirk for VRS R295 steering wheel
From: Jiri Kosina @ 2025-10-14 9:49 UTC (permalink / raw)
To: Oleg Makarenko; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20250929154639.1014717-1-oleg@makarenk.ooo>
On Mon, 29 Sep 2025, Oleg Makarenko wrote:
> This patch adds ALWAYS_POLL quirk for the VRS R295 steering wheel joystick.
> This device reboots itself every 8-10 seconds if it is not polled.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: avoid Cooler Master MM712 dongle wakeup bug
From: Jiri Kosina @ 2025-10-14 9:48 UTC (permalink / raw)
To: Tristan Lobb; +Cc: bentiss, linux-input, linux-kernel
In-Reply-To: <20250928162543.226114-1-tristan.lobb@it-lobb.de>
On Sun, 28 Sep 2025, Tristan Lobb wrote:
> The Cooler Master Mice Dongle includes a vendor defined HID interface
> alongside its mouse interface. Not polling it will cause the mouse to
> stop responding to polls on any interface once woken up again after
> going into power saving mode.
>
> Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and
> the Dongle's PID.
>
> Signed-off-by: Tristan Lobb <tristan.lobb@it-lobb.de>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] HID: cp2112: Add parameter validation to data length
From: Jiri Kosina @ 2025-10-14 9:47 UTC (permalink / raw)
To: Deepak Sharma
Cc: bentiss, linux-input, linux-kernel, linux-kernel-mentees, skhan,
david.hunter.linux, syzbot+7617e19c8a59edfbd879
In-Reply-To: <20250926145811.273174-1-deepak.sharma.472935@gmail.com>
On Fri, 26 Sep 2025, Deepak Sharma wrote:
> Syzkaller reported a stack OOB access in cp2112_write_req caused by lack
> of parameter validation for the user input in I2C SMBUS ioctl in cp2112
> driver
>
> Add the parameter validation for the data->block[0] to be bounded by
> I2C_SMBUS_BLOCK_MAX + the additional compatibility padding
>
> Reported-by: syzbot+7617e19c8a59edfbd879@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7617e19c8a59edfbd879
> Tested-by: syzbot+7617e19c8a59edfbd879@syzkaller.appspotmail.com
> Signed-off-by: Deepak Sharma <deepak.sharma.472935@gmail.com>
Applied to hid.git#for-6.18/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: intel-thc-hid: intel-quickspi: Add ARL PCI Device Id's
From: Jiri Kosina @ 2025-10-14 9:44 UTC (permalink / raw)
To: Abhishek Tamboli
Cc: even.xu, xinpeng.sun, bentiss, mpearson-lenovo,
srinivas.pandruvada, linux-input, linux-kernel
In-Reply-To: <20250924043720.5545-1-abhishektamboli9@gmail.com>
On Wed, 24 Sep 2025, Abhishek Tamboli wrote:
> Add the missing PCI ID for the quickspi device used on
> the Lenovo Yoga Pro 9i 16IAH10.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=220567
>
> Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com>
> ---
> Changes in v2:
> - Change the max_packet_size_value to align
> with MAX_PACKET_SIZE_VALUE_MTL
Applied to hid.git#for-6.18/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from level to edge detection
From: Jiri Kosina @ 2025-10-14 9:29 UTC (permalink / raw)
To: Even Xu; +Cc: bentiss, srinivas.pandruvada, linux-input, linux-kernel,
Rui Zhang
In-Reply-To: <20250919070939.223954-1-even.xu@intel.com>
On Fri, 19 Sep 2025, Even Xu wrote:
> The original implementation used level detection for the first interrupt
> after device reset to avoid potential interrupt line noise and missed
> interrupts during the initialization phase. However, this approach
> introduced unintended side effects when tested with certain touch panels,
> including:
> - Delayed hardware interrupt response
> - Multiple spurious interrupt triggers
>
> Switching back to edge detection for the first interrupt resolves these
> issues while maintaining reliable interrupt handling.
>
> Extensive testing across multiple platforms with touch panels from
> various vendors confirms this change introduces no regressions.
>
> Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation")
> Tested-by: Rui Zhang <rui1.zhang@intel.com>
> Signed-off-by: Even Xu <even.xu@intel.com>
Applied to hid.git#for-6.18/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: intel-quicki2c: Fix wrong type casting
From: Jiri Kosina @ 2025-10-14 9:27 UTC (permalink / raw)
To: Xinpeng Sun
Cc: bentiss, srinivas.pandruvada, even.xu, linux-input, linux-kernel,
kernel test robot
In-Reply-To: <20251009033108.1212471-1-xinpeng.sun@intel.com>
On Thu, 9 Oct 2025, Xinpeng Sun wrote:
> The type definition of qcdev->i2c_max_frame_size is already
> u32, so remove the unnecessary type casting le16_to_cpu.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202509280841.pxmgBzKW-lkp@intel.com/
Applied to hid.git#for-6.18/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/6] HID: intel-ish-hid: Various power management improvements for hibernation
From: Jiri Kosina @ 2025-10-14 9:24 UTC (permalink / raw)
To: Zhang Lixu; +Cc: linux-input, srinivas.pandruvada, benjamin.tissoires
In-Reply-To: <20250919010559.165076-1-lixu.zhang@intel.com>
On Fri, 19 Sep 2025, Zhang Lixu wrote:
> This patch series introduces several improvements to the power management and hibernation
> handling in the intel-ish-hid driver. Key changes include:
>
> - Separating hibernate callbacks in dev_pm_ops for clearer power state transitions
> - Using IPC RESET in ish_wakeup() to ensure reliable device wakeup
> - Scheduling firmware reset work on RESET_NOTIFY/ACK for robust recovery
> - Resetting client state on resume from D3 to maintain consistency
> - Enhancing resume logic in ishtp-hid-client for better stability
>
> These patches enhance reliability, improve power management flow. All changes
> have been validated on TwinLake (ISH 5.4), ArrowLake (ISH 5.6), and PantherLake
> (ISH 5.8) platforms.
Applied to hid.git#for-6.19/intel-ish, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 2/3] arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider
From: Konrad Dybcio @ 2025-10-14 9:22 UTC (permalink / raw)
To: david, Dmitry Torokhov, Jonathan Corbet, Jiri Kosina,
Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Casey Connolly,
Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles
In-Reply-To: <20251014-op6-tri-state-v7-2-938a6367197b@ixit.cz>
On 10/14/25 11:20 AM, David Heidelberg via B4 Relay wrote:
> From: Gergo Koteles <soyer@irl.hu>
>
> The previous GPIO numbers were wrong. Update them to the correct
> ones and fix the label.
>
> Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices")
> Signed-off-by: Gergo Koteles <soyer@irl.hu>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RESEND v3] Input: Improve WinWing Orion2 throttle support
From: Jiri Kosina @ 2025-10-14 9:21 UTC (permalink / raw)
To: Ivan Gorinov; +Cc: linux-input, linux-kernel
In-Reply-To: <20251012205054.GA15885@altimeter-info>
On Sun, 12 Oct 2025, Ivan Gorinov wrote:
> Add support for Orion2 throttle configurations with more than 32 buttons
> on the grip handle (this means the device reports more than 80 buttons).
>
> Map additional button codes to KEY_MACRO1 .. KEY_MACRO28.
>
> Make the module simpler, removing report descriptor fixup.
>
> Changes since v2:
> - Add more comments about button mapping
>
> Changes since v1:
> - Correct trivial coding style violations
These changes should go below the '--- ' line so that they don't end up in
the actual git changelog.
Also we use 'HID:' prefix in shortlog.
I've fixed both and applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v7 2/3] arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider
From: David Heidelberg via B4 Relay @ 2025-10-14 9:20 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Casey Connolly, Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, David Heidelberg
In-Reply-To: <20251014-op6-tri-state-v7-0-938a6367197b@ixit.cz>
From: Gergo Koteles <soyer@irl.hu>
The previous GPIO numbers were wrong. Update them to the correct
ones and fix the label.
Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices")
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index dcfffb271fcf3..51a9a276399ac 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -803,8 +803,8 @@ hall_sensor_default: hall-sensor-default-state {
bias-disable;
};
- tri_state_key_default: tri-state-key-default-state {
- pins = "gpio40", "gpio42", "gpio26";
+ alert_slider_default: alert-slider-default-state {
+ pins = "gpio126", "gpio52", "gpio24";
function = "gpio";
drive-strength = <2>;
bias-disable;
--
2.51.0
^ permalink raw reply related
* [PATCH v7 1/3] Input: add ABS_SND_PROFILE
From: David Heidelberg via B4 Relay @ 2025-10-14 9:20 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Casey Connolly, Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, David Heidelberg
In-Reply-To: <20251014-op6-tri-state-v7-0-938a6367197b@ixit.cz>
From: Gergo Koteles <soyer@irl.hu>
ABS_SND_PROFILE used to describe the state of a multi-value sound profile
switch. This will be used for the alert-slider on OnePlus phones or other
phones.
Profile values added as SND_PROFLE_(SILENT|VIBRATE|RING) identifiers
to input-event-codes.h so they can be used from DTS.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/input/event-codes.rst | 6 ++++++
drivers/hid/hid-debug.c | 1 +
include/uapi/linux/input-event-codes.h | 9 +++++++++
3 files changed, 16 insertions(+)
diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index 1ead9bb8d9c64..e4f065dd5a1da 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -241,6 +241,12 @@ A few EV_ABS codes have special meanings:
emitted only when the selected profile changes, indicating the newly
selected profile value.
+* ABS_SND_PROFILE:
+
+ - Used to describe the state of a multi-value sound profile switch.
+ An event is emitted only when the selected profile changes,
+ indicating the newly selected profile value.
+
* ABS_MT_<name>:
- Used to describe multitouch input events. Please see
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 7107071c7c516..c58500d8b94b5 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -3513,6 +3513,7 @@ static const char *absolutes[ABS_CNT] = {
[ABS_DISTANCE] = "Distance", [ABS_TILT_X] = "XTilt",
[ABS_TILT_Y] = "YTilt", [ABS_TOOL_WIDTH] = "ToolWidth",
[ABS_VOLUME] = "Volume", [ABS_PROFILE] = "Profile",
+ [ABS_SND_PROFILE] = "SoundProfile",
[ABS_MISC] = "Misc",
[ABS_MT_SLOT] = "MTSlot",
[ABS_MT_TOUCH_MAJOR] = "MTMajor",
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 4a9fbf42aa9fa..962168c661ccd 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -879,6 +879,7 @@
#define ABS_VOLUME 0x20
#define ABS_PROFILE 0x21
+#define ABS_SND_PROFILE 0x22
#define ABS_MISC 0x28
@@ -988,4 +989,12 @@
#define SND_MAX 0x07
#define SND_CNT (SND_MAX+1)
+/*
+ * ABS_SND_PROFILE values
+ */
+
+#define SND_PROFILE_SILENT 0x00
+#define SND_PROFILE_VIBRATE 0x01
+#define SND_PROFILE_RING 0x02
+
#endif
--
2.51.0
^ permalink raw reply related
* [PATCH v7 3/3] arm64: dts: qcom: sdm845-oneplus: Add alert-slider
From: David Heidelberg via B4 Relay @ 2025-10-14 9:20 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Casey Connolly, Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, Casey Connolly, David Heidelberg,
Konrad Dybcio
In-Reply-To: <20251014-op6-tri-state-v7-0-938a6367197b@ixit.cz>
From: Gergo Koteles <soyer@irl.hu>
The alert-slider is a tri-state sound profile switch found on the
OnePlus 6, Android maps the states to "silent", "vibrate" and "ring".
Expose them as ABS_SND_PROFILE events.
The previous GPIO numbers were wrong. Update them to the correct ones.
Co-developed-by: Casey Connolly <casey@connolly.tech>
Signed-off-by: Casey Connolly <casey@connolly.tech>
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
.../arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 51a9a276399ac..98f5e4c8237a0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -25,6 +25,41 @@ / {
chassis-type = "handset";
qcom,msm-id = <QCOM_ID_SDM845 0x20001>;
+ alert-slider {
+ compatible = "gpio-keys";
+ label = "Alert slider";
+
+ pinctrl-0 = <&alert_slider_default>;
+ pinctrl-names = "default";
+
+ switch-top {
+ label = "Silent";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <SND_PROFILE_SILENT>;
+ gpios = <&tlmm 126 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ };
+
+ switch-middle {
+ label = "Vibrate";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <SND_PROFILE_VIBRATE>;
+ gpios = <&tlmm 52 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ };
+
+ switch-bottom {
+ label = "Ring";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <SND_PROFILE_RING>;
+ gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ };
+ };
+
aliases {
serial0 = &uart9;
serial1 = &uart6;
--
2.51.0
^ permalink raw reply related
* [PATCH v7 0/3] Add support for sound profile switching and leverage for OnePlus slider
From: David Heidelberg via B4 Relay @ 2025-10-14 9:20 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Casey Connolly, Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, David Heidelberg, Casey Connolly,
Konrad Dybcio
This series add initial support for OnePlus 6 and 6T, but other OnePlus
phones contains same mechanism to switch sound profiles.
This code was tested for two years within the downstream Snapdragon 845 tree.
It is now perfectly integrated with feedbackd in the Phosh environment.
The series is also available (until merged) at
git@gitlab.com:dhxx/linux.git b4/op6-tri-state
Changes in v7:
- Separated GPIO number fix from the original commit
"arm64: dts: qcom: sdm845-oneplus: Add alert-slider"
- Rebased again next-20251008
- Link to v6: https://lore.kernel.org/r/20250731-op6-tri-state-v6-0-569c25cbc8c2@ixit.cz
Changes in v6:
- Rebased again next-20250731, otherwise just a resent.
- Link to v5: https://lore.kernel.org/r/20250419-op6-tri-state-v5-0-443127078517@ixit.cz
Changes in v5:
- Dropped merged
"Input: gpio-keys - add support for linux,input-value DTS property"
- Link to v4: https://lore.kernel.org/all/cover.1677022414.git.soyer@irl.hu/
Changes in v4:
- DTS: use default debounce-interval, order alphabetically
- Link to v3: https://lore.kernel.org/lkml/cover.1676850819.git.soyer@irl.hu/
Changes in v3:
- rename tri-state-key to alert-slider, fix DTS warnings,
Changes in v2:
- rebase to qcom/for-next
add SND_PROFILE_* identifiers to input-event-codes.h
---
Gergo Koteles (3):
Input: add ABS_SND_PROFILE
arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider
arm64: dts: qcom: sdm845-oneplus: Add alert-slider
Documentation/input/event-codes.rst | 6 ++++
.../arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 39 ++++++++++++++++++++--
drivers/hid/hid-debug.c | 1 +
include/uapi/linux/input-event-codes.h | 9 +++++
4 files changed, 53 insertions(+), 2 deletions(-)
---
base-commit: 52ba76324a9d7c39830c850999210a36ef023cde
change-id: 20250419-op6-tri-state-ed1a05a11125
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH v6] HID: lg-g15 - Add support for Logitech G13.
From: Jiri Kosina @ 2025-10-14 9:18 UTC (permalink / raw)
To: Leo L. Schwab
Cc: Hans de Goede, Kate Hsuan, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20250917230550.1160621-1-ewhac@ewhac.org>
On Wed, 17 Sep 2025, Leo L. Schwab wrote:
> The Logitech G13 is a gaming keypad with general-purpose macro keys,
> four LED-backlit macro preset keys, five "menu" keys, backlight toggle
> key, an analog thumbstick, RGB LED backlight, and a monochrome LCD
> display.
>
> Support input event generation for all keys and the thumbstick, and
> expose all LEDs.
>
> Signed-off-by: Leo L. Schwab <ewhac@ewhac.org>
> Reviewed-by: Hans de Goede <hansg@kernel.org>
> Tested-by: Kate Hsuan <hpa@redhat.com>
> ---
> Changes in v6:
> - Alter interaction between `brightness` and `brightness_hw_changed`
> for the backlight as advised by Hans de Goede <hansg@kernel.org>.
> - On probe, query device for current state of HW backlight toggle;
> track in `backlight_disabled` and update sysfs.
> - Ensure non-backlight LED brightnesses report either 0 or 1.
> Changes in v5:
> - None; resend v4 due to bounced email submission.
> Changes in v4:
> - Minor changes recommended by Hans de Goede <hansg@kernel.org>.
> Changes in v3:
> - Re-revise commit message.
> - Conditionally compile the section depending on
> CONFIG_LEDS_BRIGHTNESS_HW_CHANGED correctly this time.
> - Use led-class-multicolor facilities for the RGB backlight.
> - Changes recommended by Kate Hsuan <hpa@redhat.com>:
> - Use guard(mutex) construct.
> - Fix numerous style nits.
> Changes in v2:
> - Add `#ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED` bracket around new
> code segment dependent on that feature (fixes test robot build
> error).
> - Use `guard(mutex)` construct in new code (existing code left
> unmodified).
> - Commit message revised.
Applied to hid.git#for-6.19/logitech, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: Kconfig: Fix build error from CONFIG_HID_HAPTIC
From: Thorsten Leemhuis @ 2025-10-14 8:48 UTC (permalink / raw)
To: Jonathan Denose, Kuan-Wei Chiu
Cc: Jiri Kosina, Benjamin Tissoires, Randy Dunlap, Lucas GISSOT,
linux-input, linux-kernel
In-Reply-To: <CAMCVhVNLr+2ivRo9T4rVt4mkncwbOfXEL9bE=pDGRp=Qjy1c9A@mail.gmail.com>
On 10/13/25 23:23, Jonathan Denose wrote:
> On Mon, Oct 13, 2025 at 4:11 PM Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
>> On Mon, Oct 13, 2025 at 08:54:57PM +0000, Jonathan Denose wrote:
>>> Temporarily change CONFIG_HID_HAPTIC to be bool instead of tristate, until
>>> we implement a permanent solution.
>>>
>>> ---
>>
>> The "---" line here will cause many tools used for applying patches,
>> like git am, to discard the content below it [1].
>>
>> Please don't add this line unless you don't want the following content
>> to appear in the commit message.
>>
>> [1]: https://www.kernel.org/doc/html/v6.17/process/submitting-patches.html#commentary
>>
>> Regards,
>> Kuan-Wei
>
> Yes, that was intentional, the information below the '---' was
> included as additional information and not for the commit message.
But at least some of it should be in there (and likely all of it,
despite what checkpatch says) to make the commit-msg properly work
stand-alone. Especially Link: or Closes: tags to the reports (and I
don't care, but ideally with a preceding Reported-by: tag mentioning the
reporters) should be in there.
Documentation/process/submitting-patches.rst and
Documentation/process/5.Posting.rst explain this in more details.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH 25/32] media: imx8mq-mipi-csi2: Use %pe format specifier
From: Martin Kepplinger-Novakovic @ 2025-10-14 7:07 UTC (permalink / raw)
To: Ricardo Ribalda, Linus Walleij, Dmitry Torokhov,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Krzysztof Hałasa, Tomi Valkeinen, Leon Luo, Kieran Bingham,
Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, AngeloGioacchino Del Regno, Rui Miguel Silva,
Laurent Pinchart, Purism Kernel Team, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dafna Hirschfeld,
Heiko Stuebner, Sylwester Nawrocki, Krzysztof Kozlowski,
Alim Akhtar, Yemike Abhilash Chandra, Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, imx, linux-renesas-soc, linux-rockchip,
linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-25-2c5efbd82952@chromium.org>
Am Montag, dem 13.10.2025 um 14:15 +0000 schrieb Ricardo Ribalda:
> The %pe format specifier is designed to print error pointers. It
> prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR().
>
> This patch fixes this cocci report:
> ./platform/nxp/imx8mq-mipi-csi2.c:422:23-30: WARNING: Consider using
> %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/platform/nxp/imx8mq-mipi-csi2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx8mq-mipi-csi2.c
> b/drivers/media/platform/nxp/imx8mq-mipi-csi2.c
> index
> 3a4645f59a44028fdca82a4d8393e1a0a6ba88f0..d333ff43539f061b8b9cf88af2c
> da8c44b3ec2a9 100644
> --- a/drivers/media/platform/nxp/imx8mq-mipi-csi2.c
> +++ b/drivers/media/platform/nxp/imx8mq-mipi-csi2.c
> @@ -418,8 +418,8 @@ static int imx8mq_mipi_csi_calc_hs_settle(struct
> csi_state *state,
>
> src_pad = media_entity_remote_source_pad_unique(&sd_state-
> >sd->entity);
> if (IS_ERR(src_pad)) {
> - dev_err(state->dev, "can't get source pad of %s
> (%ld)\n",
> - sd_state->sd->name, PTR_ERR(src_pad));
> + dev_err(state->dev, "can't get source pad of %s
> (%pe)\n",
> + sd_state->sd->name, src_pad);
> return PTR_ERR(src_pad);
> }
>
Reviewed-by: Martin Kepplinger-Novakovic <martink@posteo.de>
thanks you,
martin
^ permalink raw reply
* Re: [PATCH 05/32] media: ar0521: Use %pe format specifier
From: Krzysztof Hałasa @ 2025-10-14 4:24 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Linus Walleij, Dmitry Torokhov, Mauro Carvalho Chehab,
Hans Verkuil, Sakari Ailus, Tomi Valkeinen, Leon Luo,
Kieran Bingham, Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, AngeloGioacchino Del Regno, Rui Miguel Silva,
Laurent Pinchart, Martin Kepplinger, Purism Kernel Team,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dafna Hirschfeld, Heiko Stuebner, Sylwester Nawrocki,
Krzysztof Kozlowski, Alim Akhtar, Yemike Abhilash Chandra,
Greg Kroah-Hartman, linux-input, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek, imx, linux-renesas-soc,
linux-rockchip, linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-5-2c5efbd82952@chromium.org>
Ricardo Ribalda <ribalda@chromium.org> writes:
> The %pe format specifier is designed to print error pointers. It prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR()
>
> This patch fixes this cocci report:
> ./i2c/ar0521.c:1113:31-38: WARNING: Consider using %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Thanks,
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
> --- a/drivers/media/i2c/ar0521.c
> +++ b/drivers/media/i2c/ar0521.c
> @@ -1109,8 +1109,8 @@ static int ar0521_probe(struct i2c_client *client)
> ar0521_supply_names[cnt]);
>
> if (IS_ERR(supply)) {
> - dev_info(dev, "no %s regulator found: %li\n",
> - ar0521_supply_names[cnt], PTR_ERR(supply));
> + dev_info(dev, "no %s regulator found: %pe\n",
> + ar0521_supply_names[cnt], supply);
> return PTR_ERR(supply);
> }
> sensor->supplies[cnt] = supply;
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* 答复: [External Mail][PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: 卢国宏 @ 2025-10-14 1:24 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires
Cc: kenalba@google.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, 李鹏,
宋密密, 卢国宏
In-Reply-To: <6ec0ba2fd4ba42bf91fa8c5dbfb5e1c0@xiaomi.com>
Hi Jiri Kosina and Benjamin Tissoires! Is there any new progress on getting this patch into the kernel? I look forward to hearing from you. Thank you very much!
________________________________________
发件人: 卢国宏
发送时间: 2025年10月10日 18:43
收件人: Dmitry Torokhov; Jiri Kosina; Benjamin Tissoires
抄送: kenalba@google.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; 李鹏; 宋密密; 卢国宏
主题: 答复: [External Mail][PATCH] HID: hid-input: only ignore 0 battery events for digitizers
Thanks, Dmitry.
Hi Jiri Kosina, Benjamin Tissoires, please let me know once you've merged this patch into the kernel. Thanks!
________________________________________
发件人: Dmitry Torokhov <dmitry.torokhov@gmail.com>
发送时间: 2025年10月10日 14:12
收件人: Jiri Kosina; Benjamin Tissoires
抄送: 卢国宏; kenalba@google.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
主题: [External Mail][PATCH] HID: hid-input: only ignore 0 battery events for digitizers
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈
Commit 581c4484769e ("HID: input: map digitizer battery usage") added
handling of battery events for digitizers (typically for batteries
presented in styli). Digitizers typically report correct battery levels
only when stylus is actively touching the surface, and in other cases
they may report battery level of 0. To avoid confusing consumers of the
battery information the code was added to filer out reports with 0
battery levels.
However there exist other kinds of devices that may legitimately report
0 battery levels. Fix this by filtering out 0-level reports only for
digitizer usages, and continue reporting them for other kinds of devices
(Smart Batteries, etc).
Reported-by: 卢国宏 <luguohong@xiaomi.com>
Tested-by: 卢国宏 <luguohong@xiaomi.com>
Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-input.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ff1784b5c2a4..ba3f6655af9e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
dev->battery = NULL;
}
-static void hidinput_update_battery(struct hid_device *dev, int value)
+static void hidinput_update_battery(struct hid_device *dev,
+ unsigned int usage, int value)
{
int capacity;
if (!dev->battery)
return;
- if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+ if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+ return;
+
+ if (value < dev->battery_min || value > dev->battery_max)
return;
capacity = hidinput_scale_battery_capacity(dev, value);
@@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
if (!handled)
- hidinput_update_battery(hid, value);
+ hidinput_update_battery(hid, usage->hid, value);
return;
}
--
2.51.0.740.g6adb054d12-goog
--
Dmitry
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
^ permalink raw reply related
* Re: [PATCH] HID: Kconfig: Fix build error from CONFIG_HID_HAPTIC
From: Randy Dunlap @ 2025-10-14 1:24 UTC (permalink / raw)
To: Kuan-Wei Chiu, Jonathan Denose
Cc: Jiri Kosina, Benjamin Tissoires, Thorsten Leemhuis, Lucas GISSOT,
linux-input, linux-kernel
In-Reply-To: <aO1vQYCKU7fA0Fxm@visitorckw-System-Product-Name>
On 10/13/25 2:29 PM, Kuan-Wei Chiu wrote:
> On Mon, Oct 13, 2025 at 04:23:36PM -0500, Jonathan Denose wrote:
>> On Mon, Oct 13, 2025 at 4:11 PM Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
>>>
>>> On Mon, Oct 13, 2025 at 08:54:57PM +0000, Jonathan Denose wrote:
>>>> Temporarily change CONFIG_HID_HAPTIC to be bool instead of tristate, until
>>>> we implement a permanent solution.
>>>>
>>>> ---
>>>
>>> The "---" line here will cause many tools used for applying patches,
>>> like git am, to discard the content below it [1].
>>>
>>> Please don't add this line unless you don't want the following content
>>> to appear in the commit message.
>>>
>>> [1]: https://www.kernel.org/doc/html/v6.17/process/submitting-patches.html#commentary
>>>
>>> Regards,
>>> Kuan-Wei
>>
>> Yes, that was intentional, the information below the '---' was
>> included as additional information and not for the commit message. The
>> error messages were too long, as was the link to the longer
>> discussion, and this caused errors in checkpatch.pl.
>>
checkpatch is just a dumb script. Don't let it determine what goes
into a patch description. It can (easily) be wrong.
> Then at least your Signed-off-by tag needs to be above the --- line?
Right.
--
~Randy
^ permalink raw reply
* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
From: Denis Benato @ 2025-10-13 22:50 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
In-Reply-To: <CAGwozwHogocd8FHn31tZY15-N_Kdaoy8cYqtdxte=H3Qioj_ug@mail.gmail.com>
On 10/14/25 00:18, Antheas Kapenekakis wrote:
> On Tue, 14 Oct 2025 at 00:06, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/13/25 23:57, Antheas Kapenekakis wrote:
>>> On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>> Some ROG laptops expose multiple interfaces for controlling the
>>>>> keyboard/RGB brightness. This creates a name conflict under
>>>>> asus::kbd_brightness, where the second device ends up being
>>>>> named asus::kbd_brightness_1 and they are both broken.
>>>> Can you please reference a bug report and/or an analysis of why they ends
>>>> up being broken?
>>> You can reference the V1 description [1]
>>>
>>> [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>> oh okay thanks. I would suggest to keep relevant parts in successive revisions,
>> and most importantly repeat (a shorter description of) relevant parts on the proper
>> commit since commit messages will (hopefully) become part of the kernel,
>> because just reading messages of the current revision doesn't give the full picture
>> of the what and why,
> It's true I cut out the introduction, perhaps I shouldn't have, but it
> will get thrown away anyway. I think the commit body is detailed
> enough though.
I am aware the cover letter won't be part of the kernel, it's why I asked for the
relevant context to be repeated in the appropriate commit message.
I don't think commit messages are detailed enough: a few more explanation
lines would surely help a reader as messages are more centered on the "what" and
not the "why".
Note: this comment of mine is not limited to this particular commit:
look at how long the v1 cover letter is and how long commit messages are
once combined. A lot that has been left out should really be included
(personal opinion of mine, looking at this for the first time: it would have helped).
Thanks,
Denis
> I am looping you in late, but since you are taking over
> Luke's series and you ended up moving the quirks this series removes
> and earlier series did not, you will have some merge conflicts.
>
> By the way, remember to sign off that series yourself as well, since
> you are changing the commits.
>
> Antheas
>
>
>> Regards,
>> Denis
>>>>> Therefore, register a listener to the asus-wmi brightness device
>>>>> instead of creating a new one.
>>>>>
>>>>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
>>>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>>>> ---
>>>>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
>>>>> 1 file changed, 10 insertions(+), 54 deletions(-)
>>>>>
>>>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>>>> index a62559e3e064..0af19c8ef035 100644
>>>>> --- a/drivers/hid/hid-asus.c
>>>>> +++ b/drivers/hid/hid-asus.c
>>>>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>>>>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
>>>>>
>>>>> struct asus_kbd_leds {
>>>>> - struct led_classdev cdev;
>>>>> + struct asus_hid_listener listener;
>>>> It is my understanding from "register a listener .... instead of creating a new one"
>>>> that you are attempting to use the same listener among many devices... so why isn't
>>>> this a pointer? And more importantly: why do we have bool available, bool registered
>>>> instead of either one or the other being replaced by this field being possibly NULL?
>>> A listener is the handle that is passed to asus-wmi so that it can
>>> communicate with hid-asus. Since the flow of communication flows from
>>> asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
>>>
>>> The boolean kbd_led_avail is used to signify whether the BIOS supports
>>> RGB commands. If not, we still want the common handler to be there to
>>> link multiple hid-asus devices together. At the same time, we need to
>>> skip calling the bios commands for brightness, and hold a value for
>>> the previous brightness outside the bios.
>>>
>>> The kbd_led_registered fixes the race condition that happens between
>>> hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
>>> is only setup once, either once asus-wmi loads (if it supports RGB) or
>>> when the first hid device loads.
>>>
>>> Best,
>>> Antheas
>>>
>>>>> struct hid_device *hdev;
>>>>> struct work_struct work;
>>>>> unsigned int brightness;
>>>>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
>>>>> spin_unlock_irqrestore(&led->lock, flags);
>>>>> }
>>>>>
>>>>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>>>> - enum led_brightness brightness)
>>>>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
>>>>> + int brightness)
>>>>> {
>>>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>>>> - cdev);
>>>>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
>>>>> + listener);
>>>>> unsigned long flags;
>>>>>
>>>>> spin_lock_irqsave(&led->lock, flags);
>>>>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>>>> asus_schedule_work(led);
>>>>> }
>>>>>
>>>>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
>>>>> -{
>>>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>>>> - cdev);
>>>>> - enum led_brightness brightness;
>>>>> - unsigned long flags;
>>>>> -
>>>>> - spin_lock_irqsave(&led->lock, flags);
>>>>> - brightness = led->brightness;
>>>>> - spin_unlock_irqrestore(&led->lock, flags);
>>>>> -
>>>>> - return brightness;
>>>>> -}
>>>>> -
>>>>> static void asus_kbd_backlight_work(struct work_struct *work)
>>>>> {
>>>>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
>>>>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
>>>>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>>>> }
>>>>>
>>>>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
>>>>> - * precedence. We only activate HID-based backlight control when the
>>>>> - * WMI control is not available.
>>>>> - */
>>>>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
>>>>> -{
>>>>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>>>>> - u32 value;
>>>>> - int ret;
>>>>> -
>>>>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
>>>>> - return false;
>>>>> -
>>>>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
>>>>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
>>>>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
>>>>> - return false;
>>>>> - }
>>>>> -
>>>>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
>>>>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
>>>>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
>>>>> - if (ret)
>>>>> - return false;
>>>>> -
>>>>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
>>>>> -}
>>>>> -
>>>>> /*
>>>>> * We don't care about any other part of the string except the version section.
>>>>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
>>>>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>>>>> drvdata->kbd_backlight->removed = false;
>>>>> drvdata->kbd_backlight->brightness = 0;
>>>>> drvdata->kbd_backlight->hdev = hdev;
>>>>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
>>>>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
>>>>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
>>>>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
>>>>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
>>>>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
>>>>> spin_lock_init(&drvdata->kbd_backlight->lock);
>>>>>
>>>>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
>>>>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
>>>>> if (ret < 0) {
>>>>> /* No need to have this still around */
>>>>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
>>>>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
>>>>>
>>>>> if (drvdata->kbd_backlight) {
>>>>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
>>>>> - drvdata->kbd_backlight->cdev.brightness };
>>>>> + drvdata->kbd_backlight->brightness };
>>>>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
>>>>> if (ret < 0) {
>>>>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>>>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>>>> }
>>>>>
>>>>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>>>>> - !asus_kbd_wmi_led_control_present(hdev) &&
>>>>> asus_kbd_register_leds(hdev))
>>>>> hid_warn(hdev, "Failed to initialize backlight.\n");
>>>>>
>>>>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
>>>>> unsigned long flags;
>>>>>
>>>>> if (drvdata->kbd_backlight) {
>>>>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
>>>>> +
>>>>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
>>>>> drvdata->kbd_backlight->removed = true;
>>>>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
^ permalink raw reply
* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
From: Antheas Kapenekakis @ 2025-10-13 22:18 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
In-Reply-To: <bb149ff1-5fbc-41ff-a4e8-51f6b8631b5e@gmail.com>
On Tue, 14 Oct 2025 at 00:06, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 23:57, Antheas Kapenekakis wrote:
> > On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
> >>
> >> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>> Some ROG laptops expose multiple interfaces for controlling the
> >>> keyboard/RGB brightness. This creates a name conflict under
> >>> asus::kbd_brightness, where the second device ends up being
> >>> named asus::kbd_brightness_1 and they are both broken.
> >> Can you please reference a bug report and/or an analysis of why they ends
> >> up being broken?
> > You can reference the V1 description [1]
> >
> > [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> oh okay thanks. I would suggest to keep relevant parts in successive revisions,
> and most importantly repeat (a shorter description of) relevant parts on the proper
> commit since commit messages will (hopefully) become part of the kernel,
> because just reading messages of the current revision doesn't give the full picture
> of the what and why,
It's true I cut out the introduction, perhaps I shouldn't have, but it
will get thrown away anyway. I think the commit body is detailed
enough though.
I am looping you in late, but since you are taking over
Luke's series and you ended up moving the quirks this series removes
and earlier series did not, you will have some merge conflicts.
By the way, remember to sign off that series yourself as well, since
you are changing the commits.
Antheas
> Regards,
> Denis
> >>> Therefore, register a listener to the asus-wmi brightness device
> >>> instead of creating a new one.
> >>>
> >>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> >>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> >>> ---
> >>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
> >>> 1 file changed, 10 insertions(+), 54 deletions(-)
> >>>
> >>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> >>> index a62559e3e064..0af19c8ef035 100644
> >>> --- a/drivers/hid/hid-asus.c
> >>> +++ b/drivers/hid/hid-asus.c
> >>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> >>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
> >>>
> >>> struct asus_kbd_leds {
> >>> - struct led_classdev cdev;
> >>> + struct asus_hid_listener listener;
> >> It is my understanding from "register a listener .... instead of creating a new one"
> >> that you are attempting to use the same listener among many devices... so why isn't
> >> this a pointer? And more importantly: why do we have bool available, bool registered
> >> instead of either one or the other being replaced by this field being possibly NULL?
> > A listener is the handle that is passed to asus-wmi so that it can
> > communicate with hid-asus. Since the flow of communication flows from
> > asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
> >
> > The boolean kbd_led_avail is used to signify whether the BIOS supports
> > RGB commands. If not, we still want the common handler to be there to
> > link multiple hid-asus devices together. At the same time, we need to
> > skip calling the bios commands for brightness, and hold a value for
> > the previous brightness outside the bios.
> >
> > The kbd_led_registered fixes the race condition that happens between
> > hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
> > is only setup once, either once asus-wmi loads (if it supports RGB) or
> > when the first hid device loads.
> >
> > Best,
> > Antheas
> >
> >>> struct hid_device *hdev;
> >>> struct work_struct work;
> >>> unsigned int brightness;
> >>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
> >>> spin_unlock_irqrestore(&led->lock, flags);
> >>> }
> >>>
> >>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> >>> - enum led_brightness brightness)
> >>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
> >>> + int brightness)
> >>> {
> >>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> >>> - cdev);
> >>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
> >>> + listener);
> >>> unsigned long flags;
> >>>
> >>> spin_lock_irqsave(&led->lock, flags);
> >>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> >>> asus_schedule_work(led);
> >>> }
> >>>
> >>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
> >>> -{
> >>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> >>> - cdev);
> >>> - enum led_brightness brightness;
> >>> - unsigned long flags;
> >>> -
> >>> - spin_lock_irqsave(&led->lock, flags);
> >>> - brightness = led->brightness;
> >>> - spin_unlock_irqrestore(&led->lock, flags);
> >>> -
> >>> - return brightness;
> >>> -}
> >>> -
> >>> static void asus_kbd_backlight_work(struct work_struct *work)
> >>> {
> >>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
> >>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
> >>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> >>> }
> >>>
> >>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> >>> - * precedence. We only activate HID-based backlight control when the
> >>> - * WMI control is not available.
> >>> - */
> >>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> >>> -{
> >>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> >>> - u32 value;
> >>> - int ret;
> >>> -
> >>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
> >>> - return false;
> >>> -
> >>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
> >>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
> >>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
> >>> - return false;
> >>> - }
> >>> -
> >>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
> >>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
> >>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
> >>> - if (ret)
> >>> - return false;
> >>> -
> >>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
> >>> -}
> >>> -
> >>> /*
> >>> * We don't care about any other part of the string except the version section.
> >>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
> >>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> >>> drvdata->kbd_backlight->removed = false;
> >>> drvdata->kbd_backlight->brightness = 0;
> >>> drvdata->kbd_backlight->hdev = hdev;
> >>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> >>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
> >>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
> >>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
> >>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
> >>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
> >>> spin_lock_init(&drvdata->kbd_backlight->lock);
> >>>
> >>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
> >>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
> >>> if (ret < 0) {
> >>> /* No need to have this still around */
> >>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> >>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
> >>>
> >>> if (drvdata->kbd_backlight) {
> >>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
> >>> - drvdata->kbd_backlight->cdev.brightness };
> >>> + drvdata->kbd_backlight->brightness };
> >>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> >>> if (ret < 0) {
> >>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> >>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> >>> }
> >>>
> >>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> >>> - !asus_kbd_wmi_led_control_present(hdev) &&
> >>> asus_kbd_register_leds(hdev))
> >>> hid_warn(hdev, "Failed to initialize backlight.\n");
> >>>
> >>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
> >>> unsigned long flags;
> >>>
> >>> if (drvdata->kbd_backlight) {
> >>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
> >>> +
> >>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
> >>> drvdata->kbd_backlight->removed = true;
> >>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
>
^ permalink raw reply
* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
From: Denis Benato @ 2025-10-13 22:06 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
In-Reply-To: <CAGwozwHP6ukxBRpOFU+XQL5gyNKu5f-HUJio-=F6rAGUmcm2tw@mail.gmail.com>
On 10/13/25 23:57, Antheas Kapenekakis wrote:
> On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>> Some ROG laptops expose multiple interfaces for controlling the
>>> keyboard/RGB brightness. This creates a name conflict under
>>> asus::kbd_brightness, where the second device ends up being
>>> named asus::kbd_brightness_1 and they are both broken.
>> Can you please reference a bug report and/or an analysis of why they ends
>> up being broken?
> You can reference the V1 description [1]
>
> [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
oh okay thanks. I would suggest to keep relevant parts in successive revisions,
and most importantly repeat (a shorter description of) relevant parts on the proper
commit since commit messages will (hopefully) become part of the kernel,
because just reading messages of the current revision doesn't give the full picture
of the what and why,
Regards,
Denis
>>> Therefore, register a listener to the asus-wmi brightness device
>>> instead of creating a new one.
>>>
>>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>> ---
>>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
>>> 1 file changed, 10 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>> index a62559e3e064..0af19c8ef035 100644
>>> --- a/drivers/hid/hid-asus.c
>>> +++ b/drivers/hid/hid-asus.c
>>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
>>>
>>> struct asus_kbd_leds {
>>> - struct led_classdev cdev;
>>> + struct asus_hid_listener listener;
>> It is my understanding from "register a listener .... instead of creating a new one"
>> that you are attempting to use the same listener among many devices... so why isn't
>> this a pointer? And more importantly: why do we have bool available, bool registered
>> instead of either one or the other being replaced by this field being possibly NULL?
> A listener is the handle that is passed to asus-wmi so that it can
> communicate with hid-asus. Since the flow of communication flows from
> asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
>
> The boolean kbd_led_avail is used to signify whether the BIOS supports
> RGB commands. If not, we still want the common handler to be there to
> link multiple hid-asus devices together. At the same time, we need to
> skip calling the bios commands for brightness, and hold a value for
> the previous brightness outside the bios.
>
> The kbd_led_registered fixes the race condition that happens between
> hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
> is only setup once, either once asus-wmi loads (if it supports RGB) or
> when the first hid device loads.
>
> Best,
> Antheas
>
>>> struct hid_device *hdev;
>>> struct work_struct work;
>>> unsigned int brightness;
>>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
>>> spin_unlock_irqrestore(&led->lock, flags);
>>> }
>>>
>>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>> - enum led_brightness brightness)
>>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
>>> + int brightness)
>>> {
>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>> - cdev);
>>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
>>> + listener);
>>> unsigned long flags;
>>>
>>> spin_lock_irqsave(&led->lock, flags);
>>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>> asus_schedule_work(led);
>>> }
>>>
>>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
>>> -{
>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>> - cdev);
>>> - enum led_brightness brightness;
>>> - unsigned long flags;
>>> -
>>> - spin_lock_irqsave(&led->lock, flags);
>>> - brightness = led->brightness;
>>> - spin_unlock_irqrestore(&led->lock, flags);
>>> -
>>> - return brightness;
>>> -}
>>> -
>>> static void asus_kbd_backlight_work(struct work_struct *work)
>>> {
>>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
>>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
>>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>> }
>>>
>>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
>>> - * precedence. We only activate HID-based backlight control when the
>>> - * WMI control is not available.
>>> - */
>>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
>>> -{
>>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>>> - u32 value;
>>> - int ret;
>>> -
>>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
>>> - return false;
>>> -
>>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
>>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
>>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
>>> - return false;
>>> - }
>>> -
>>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
>>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
>>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
>>> - if (ret)
>>> - return false;
>>> -
>>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
>>> -}
>>> -
>>> /*
>>> * We don't care about any other part of the string except the version section.
>>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
>>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>>> drvdata->kbd_backlight->removed = false;
>>> drvdata->kbd_backlight->brightness = 0;
>>> drvdata->kbd_backlight->hdev = hdev;
>>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
>>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
>>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
>>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
>>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
>>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
>>> spin_lock_init(&drvdata->kbd_backlight->lock);
>>>
>>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
>>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
>>> if (ret < 0) {
>>> /* No need to have this still around */
>>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
>>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
>>>
>>> if (drvdata->kbd_backlight) {
>>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
>>> - drvdata->kbd_backlight->cdev.brightness };
>>> + drvdata->kbd_backlight->brightness };
>>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
>>> if (ret < 0) {
>>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>> }
>>>
>>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>>> - !asus_kbd_wmi_led_control_present(hdev) &&
>>> asus_kbd_register_leds(hdev))
>>> hid_warn(hdev, "Failed to initialize backlight.\n");
>>>
>>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
>>> unsigned long flags;
>>>
>>> if (drvdata->kbd_backlight) {
>>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
>>> +
>>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
>>> drvdata->kbd_backlight->removed = true;
>>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
^ permalink raw reply
* [syzbot] [input?] BUG: unable to handle kernel paging request in uinput_destroy_device
From: syzbot @ 2025-10-13 21:58 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2b763d465239 Add linux-next specific files for 20251010
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12f06542580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d4057daadbd2196b
dashboard link: https://syzkaller.appspot.com/bug?extid=51f9b5e3c5a307417c1b
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13cbf458580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5ca8031cf31f/disk-2b763d46.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/00ba418b156f/vmlinux-2b763d46.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a18ef5d6f602/bzImage-2b763d46.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+51f9b5e3c5a307417c1b@syzkaller.appspotmail.com
BUG: unable to handle page fault for address: fffffffffffffff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD df3d067
P4D df3d067
PUD df3f067
PMD 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6106 Comm: syz.0.45 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:swake_up_locked kernel/sched/swait.c:30 [inline]
RIP: 0010:complete_with_flags kernel/sched/completion.c:29 [inline]
RIP: 0010:complete+0x99/0x1b0 kernel/sched/completion.c:52
Code: 89 e7 e8 8a 4e 8b 00 4d 8b 3c 24 4d 39 e7 0f 84 d4 00 00 00 49 8d 7f f8 48 89 f8 48 c1 e8 03 80 3c 28 00 74 05 e8 67 4e 8b 00 <49> 8b 7f f8 be 03 00 00 00 31 d2 e8 17 5c f6 ff 4c 89 ff e8 9f eb
RSP: 0018:ffffc90003a3fcd8 EFLAGS: 00010046
RAX: 1fffffffffffffff RBX: ffffc90003bafa58 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: 0000000000000004 RDI: fffffffffffffff8
RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000747f78 R12: ffffc90003bafa98
R13: 0000000000000001 R14: 0000000000000a06 R15: 0000000000000000
FS: 0000555564ca1500(0000) GS:ffff888125e2b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffff8 CR3: 000000007959e000 CR4: 00000000003526f0
Call Trace:
<TASK>
uinput_flush_requests drivers/input/misc/uinput.c:213 [inline]
uinput_destroy_device+0x11a/0x8c0 drivers/input/misc/uinput.c:298
uinput_release+0x3b/0x50 drivers/input/misc/uinput.c:758
__fput+0x44c/0xa70 fs/file_table.c:468
task_work_run+0x1d4/0x260 kernel/task_work.c:227
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe54718eec9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe72996ff8 EFLAGS: 00000246
ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 000000000001bc2c RCX: 00007fe54718eec9
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007fe5473e7da0 R08: 0000000000000001 R09: 00000006729972ef
R10: 0000001b2f220000 R11: 0000000000000246 R12: 00007fe5473e5fac
R13: 00007fe5473e5fa0 R14: ffffffffffffffff R15: 00007ffe72997110
</TASK>
Modules linked in:
CR2: fffffffffffffff8
---[ end trace 0000000000000000 ]---
RIP: 0010:swake_up_locked kernel/sched/swait.c:30 [inline]
RIP: 0010:complete_with_flags kernel/sched/completion.c:29 [inline]
RIP: 0010:complete+0x99/0x1b0 kernel/sched/completion.c:52
Code: 89 e7 e8 8a 4e 8b 00 4d 8b 3c 24 4d 39 e7 0f 84 d4 00 00 00 49 8d 7f f8 48 89 f8 48 c1 e8 03 80 3c 28 00 74 05 e8 67 4e 8b 00 <49> 8b 7f f8 be 03 00 00 00 31 d2 e8 17 5c f6 ff 4c 89 ff e8 9f eb
RSP: 0018:ffffc90003a3fcd8 EFLAGS: 00010046
RAX: 1fffffffffffffff RBX: ffffc90003bafa58 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: 0000000000000004 RDI: fffffffffffffff8
RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000747f78 R12: ffffc90003bafa98
R13: 0000000000000001 R14: 0000000000000a06 R15: 0000000000000000
FS: 0000555564ca1500(0000) GS:ffff888125e2b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffff8 CR3: 000000007959e000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
0: 89 e7 mov %esp,%edi
2: e8 8a 4e 8b 00 call 0x8b4e91
7: 4d 8b 3c 24 mov (%r12),%r15
b: 4d 39 e7 cmp %r12,%r15
e: 0f 84 d4 00 00 00 je 0xe8
14: 49 8d 7f f8 lea -0x8(%r15),%rdi
18: 48 89 f8 mov %rdi,%rax
1b: 48 c1 e8 03 shr $0x3,%rax
1f: 80 3c 28 00 cmpb $0x0,(%rax,%rbp,1)
23: 74 05 je 0x2a
25: e8 67 4e 8b 00 call 0x8b4e91
* 2a: 49 8b 7f f8 mov -0x8(%r15),%rdi <-- trapping instruction
2e: be 03 00 00 00 mov $0x3,%esi
33: 31 d2 xor %edx,%edx
35: e8 17 5c f6 ff call 0xfff65c51
3a: 4c 89 ff mov %r15,%rdi
3d: e8 .byte 0xe8
3e: 9f lahf
3f: eb .byte 0xeb
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
From: Antheas Kapenekakis @ 2025-10-13 21:57 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
In-Reply-To: <e1e6ee09-ea29-4328-9eae-f2a4a23b3edc@gmail.com>
On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > Some ROG laptops expose multiple interfaces for controlling the
> > keyboard/RGB brightness. This creates a name conflict under
> > asus::kbd_brightness, where the second device ends up being
> > named asus::kbd_brightness_1 and they are both broken.
> Can you please reference a bug report and/or an analysis of why they ends
> up being broken?
You can reference the V1 description [1]
[1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >
> > Therefore, register a listener to the asus-wmi brightness device
> > instead of creating a new one.
> >
> > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
> > 1 file changed, 10 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > index a62559e3e064..0af19c8ef035 100644
> > --- a/drivers/hid/hid-asus.c
> > +++ b/drivers/hid/hid-asus.c
> > @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
> >
> > struct asus_kbd_leds {
> > - struct led_classdev cdev;
> > + struct asus_hid_listener listener;
> It is my understanding from "register a listener .... instead of creating a new one"
> that you are attempting to use the same listener among many devices... so why isn't
> this a pointer? And more importantly: why do we have bool available, bool registered
> instead of either one or the other being replaced by this field being possibly NULL?
A listener is the handle that is passed to asus-wmi so that it can
communicate with hid-asus. Since the flow of communication flows from
asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
The boolean kbd_led_avail is used to signify whether the BIOS supports
RGB commands. If not, we still want the common handler to be there to
link multiple hid-asus devices together. At the same time, we need to
skip calling the bios commands for brightness, and hold a value for
the previous brightness outside the bios.
The kbd_led_registered fixes the race condition that happens between
hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
is only setup once, either once asus-wmi loads (if it supports RGB) or
when the first hid device loads.
Best,
Antheas
> > struct hid_device *hdev;
> > struct work_struct work;
> > unsigned int brightness;
> > @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
> > spin_unlock_irqrestore(&led->lock, flags);
> > }
> >
> > -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> > - enum led_brightness brightness)
> > +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
> > + int brightness)
> > {
> > - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> > - cdev);
> > + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
> > + listener);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&led->lock, flags);
> > @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> > asus_schedule_work(led);
> > }
> >
> > -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
> > -{
> > - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> > - cdev);
> > - enum led_brightness brightness;
> > - unsigned long flags;
> > -
> > - spin_lock_irqsave(&led->lock, flags);
> > - brightness = led->brightness;
> > - spin_unlock_irqrestore(&led->lock, flags);
> > -
> > - return brightness;
> > -}
> > -
> > static void asus_kbd_backlight_work(struct work_struct *work)
> > {
> > struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
> > @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
> > hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> > }
> >
> > -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> > - * precedence. We only activate HID-based backlight control when the
> > - * WMI control is not available.
> > - */
> > -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> > -{
> > - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> > - u32 value;
> > - int ret;
> > -
> > - if (!IS_ENABLED(CONFIG_ASUS_WMI))
> > - return false;
> > -
> > - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
> > - dmi_check_system(asus_use_hid_led_dmi_ids)) {
> > - hid_info(hdev, "using HID for asus::kbd_backlight\n");
> > - return false;
> > - }
> > -
> > - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
> > - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
> > - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
> > - if (ret)
> > - return false;
> > -
> > - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
> > -}
> > -
> > /*
> > * We don't care about any other part of the string except the version section.
> > * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
> > @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> > drvdata->kbd_backlight->removed = false;
> > drvdata->kbd_backlight->brightness = 0;
> > drvdata->kbd_backlight->hdev = hdev;
> > - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> > - drvdata->kbd_backlight->cdev.max_brightness = 3;
> > - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
> > - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
> > + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
> > INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
> > spin_lock_init(&drvdata->kbd_backlight->lock);
> >
> > - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
> > + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
> > if (ret < 0) {
> > /* No need to have this still around */
> > devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> > @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
> >
> > if (drvdata->kbd_backlight) {
> > const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
> > - drvdata->kbd_backlight->cdev.brightness };
> > + drvdata->kbd_backlight->brightness };
> > ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> > if (ret < 0) {
> > hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> > @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > }
> >
> > if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> > - !asus_kbd_wmi_led_control_present(hdev) &&
> > asus_kbd_register_leds(hdev))
> > hid_warn(hdev, "Failed to initialize backlight.\n");
> >
> > @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
> > unsigned long flags;
> >
> > if (drvdata->kbd_backlight) {
> > + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
> > +
> > spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
> > drvdata->kbd_backlight->removed = true;
> > spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox