* Re: [PATCH v5 8/9] HID: steelseries: Add async status interface support
From: sashiko-bot @ 2026-06-30 17:39 UTC (permalink / raw)
To: Sriman Achanta; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <c993054229da167e96332fc142d372091e8c7406.1782840133.git.srimanachanta@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unsynchronized access to the sibling interface's HID device and driver data in `steelseries_get_sibling_sd()` leads to Use-After-Free vulnerabilities during concurrent unbinding.
- [High] Unsafe retrieval of `intfdata` from a sibling USB interface without verifying the bound USB driver leads to type confusion.
--
commit 184e416637c40dbd71e035542907c5105f99d55d
Author: Sriman Achanta <srimanachanta@gmail.com>
HID: steelseries: Add async status interface support
This patch adds support for an async status interface on some Steelseries
headsets. The driver binds both sync and async interfaces, using the async
interface to push status events and delay its probe until the sync interface
is fully initialized.
> diff --git a/drivers/hid/hid-steelseries-arctis.c b/drivers/hid/hid-steelseries-arctis.c
> --- a/drivers/hid/hid-steelseries-arctis.c
> +++ b/drivers/hid/hid-steelseries-arctis.c
[ ... ]
> +static struct steelseries_device *
> +steelseries_get_sibling_sd(struct hid_device *hdev, int interface_num)
> +{
> + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> + struct usb_device *usb_dev = interface_to_usbdev(intf);
> + struct usb_interface *sibling_intf;
> + struct hid_device *sibling_hdev;
> + struct steelseries_device *sd;
> +
> + sibling_intf = usb_ifnum_to_if(usb_dev, interface_num);
> + if (!sibling_intf)
> + return NULL;
> +
> + sibling_hdev = usb_get_intfdata(sibling_intf);
> + if (!sibling_hdev || sibling_hdev->driver != &steelseries_arctis_driver)
[Severity: High]
Can a malicious USB device trigger an out-of-bounds read here?
If the device advertises the sync interface as a non-HID class (like Mass
Storage) but the async interface as HID, the USB core might bind a different
driver to the sync interface. In that case, usb_get_intfdata() would return
a driver-specific structure (like struct us_data) rather than a
struct hid_device.
Would it be safer to verify the bound USB driver on the sibling interface
before casting the intfdata and dereferencing sibling_hdev->driver?
> + return NULL;
> +
> + sd = hid_get_drvdata(sibling_hdev);
> + if (sd)
> + kref_get(&sd->refcnt);
[Severity: High]
Is there a race condition with concurrent unbinding here?
If the sync interface is concurrently unbound (e.g., via sysfs or physical
disconnection) while the async interface is probing, usb_get_intfdata()
and hid_get_drvdata() are called without holding device_lock() for the
sibling interface's device.
Could this allow the hid_device to be freed before checking
sibling_hdev->driver, or allow the steelseries_device (sd) to be freed
before kref_get() is called?
> +
> + return sd;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782840133.git.srimanachanta@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v5 5/9] HID: steelseries: Report POWER_SUPPLY_STATUS_FULL when full
From: sashiko-bot @ 2026-06-30 17:39 UTC (permalink / raw)
To: Sriman Achanta; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <3d06ba7fcb4873c9d9d69c1fcbcd3d6bc21fadd0.1782840133.git.srimanachanta@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch incorrectly reports POWER_SUPPLY_STATUS_FULL for an unplugged, actively discharging wireless headset solely because its capacity is 100%.
--
commit 7a846a17b1f3241f94405b831860eba9d3123648
Author: Sriman Achanta <srimanachanta@gmail.com>
HID: steelseries: Report POWER_SUPPLY_STATUS_FULL when full
This commit updates the battery status reporting for SteelSeries headsets.
It now returns POWER_SUPPLY_STATUS_FULL when the headset is connected, not
charging, and at 100% capacity instead of returning DISCHARGING.
> diff --git a/drivers/hid/hid-steelseries-arctis.c b/drivers/hid/hid-steelseries-arctis.c
> --- a/drivers/hid/hid-steelseries-arctis.c
> +++ b/drivers/hid/hid-steelseries-arctis.c
> @@ -215,6 +215,8 @@ static int steelseries_battery_get_property(struct power_supply *psy,
> val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
> else if (sd->battery_charging)
> val->intval = POWER_SUPPLY_STATUS_CHARGING;
> + else if (sd->battery_capacity >= 100)
> + val->intval = POWER_SUPPLY_STATUS_FULL;
[Severity: Medium]
Will this incorrectly report POWER_SUPPLY_STATUS_FULL for an unplugged,
actively discharging wireless headset just because its capacity is at 100%?
When the headset is unplugged from external power but still fully charged,
sd->battery_charging is false and sd->battery_capacity is 100. It appears
this logic will now return POWER_SUPPLY_STATUS_FULL instead of
POWER_SUPPLY_STATUS_DISCHARGING, because there is no explicit check to verify
if the device is currently receiving external power.
Is there a way to ensure the headset is actually plugged in before returning
FULL, so that userspace tools don't incorrectly hide the discharge state
until the capacity drops below 100%?
> else
> val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> break;
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782840133.git.srimanachanta@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v5 9/9] HID: steelseries: Add support for Arctis Nova 7 Gen2 family
From: sashiko-bot @ 2026-06-30 17:44 UTC (permalink / raw)
To: Sriman Achanta; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <8d6f139f082f2b985bad0cb3f60f260e60a7f2e9.1782840133.git.srimanachanta@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] The global bounds check `if (size < 4)` incorrectly drops valid, shorter unsolicited status reports.
Pre-existing issues:
- [High] Concurrent sysfs unbind leads to Use-After-Free of sibling `hid_device` and `steelseries_device`.
- [High] Type confusion when retrieving the sibling HID device can lead to an out-of-bounds memory read.
--
commit 70087cd16ba3bb84894fac86ae371e8ee1265c7a
Author: Sriman Achanta <srimanachanta@gmail.com>
HID: steelseries: Add support for Arctis Nova 7 Gen2 family
This patch adds support for the Arctis Nova 7 Gen2 headsets. It introduces a
new parser for unsolicited battery and connection updates on a second HID
interface, and adds eight new USB product IDs to the supported devices list.
> diff --git a/drivers/hid/hid-steelseries-arctis.c b/drivers/hid/hid-steelseries-arctis.c
> index 689435c60ecbd..31d31f3f4b0e9 100644
> --- a/drivers/hid/hid-steelseries-arctis.c
> +++ b/drivers/hid/hid-steelseries-arctis.c
[ ... ]
> @@ -162,6 +169,30 @@ static void steelseries_arctis_9_parse_status(struct steelseries_device *sd,
> }
> }
>
> +static void steelseries_arctis_nova_7_gen2_parse_status(struct steelseries_device *sd,
> + u8 *data, int size)
> +{
> + if (size < 4)
> + return;
[Severity: Medium]
Could this global bounds check prematurely discard valid unsolicited battery
and connection updates?
The new opcodes 0xb7, 0xb9, and 0xbb only require up to data[1] to be valid.
If the headset firmware sends these unsolicited updates as 2-byte short USB
HID packets reflecting their actual content size, this check will drop them.
[ ... ]
> @@ -180,6 +211,14 @@ static const struct steelseries_device_info arctis_9_info = {
> .parse_status = steelseries_arctis_9_parse_status,
> };
>
> +static const struct steelseries_device_info arctis_nova_7_gen2_info = {
> + .sync_interface = 3,
> + .async_interface = 5,
[Severity: High]
This is a pre-existing issue, but the addition of these new devices using the
async/sync interface mechanism heavily exercises it. Is it possible for a
concurrent sysfs unbind to cause a use-after-free?
During the async interface probe, steelseries_get_sibling_sd() calls
usb_get_intfdata(sibling_intf) without holding the device lock for the sibling
interface. If a user concurrently unbinds the sibling interface (e.g., via
sysfs), usbhid destroys the hid_device. This causes the probe path to
locklessly dereference the freed sibling_hdev->driver:
sibling_hdev = usb_get_intfdata(sibling_intf);
if (!sibling_hdev || sibling_hdev->driver != &steelseries_arctis_driver)
return NULL;
sd = hid_get_drvdata(sibling_hdev);
if (sd)
kref_get(&sd->refcnt);
It then calls kref_get(&sd->refcnt) on the associated private data, modifying
freed memory.
[Severity: High]
This isn't a bug introduced by this patch, but adding these devices expands
the exposure to a pre-existing type confusion issue. Could this lead to an
out-of-bounds memory read?
In steelseries_get_sibling_sd(), the driver extracts the private data via
usb_get_intfdata() and assumes it is a struct hid_device *:
sibling_intf = usb_ifnum_to_if(usb_dev, interface_num);
if (!sibling_intf)
return NULL;
sibling_hdev = usb_get_intfdata(sibling_intf);
if (!sibling_hdev || sibling_hdev->driver != &steelseries_arctis_driver)
return NULL;
If a crafted USB device is plugged in where the sibling interface (e.g.,
interface 0 or 3) is a non-HID class like USB Audio, a different driver will
bind and store its own private structure in intfdata.
The driver field sits hundreds of bytes deep into struct hid_device. Reading
it from a smaller structure belonging to another driver will read out-of-bounds
of the allocated SLUB object.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782840133.git.srimanachanta@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH] HID: asus: add new Asus EC hid device for keyboard backlight and FN HotKeys
From: Alexandru Serdeliuc @ 2026-06-30 16:43 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-kernel, linux-input
In-Reply-To: <20251221-add-support-for-the-asus-hid-ec-v1-1-35d7d70fbbfc@yahoo.com>
Hi Jiri, Benjamin,
Enquiring if anyone has had a chance to look over this patch series from
December?
To provide a bit of architectural context, this is a 100% pure HID
client driver.
This laptop (Asus Zenbook A14 UX3407QA) runs on the Qualcomm ARM64
Snapdragon platform.
Because it is an ARM device, it does not use traditional legacy x86
ACPI/WMI code.
Instead, the Fn hotkeys and keyboard backlight controls are routed
completely through standard vendor-specific HID reports (using Report ID
0x5A) over the existing I2C-HID transport layer.
It requires absolutely zero Device Tree modifications or external
platform subsystem hooks to bind or function.
The driver matches strictly on Vendor/Product ID (0x0B05 / 0x0220)
passed directly through the core HID subsystem.
I would highly appreciate any architectural feedback or a quick review!
Best regards,
Alexandru Marc Serdeliuc
On 12/21/25 12:12, Alexandru Marc Serdeliuc via B4 Relay wrote:
> From: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
>
> Add support for Asus Embedded Controlled accessed via HID
>
> Currently working features:
> - Keyboard Backlight
> - FN HotKeys
>
> Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> ---
> Add support for Asus Embedded Controlled accessed via HID
>
> Currently working features:
> - Keyboard Backlight
> - FN HotKeys
> ---
> drivers/hid/Kconfig | 10 ++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-asus-ec.c | 386 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 397 insertions(+)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 920a64b66b25b39e8259105c7c9b975fb77b2725..f0fbc951735eeea39198137294a9429f5b9d34b8 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -202,6 +202,16 @@ config HID_ASUS
> - GL553V series
> - GL753V series
>
> +config HID_ASUS_EC
> + tristate "ASUS EC HID support (Zenbook A14 UX3407QA)"
> + depends on HID && I2C_HID
> + help
> + Say Y here if you have an ASUS Zenbook A14 (UX3407QA) and want
> + support for its EC-controlled keyboard backlight and Fn hotkeys
> +
> + This driver is currently only tested on the ASUS Zenbook A14
> + UX3407QA; behaviour on other models is unknown.
> +
> config HID_AUREAL
> tristate "Aureal"
> help
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 361a7daedeb85454114def8afb5f58caeab58a00..bacccf00482c1b787ce59660e4366f8224aeefee 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_HID_APPLETB_BL) += hid-appletb-bl.o
> obj-$(CONFIG_HID_APPLETB_KBD) += hid-appletb-kbd.o
> obj-$(CONFIG_HID_CREATIVE_SB0540) += hid-creative-sb0540.o
> obj-$(CONFIG_HID_ASUS) += hid-asus.o
> +obj-$(CONFIG_HID_ASUS_EC) += hid-asus-ec.o
> obj-$(CONFIG_HID_AUREAL) += hid-aureal.o
> obj-$(CONFIG_HID_BELKIN) += hid-belkin.o
> obj-$(CONFIG_HID_BETOP_FF) += hid-betopff.o
> diff --git a/drivers/hid/hid-asus-ec.c b/drivers/hid/hid-asus-ec.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..1cf61fb2468d079827bfdb1db49daca905e53874
> --- /dev/null
> +++ b/drivers/hid/hid-asus-ec.c
> @@ -0,0 +1,386 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * ASUS EC HID driver for Zenbook A14 (UX3407QA)
> + *
> + * EC I2C HID driver for keyboard backlight and Fn hotkeys.
> + *
> + * Copyright (c) 2025 Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/hid.h>
> +#include <linux/input.h>
> +#include <linux/leds.h>
> +#include <linux/slab.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/string.h>
> +#include <linux/delay.h>
> +#include <linux/pm.h>
> +
> +#define ASUS_VENDOR_ID 0x0B05
> +#define ASUS_PRODUCT_ID 0x0220
> +
> +#define A14_EC_REPORT_ID 0x5A
> +#define A14_EC_REPORT_SIZE 64
> +#define A14_EC_MAX_BACKLIGHT 3
> +
> +#define A14_EC_EVT_KEY_FN_ESC 0x4E
> +#define A14_EC_EVT_KEY_FN_F4 0xC7
> +#define A14_EC_EVT_KEY_FN_F5 0x10
> +#define A14_EC_EVT_KEY_FN_F6 0x20
> +#define A14_EC_EVT_KEY_FN_F8 0x7E
> +#define A14_EC_EVT_KEY_FN_F9 0x7C
> +#define A14_EC_EVT_KEY_FN_F10 0x85
> +#define A14_EC_EVT_KEY_FN_F11 0x6B
> +#define A14_EC_EVT_KEY_FN_F12 0x86
> +#define A14_EC_EVT_KEY_FN_F 0x9d
> +
> +
> +struct asus_hid_data {
> + struct hid_device *hdev;
> + struct led_classdev kbd_led_cdev;
> + struct input_dev *hotkey_input_dev;
> + enum led_brightness saved_brightness;
> +};
> +
> +static struct asus_hid_data *asus_data;
> +
> +static int asus_send_ec_command(struct hid_device *hdev, u8 *cmd_buf)
> +{
> + int ret;
> + u8 report_id = cmd_buf[0];
> +
> + ret = hid_hw_raw_request(hdev, report_id, cmd_buf, A14_EC_REPORT_SIZE,
> + HID_FEATURE_REPORT,
> + HID_REQ_SET_REPORT);
> +
> + if (ret < 0)
> + dev_err(&hdev->dev, "hid_hw_raw_request failed with status: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int asus_kbd_led_init(struct hid_device *hdev)
> +{
> + u8 ec_init_cmd[A14_EC_REPORT_SIZE] = { A14_EC_REPORT_ID, 0xD0, 0x8F, 0x01 };
> + int ret;
> +
> + ret = asus_send_ec_command(hdev, ec_init_cmd);
> +
> + if (ret < 0)
> + return ret;
> +
> + u8 brightness_cmd[A14_EC_REPORT_SIZE] = { A14_EC_REPORT_ID, 0xBA, 0xC5,
> + 0xC4, A14_EC_MAX_BACKLIGHT };
> +
> + ret = asus_send_ec_command(hdev, brightness_cmd);
> + if (ret < 0)
> + dev_warn(&hdev->dev, "Brightness init failed: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static void asus_kbd_set_brightness(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct asus_hid_data *data = container_of(led_cdev, struct asus_hid_data, kbd_led_cdev);
> +
> + u8 level = (u8)brightness;
> +
> + if (level > A14_EC_MAX_BACKLIGHT)
> + level = A14_EC_MAX_BACKLIGHT;
> +
> + u8 buf[A14_EC_REPORT_SIZE] = { A14_EC_REPORT_ID, 0xBA, 0xC5, 0xC4, level };
> +
> + asus_send_ec_command(data->hdev, buf);
> + msleep(20);
> + data->saved_brightness = (enum led_brightness)level;
> +}
> +
> +static int asus_raw_event(struct hid_device *hdev, struct hid_report *report,
> + u8 *raw_data, int size)
> +{
> + struct asus_hid_data *data = hid_get_drvdata(hdev);
> + struct input_dev *input_dev = data->hotkey_input_dev;
> +
> + if (report->id == A14_EC_REPORT_ID && size >= 2) {
> + u8 usage_code = raw_data[1];
> +
> + switch (usage_code) {
> + case A14_EC_EVT_KEY_FN_ESC:
> + input_event(input_dev, EV_KEY, KEY_FN_ESC, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_FN_ESC, 0);
> + input_sync(input_dev);
> + return 1;
> +
> + /* FN + F1, F2 and F3 are not managed by EC*/
> +
> + case A14_EC_EVT_KEY_FN_F4:
> + if (size >= 3) {
> + u8 current_level = data->saved_brightness;
> + u8 max_level = A14_EC_MAX_BACKLIGHT;
> + u8 next_level = (current_level + 1) % (max_level + 1);
> +
> + asus_kbd_set_brightness(&data->kbd_led_cdev,
> + (enum led_brightness)next_level);
> + if (next_level > current_level ||
> + (current_level == max_level && next_level == 0)) {
> + if (next_level == 0) {
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + } else {
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMUP, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMUP, 0);
> + input_sync(input_dev);
> + }
> + } else if (next_level < current_level) {
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY,
> + KEY_KBDILLUMDOWN, 0);
> + input_sync(input_dev);
> + }
> + }
> + return 1;
> + case A14_EC_EVT_KEY_FN_F5:
> + input_event(input_dev, EV_KEY, KEY_BRIGHTNESSDOWN, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_BRIGHTNESSDOWN, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F6:
> + input_event(input_dev, EV_KEY, KEY_BRIGHTNESSUP, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_BRIGHTNESSUP, 0);
> + input_sync(input_dev);
> + return 1;
> +
> + /* FN + F7 is not managed by the EC*/
> +
> + case A14_EC_EVT_KEY_FN_F8:
> + input_event(input_dev, EV_KEY, KEY_EMOJI_PICKER, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_EMOJI_PICKER, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F9:
> + input_event(input_dev, EV_KEY, KEY_MICMUTE, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_MICMUTE, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F10:
> + input_event(input_dev, EV_KEY, KEY_CAMERA_ACCESS_TOGGLE, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_CAMERA_ACCESS_TOGGLE, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F11:
> + input_event(input_dev, EV_KEY, KEY_TOUCHPAD_TOGGLE, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_TOUCHPAD_TOGGLE, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F12:
> + input_event(input_dev, EV_KEY, KEY_PROG1, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_PROG1, 0);
> + input_sync(input_dev);
> + return 1;
> + case A14_EC_EVT_KEY_FN_F:
> + input_event(input_dev, EV_KEY, KEY_PERFORMANCE, 1);
> + input_sync(input_dev);
> + input_event(input_dev, EV_KEY, KEY_PERFORMANCE, 0);
> + input_sync(input_dev);
> + return 1;
> + default:
> + return 0;
> + }
> + }
> + return 0;
> +}
> +
> +static int asus_hid_suspend(struct hid_device *hdev, pm_message_t message)
> +{
> + struct asus_hid_data *data = hid_get_drvdata(hdev);
> +
> + if (message.event == PM_EVENT_SUSPEND || message.event == PM_EVENT_HIBERNATE) {
> + asus_kbd_set_brightness(&data->kbd_led_cdev, LED_OFF);
> + return 0;
> + }
> +
> + dev_dbg(&hdev->dev, "Runtime suspend: turning off keyboard backlight\n");
> + asus_kbd_set_brightness(&data->kbd_led_cdev, LED_OFF);
> + return 0;
> +}
> +
> +
> +static int asus_hid_resume(struct hid_device *hdev)
> +{
> + struct asus_hid_data *data = hid_get_drvdata(hdev);
> + int ret;
> + int retry_count;
> +
> + msleep(40);
> +
> + dev_dbg(&hdev->dev, "Re-initialising EC backlight communication\n");
> + retry_count = 0;
> + do {
> + ret = asus_kbd_led_init(hdev);
> + if (ret >= 0) {
> + dev_dbg(&hdev->dev,
> + "EC init successful on attempt %d\n",
> + retry_count + 1);
> + break;
> + }
> + retry_count++;
> + dev_warn(&hdev->dev,
> + "EC init attempt %d failed: %d, retrying...\n",
> + retry_count, ret);
> + msleep(300 * retry_count);
> + } while (retry_count < 5);
> +
> + if (ret < 0) {
> + dev_err(&hdev->dev,
> + "EC init on resume failed after %d attempts: %d\n",
> + retry_count, ret);
> + dev_err(&hdev->dev,
> + "Keyboard backlight may not work; try reloading the driver\n");
> + } else {
> + dev_dbg(&hdev->dev, "EC backlight communication restored\n");
> + }
> +
> + asus_kbd_set_brightness(&data->kbd_led_cdev, data->saved_brightness);
> +
> + dev_info(&hdev->dev, "Resume complete\n");
> + return 0;
> +}
> +
> +static const struct hid_device_id asus_hid_devices[] = {
> + /* Tested on ASUS Zenbook A14 (UX3407QA) only. */
> + { HID_DEVICE(0x18, 0x00, ASUS_VENDOR_ID, ASUS_PRODUCT_ID) },
> + { } /* Terminating entry */
> +};
> +MODULE_DEVICE_TABLE(hid, asus_hid_devices);
> +
> +static int asus_hid_probe(struct hid_device *hdev, const struct hid_device_id *id)
> +{
> + int ret;
> + struct asus_hid_data *data;
> +
> + data = devm_kzalloc(&hdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> + data->hdev = hdev;
> + hid_set_drvdata(hdev, data);
> + asus_data = data;
> + data->saved_brightness = A14_EC_MAX_BACKLIGHT;
> + ret = hid_parse(hdev);
> + if (ret)
> + return ret;
> + ret = hid_hw_start(hdev, HID_INPUT_REPORT | HID_OUTPUT_REPORT | HID_FEATURE_REPORT);
> + if (ret)
> + return ret;
> + data->hotkey_input_dev = input_allocate_device();
> + if (!data->hotkey_input_dev) {
> + dev_err(&hdev->dev, "Failed to allocate hotkey input device\n");
> + hid_hw_stop(hdev); return -ENOMEM;
> + }
> + data->hotkey_input_dev->name = "ASUS EC I2C HID hotkeys";
> + data->hotkey_input_dev->phys = "i2c-hid/input1/hotkeys";
> + data->hotkey_input_dev->id.bustype = hdev->bus;
> + data->hotkey_input_dev->id.vendor = hdev->vendor;
> + data->hotkey_input_dev->id.product = hdev->product;
> + data->hotkey_input_dev->dev.parent = &hdev->dev;
> + set_bit(EV_KEY, data->hotkey_input_dev->evbit);
> + set_bit(KEY_FN_ESC, data->hotkey_input_dev->keybit);
> + set_bit(KEY_KBDILLUMUP, data->hotkey_input_dev->keybit);
> + set_bit(KEY_KBDILLUMDOWN, data->hotkey_input_dev->keybit);
> + set_bit(KEY_BRIGHTNESSDOWN, data->hotkey_input_dev->keybit);
> + set_bit(KEY_BRIGHTNESSUP, data->hotkey_input_dev->keybit);
> + set_bit(KEY_SWITCHVIDEOMODE, data->hotkey_input_dev->keybit);
> + set_bit(KEY_EMOJI_PICKER, data->hotkey_input_dev->keybit);
> + set_bit(KEY_MICMUTE, data->hotkey_input_dev->keybit);
> + set_bit(KEY_CAMERA_ACCESS_TOGGLE, data->hotkey_input_dev->keybit);
> + set_bit(KEY_TOUCHPAD_TOGGLE, data->hotkey_input_dev->keybit);
> + set_bit(KEY_PROG1, data->hotkey_input_dev->keybit);
> + set_bit(KEY_PERFORMANCE, data->hotkey_input_dev->keybit);
> +
> + ret = input_register_device(data->hotkey_input_dev);
> + if (ret) {
> + dev_err(&hdev->dev, "Failed to register hotkey input device\n");
> + input_free_device(data->hotkey_input_dev); hid_hw_stop(hdev);
> + return ret;
> + }
> + asus_kbd_led_init(hdev);
> + data->kbd_led_cdev.name = "asus::kbd_backlight";
> + data->kbd_led_cdev.brightness_set = asus_kbd_set_brightness;
> + data->kbd_led_cdev.max_brightness = A14_EC_MAX_BACKLIGHT;
> + ret = led_classdev_register(&hdev->dev, &data->kbd_led_cdev);
> + if (ret) {
> + input_unregister_device(data->hotkey_input_dev);
> + hid_hw_stop(hdev);
> + return ret;
> + }
> + dev_info(&hdev->dev,
> + "ASUS EC HID driver for Zenbook A14 loaded for 0x%04x:0x%04x\n",
> + ASUS_VENDOR_ID, ASUS_PRODUCT_ID);
> + return 0;
> +}
> +static void asus_hid_remove(struct hid_device *hdev)
> +{
> + struct asus_hid_data *data = hid_get_drvdata(hdev);
> +
> + led_classdev_unregister(&data->kbd_led_cdev);
> + input_unregister_device(data->hotkey_input_dev);
> + hid_hw_stop(hdev);
> + asus_data = NULL;
> +}
> +static struct hid_driver hid_asus_ec_driver = {
> + .name = "hid-asus-ec",
> + .id_table = asus_hid_devices,
> + .probe = asus_hid_probe,
> + .remove = asus_hid_remove,
> + .raw_event = asus_raw_event,
> + .suspend = asus_hid_suspend,
> + .resume = asus_hid_resume,
> +};
> +module_hid_driver(hid_asus_ec_driver);
> +MODULE_AUTHOR("Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>");
> +MODULE_DESCRIPTION("ASUS EC HID driver for Zenbook A14 (UX3407QA)");
> +MODULE_LICENSE("GPL");
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251221-add-support-for-the-asus-hid-ec-a60b9a2d74b3
>
> Best regards,
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS ee89db004238bd0b034f2a6176e175561658750b
From: kernel test robot @ 2026-06-30 18:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: ee89db004238bd0b034f2a6176e175561658750b Input: maplemouse - fix NULL pointer dereference in open()
elapsed time: 746m
configs tested: 284
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260630 clang-23
arc randconfig-001-20260701 gcc-12.5.0
arc randconfig-002-20260630 clang-23
arc randconfig-002-20260701 gcc-12.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001-20260630 clang-23
arm randconfig-001-20260701 gcc-12.5.0
arm randconfig-002-20260630 clang-23
arm randconfig-002-20260701 gcc-12.5.0
arm randconfig-003-20260630 clang-23
arm randconfig-003-20260701 gcc-12.5.0
arm randconfig-004-20260630 clang-23
arm randconfig-004-20260701 gcc-12.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260630 clang-23
arm64 randconfig-002-20260630 clang-23
arm64 randconfig-003-20260630 clang-23
arm64 randconfig-004-20260630 clang-23
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260630 clang-23
csky randconfig-002-20260630 clang-23
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260630 clang-18
hexagon randconfig-002-20260630 clang-18
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260630 clang-22
i386 buildonly-randconfig-001-20260701 clang-22
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260630 clang-22
i386 buildonly-randconfig-002-20260701 clang-22
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260630 clang-22
i386 buildonly-randconfig-003-20260701 clang-22
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260630 clang-22
i386 buildonly-randconfig-004-20260701 clang-22
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260630 clang-22
i386 buildonly-randconfig-005-20260701 clang-22
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260630 clang-22
i386 buildonly-randconfig-006-20260701 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260630 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260630 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260630 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260630 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260630 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260630 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260630 clang-22
i386 randconfig-011 gcc-12
i386 randconfig-011-20260630 gcc-12
i386 randconfig-012 gcc-12
i386 randconfig-012-20260630 gcc-12
i386 randconfig-013 gcc-12
i386 randconfig-013-20260630 gcc-12
i386 randconfig-014 gcc-12
i386 randconfig-014-20260630 gcc-12
i386 randconfig-015 gcc-12
i386 randconfig-015-20260630 gcc-12
i386 randconfig-016 gcc-12
i386 randconfig-016-20260630 gcc-12
i386 randconfig-017 gcc-12
i386 randconfig-017-20260630 gcc-12
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260630 clang-18
loongarch randconfig-002-20260630 clang-18
m68k alldefconfig gcc-16.1.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips bmips_stb_defconfig clang-17
mips malta_kvm_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260630 clang-18
nios2 randconfig-002-20260630 clang-18
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260630 clang-22
parisc randconfig-001-20260701 clang-17
parisc randconfig-002-20260630 clang-22
parisc randconfig-002-20260701 clang-17
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260630 clang-22
powerpc randconfig-001-20260701 clang-17
powerpc randconfig-002-20260630 clang-22
powerpc randconfig-002-20260701 clang-17
powerpc64 randconfig-001-20260630 clang-22
powerpc64 randconfig-001-20260701 clang-17
powerpc64 randconfig-002-20260630 clang-22
powerpc64 randconfig-002-20260701 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-9.5.0
riscv randconfig-001-20260630 gcc-9.5.0
riscv randconfig-002 gcc-9.5.0
riscv randconfig-002-20260630 gcc-9.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-9.5.0
s390 randconfig-001-20260630 gcc-9.5.0
s390 randconfig-002 gcc-9.5.0
s390 randconfig-002-20260630 gcc-9.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 gcc-9.5.0
sh randconfig-001-20260630 gcc-9.5.0
sh randconfig-002 gcc-9.5.0
sh randconfig-002-20260630 gcc-9.5.0
sh se7750_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 clang-17
sparc randconfig-001-20260630 clang-17
sparc randconfig-002 clang-17
sparc randconfig-002-20260630 clang-17
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 clang-17
sparc64 randconfig-001-20260630 clang-17
sparc64 randconfig-002 clang-17
sparc64 randconfig-002-20260630 clang-17
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 clang-17
um randconfig-001-20260630 clang-17
um randconfig-002 clang-17
um randconfig-002-20260630 clang-17
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260630 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260630 clang-22
x86_64 buildonly-randconfig-002-20260630 gcc-14
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260630 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260630 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260630 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260630 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260630 gcc-14
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260630 gcc-14
x86_64 randconfig-003 gcc-14
x86_64 randconfig-003-20260630 gcc-14
x86_64 randconfig-004 gcc-14
x86_64 randconfig-004-20260630 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260630 gcc-14
x86_64 randconfig-006 gcc-14
x86_64 randconfig-006-20260630 gcc-14
x86_64 randconfig-011-20260630 gcc-14
x86_64 randconfig-012-20260630 gcc-14
x86_64 randconfig-013-20260630 gcc-14
x86_64 randconfig-014-20260630 gcc-14
x86_64 randconfig-015-20260630 gcc-14
x86_64 randconfig-016-20260630 gcc-14
x86_64 randconfig-071 gcc-13
x86_64 randconfig-071-20260630 clang-22
x86_64 randconfig-071-20260630 gcc-13
x86_64 randconfig-071-20260701 gcc-14
x86_64 randconfig-072 gcc-13
x86_64 randconfig-072-20260630 clang-22
x86_64 randconfig-072-20260630 gcc-13
x86_64 randconfig-072-20260701 gcc-14
x86_64 randconfig-073 gcc-13
x86_64 randconfig-073-20260630 clang-22
x86_64 randconfig-073-20260630 gcc-13
x86_64 randconfig-073-20260701 gcc-14
x86_64 randconfig-074 gcc-13
x86_64 randconfig-074-20260630 clang-22
x86_64 randconfig-074-20260630 gcc-13
x86_64 randconfig-074-20260701 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260630 clang-22
x86_64 randconfig-075-20260630 gcc-13
x86_64 randconfig-075-20260701 gcc-14
x86_64 randconfig-076 gcc-13
x86_64 randconfig-076-20260630 clang-22
x86_64 randconfig-076-20260630 gcc-13
x86_64 randconfig-076-20260701 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001 clang-17
xtensa randconfig-001-20260630 clang-17
xtensa randconfig-002 clang-17
xtensa randconfig-002-20260630 clang-17
xtensa smp_lx200_defconfig gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Input: maplemouse - set driver data before registering input device
From: Florian Fuchs @ 2026-06-30 19:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Adrian McMenamin, linux-kernel
In-Reply-To: <akNXw45L_8bxD6QV@google.com>
On 29 Jun 22:47, Dmitry Torokhov wrote:
> Set maple driver data before calling input_register_device() to
> ensure that it is available if the device is opened immediately and
> the callback is triggered.
>
> Cc: stable@vger.kernel.org
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/mouse/maplemouse.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
> index c41182766538..0c8f7d1b02aa 100644
> --- a/drivers/input/mouse/maplemouse.c
> +++ b/drivers/input/mouse/maplemouse.c
> @@ -88,6 +88,8 @@ static int probe_maple_mouse(struct device *dev)
> mse->dev = input_dev;
> mse->mdev = mdev;
>
> + maple_set_drvdata(mdev, mse);
> +
> input_set_drvdata(input_dev, mse);
> input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
> input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) |
> @@ -103,12 +105,12 @@ static int probe_maple_mouse(struct device *dev)
> goto fail_register;
>
> mdev->driver = mdrv;
> - maple_set_drvdata(mdev, mse);
>
> return error;
>
> fail_register:
> input_free_device(input_dev);
> + maple_set_drvdata(mdev, NULL);
> fail_nomem:
> kfree(mse);
> fail:
> --
> 2.55.0.rc0.799.gd6f94ed593-goog
>
>
> --
> Dmitry
Tested-by: Florian Fuchs <fuchsfl@gmail.com>
Regards
Florian
^ permalink raw reply
* Re: [PATCH] Input: maplecontrol - set driver data before registering input device
From: Florian Fuchs @ 2026-06-30 19:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Adrian McMenamin, linux-input, linux-kernel
In-Reply-To: <akNYib9hQFNN1fA9@google.com>
On 29 Jun 22:49, Dmitry Torokhov wrote:
> Set maple driver data before calling input_register_device() to
> ensure that it is available if the device is opened immediately and
> the callback is triggered.
>
> Cc: stable@vger.kernel.org
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/joystick/maplecontrol.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 7f36f73844a9..6293b6e8148b 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -112,6 +112,8 @@ static int probe_maple_controller(struct device *dev)
> pad->dev = idev;
> pad->mdev = mdev;
>
> + maple_set_drvdata(mdev, pad);
> +
> idev->open = dc_pad_open;
> idev->close = dc_pad_close;
>
> @@ -146,7 +148,6 @@ static int probe_maple_controller(struct device *dev)
> goto fail;
>
> mdev->driver = mdrv;
> - maple_set_drvdata(mdev, pad);
>
> return 0;
>
> --
> 2.55.0.rc0.799.gd6f94ed593-goog
>
>
> --
> Dmitry
Tested-by: Florian Fuchs <fuchsfl@gmail.com>
Regards
Florian
^ permalink raw reply
* [PATCH] HID: hiddev: set report-init policy before device registration
From: Yousef Alhouseen @ 2026-06-30 21:18 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-usb, linux-input, linux-kernel, Yousef Alhouseen
usb_register_dev() publishes the hiddev character device before
hiddev_connect() initializes the report policy. A process that opens the
new node immediately can issue a usage ioctl while initialized is still
false and trigger usbhid_init_reports(), bypassing
HID_QUIRK_NO_INIT_REPORTS.
Set initialized before registering the character device so every opener
observes the quirk-selected policy.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/hid/usbhid/hiddev.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 6378801b22c6..c822e7dee8b7 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -900,6 +900,8 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
hid->hiddev = hiddev;
hiddev->hid = hid;
hiddev->exist = 1;
+ /* Honor NO_INIT_REPORTS before the character device becomes visible. */
+ hiddev->initialized = hid->quirks & HID_QUIRK_NO_INIT_REPORTS;
retval = usb_register_dev(usbhid->intf, &hiddev_class);
if (retval) {
hid_err(hid, "Not able to get a minor for this device\n");
@@ -908,12 +910,6 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
return retval;
}
- /*
- * If HID_QUIRK_NO_INIT_REPORTS is set, make sure we don't initialize
- * the reports.
- */
- hiddev->initialized = hid->quirks & HID_QUIRK_NO_INIT_REPORTS;
-
hiddev->minor = usbhid->intf->minor;
return 0;
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-06-30 21:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Jakub Kicinski,
Paolo Abeni, Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-media, netdev, linux-sunxi, linux-phy,
linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 3:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
This is helpful.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 03/13] mips: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-4-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/alchemy/board-xxs1500.c | 2 +-
> arch/mips/alchemy/devboards/db1000.c | 2 +-
> arch/mips/alchemy/devboards/db1200.c | 2 +-
> arch/mips/alchemy/devboards/db1550.c | 2 +-
> arch/mips/bcm47xx/workarounds.c | 2 +-
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 8 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/13] sh: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-5-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for the sh boards using the legacy interfaces,
> or remove it where it is not needed at all.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/sh/boards/board-magicpanelr2.c | 2 +-
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> arch/sh/boards/board-urquell.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7269.c | 1 -
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 2 +-
> 15 files changed, 13 insertions(+), 16 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Philippe Mathieu-Daudé @ 2026-06-30 22:09 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> After all other drivers have converted to linux/gpio/consumer.h
> or linux/gpio/legacy.h, remove the final leftover bits here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> MAINTAINERS | 1 -
> drivers/gpio/TODO | 4 +---
> drivers/gpio/gpiolib-cdev.c | 2 +-
> drivers/gpio/gpiolib-legacy.c | 3 +--
> drivers/gpio/gpiolib.c | 2 +-
> include/linux/gpio.h | 22 ----------------------
> 6 files changed, 4 insertions(+), 30 deletions(-)
> delete mode 100644 include/linux/gpio.h
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 1/3] HID: wacom: Fix Use-After-Free in wacom_intuos_pad
From: Jason Gerecke @ 2026-06-30 23:27 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Peter Hutterer, Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20260616092658.1714548-1-lee@kernel.org>
I'm still working on testing and reviewing this set as a whole, but I
can provide some immediate feedback on this first patch at least:
On Tue, Jun 16, 2026 at 2:29 AM Lee Jones <lee@kernel.org> wrote:
>
> wacom_intuos_pad() accesses wacom->shared->touch_input locklessly
> inside the interrupt handler context. If the Touch sibling device
> is disconnected, wacom_remove_shared_data() clears 'touch_input'
> outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU)
> race condition where a preempted reader in interrupt context
> dereferences the freed pointer, leading to a Use-After-Free.
>
> Resolve this by introducing RCU protection for the touch_input
> pointer:
>
> - Annotate 'touch_input' in wacom_shared struct with __rcu
> - Wrap all lockless readers in wacom_wac.c with rcu_read_lock() and
> rcu_dereference() using a unified wacom_report_touch_mute()
> helper
> - Update writers in wacom_sys.c using rcu_assign_pointer()
> - Call synchronize_rcu() in wacom_remove_shared_data() to ensure
> all active RCU readers have finished before the input device is
> freed
>
> Also wrap wacom_set_shared_values() and touch/pen assignments in
> wacom_add_shared_data() inside the wacom_udev_list_lock to serialize
> concurrent probe assignments, and verify that 'shared->touch == hdev'
> before setting touch_input to prevent concurrent sibling probe state
> desynchronization.
>
> Finally, advertise the SW_MUTE_DEVICE capability on Touch input
> devices prior to registration in wacom_setup_touch_input_capabilities()
> to prevent invalid post-registration capability modifications.
>
It seems like this patch can be split into at least two different
patches, maybe even three. The changes to
wacom_setup_touch_input_capabilities() especially feel like they could
be seperate from the introduction of RCU for shared->touch_input.
> Fixes: 961794a00eab ("Input: wacom - add reporting of SW_MUTE_DEVICE events")
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
>
> v1 -> v2: Split and use RCU as per Dmitry's review
> v2 -> v3: Sashiko fixes
> v3 -> v4: Dmitry's review [redundant check and guard()]
>
> drivers/hid/wacom_sys.c | 41 ++++++++++++++-----------
> drivers/hid/wacom_wac.c | 66 +++++++++++++++++++++--------------------
> drivers/hid/wacom_wac.h | 2 +-
> 3 files changed, 58 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 2220168bf116..86895f13dbae 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -877,10 +877,16 @@ static void wacom_remove_shared_data(void *res)
> data = container_of(wacom_wac->shared, struct wacom_hdev_data,
> shared);
>
> - if (wacom_wac->shared->touch == wacom->hdev)
> - wacom_wac->shared->touch = NULL;
> - else if (wacom_wac->shared->pen == wacom->hdev)
> - wacom_wac->shared->pen = NULL;
> + scoped_guard(mutex, &wacom_udev_list_lock) {
> + if (wacom_wac->shared->touch == wacom->hdev) {
> + wacom_wac->shared->touch = NULL;
> + rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
> + } else if (wacom_wac->shared->pen == wacom->hdev) {
> + wacom_wac->shared->pen = NULL;
> + }
> + }
> +
> + synchronize_rcu();
>
> kref_put(&data->kref, wacom_release_shared_data);
> wacom_wac->shared = NULL;
> @@ -909,6 +915,11 @@ static int wacom_add_shared_data(struct hid_device *hdev)
> list_add_tail(&data->list, &wacom_udev_list);
> }
>
> + if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
> + data->shared.touch = hdev;
> + else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
> + data->shared.pen = hdev;
> +
> mutex_unlock(&wacom_udev_list_lock);
>
> wacom_wac->shared = &data->shared;
> @@ -917,11 +928,6 @@ static int wacom_add_shared_data(struct hid_device *hdev)
> if (retval)
> return retval;
>
> - if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
> - wacom_wac->shared->touch = hdev;
> - else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
> - wacom_wac->shared->pen = hdev;
> -
> return retval;
> }
>
> @@ -2345,9 +2351,15 @@ static void wacom_release_resources(struct wacom *wacom)
>
> static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
> {
> + struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
> +
> + guard(mutex)(&wacom_udev_list_lock);
> +
> if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH) {
> - wacom_wac->shared->type = wacom_wac->features.type;
> - wacom_wac->shared->touch_input = wacom_wac->touch_input;
> + if (wacom_wac->shared->touch == wacom->hdev) {
> + wacom_wac->shared->type = wacom_wac->features.type;
> + rcu_assign_pointer(wacom_wac->shared->touch_input, wacom_wac->touch_input);
> + }
> }
>
> if (wacom_wac->has_mute_touch_switch) {
> @@ -2360,13 +2372,6 @@ static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
> if (wacom_wac->is_soft_touch_switch)
> wacom_wac->shared->is_touch_on = true;
> }
> -
> - if (wacom_wac->shared->has_mute_touch_switch &&
> - wacom_wac->shared->touch_input) {
> - set_bit(EV_SW, wacom_wac->shared->touch_input->evbit);
> - input_set_capability(wacom_wac->shared->touch_input, EV_SW,
> - SW_MUTE_DEVICE);
> - }
> }
>
> static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625..23eaa81cd827 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -510,6 +510,18 @@ static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
> }
> }
>
> +static void wacom_report_touch_mute(struct wacom_wac *wacom_wac, bool mute)
> +{
> + struct input_dev *touch_input;
> +
> + guard(rcu)();
> + touch_input = rcu_dereference(wacom_wac->shared->touch_input);
> + if (touch_input) {
> + input_report_switch(touch_input, SW_MUTE_DEVICE, mute);
> + input_sync(touch_input);
> + }
> +}
> +
> static int wacom_intuos_pad(struct wacom_wac *wacom)
> {
> struct wacom_features *features = &wacom->features;
> @@ -650,12 +662,8 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
> input_report_key(input, KEY_CONTROLPANEL, menu);
> input_report_key(input, KEY_INFO, info);
>
> - if (wacom->shared && wacom->shared->touch_input) {
> - input_report_switch(wacom->shared->touch_input,
> - SW_MUTE_DEVICE,
> - !wacom->shared->is_touch_on);
> - input_sync(wacom->shared->touch_input);
> - }
> + if (wacom->shared)
> + wacom_report_touch_mute(wacom, !wacom->shared->is_touch_on);
>
> input_report_abs(input, ABS_RX, strip1);
> input_report_abs(input, ABS_RY, strip2);
> @@ -2153,7 +2161,7 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
> */
> if ((equivalent_usage == WACOM_HID_WD_MUTE_DEVICE) ||
> (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)) {
> - if (wacom_wac->shared->touch_input) {
> + if (wacom_wac->shared) {
> bool *is_touch_on = &wacom_wac->shared->is_touch_on;
>
> if (equivalent_usage == WACOM_HID_WD_MUTE_DEVICE && value)
> @@ -2161,9 +2169,7 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
> else if (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)
> *is_touch_on = value;
>
> - input_report_switch(wacom_wac->shared->touch_input,
> - SW_MUTE_DEVICE, !(*is_touch_on));
> - input_sync(wacom_wac->shared->touch_input);
> + wacom_report_touch_mute(wacom_wac, !(*is_touch_on));
> }
> return;
> }
> @@ -3381,11 +3387,8 @@ static int wacom_wireless_irq(struct wacom_wac *wacom, size_t len)
>
> if ((wacom->shared->type == INTUOSHT ||
> wacom->shared->type == INTUOSHT2) &&
> - wacom->shared->touch_input &&
> wacom->shared->touch_max) {
> - input_report_switch(wacom->shared->touch_input,
> - SW_MUTE_DEVICE, data[5] & 0x40);
> - input_sync(wacom->shared->touch_input);
> + wacom_report_touch_mute(wacom, data[5] & 0x40);
> }
>
> pid = get_unaligned_be16(&data[6]);
> @@ -3420,11 +3423,8 @@ static int wacom_status_irq(struct wacom_wac *wacom_wac, size_t len)
>
> if ((features->type == INTUOSHT ||
> features->type == INTUOSHT2) &&
> - wacom_wac->shared->touch_input &&
> features->touch_max) {
> - input_report_switch(wacom_wac->shared->touch_input,
> - SW_MUTE_DEVICE, data[8] & 0x40);
> - input_sync(wacom_wac->shared->touch_input);
> + wacom_report_touch_mute(wacom_wac, data[8] & 0x40);
> }
>
> if (data[9] & 0x02) { /* wireless module is attached */
> @@ -3951,11 +3951,22 @@ int wacom_setup_pen_input_capabilities(struct input_dev *input_dev,
> int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
> struct wacom_wac *wacom_wac)
> {
> + struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
> + struct hid_device *hdev = wacom->hdev;
> struct wacom_features *features = &wacom_wac->features;
>
> if (!(features->device_type & WACOM_DEVICETYPE_TOUCH))
> return -ENODEV;
>
> + if (features->type != TABLETPC &&
> + features->type != TABLETPC2FG &&
> + features->type != MTSCREEN &&
> + features->type != MTTPC &&
> + features->type != MTTPC_B) {
> + input_dev->evbit[0] |= BIT_MASK(EV_SW);
> + __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
> + }
> +
1. This if statement is missing a number of cases. INTUOS5, for
example (and among others) is missing and would incorrectly gain
SW_MUTE_DEVICE. The list of cases from the big switch below needs to
be consulted again.
2. It seems like this would result in SW_MUTE_DEVICE being given to
all HID_GENERIC touch devices. It should only be added in the case
that `wacom_wac->has_mute_touch_switch` is true, however.
3. I'm not sure why we're even bothering with moving all of the
initialization for SW_MUTE_DEVICE from the individual cases out to a
single awkward if statement. The only thing I can think of is that
HID_GENERIC devices need to have it set (when appropriate) now that
the responsibility has been removed from wacom_set_shared_values(). It
should be much cleaner, however, to simply add the SW_MUTE_DEVICE
setup for HID_GENERIC devices right before the function returns early
for them.
> if (features->device_type & WACOM_DEVICETYPE_DIRECT)
> __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
> else
> @@ -3992,22 +4003,17 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
> switch (features->type) {
> case INTUOSP2_BT:
> case INTUOSP2S_BT:
> - input_dev->evbit[0] |= BIT_MASK(EV_SW);
> - __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
> -
> - if (wacom_wac->shared->touch->product == 0x361) {
> + if (hdev->product == 0x361) {
> input_set_abs_params(input_dev, ABS_MT_POSITION_X,
> 0, 12440, 4, 0);
> input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
> 0, 8640, 4, 0);
> - }
> - else if (wacom_wac->shared->touch->product == 0x360) {
> + } else if (hdev->product == 0x360) {
> input_set_abs_params(input_dev, ABS_MT_POSITION_X,
> 0, 8960, 4, 0);
> input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
> 0, 5920, 4, 0);
> - }
> - else if (wacom_wac->shared->touch->product == 0x393) {
> + } else if (hdev->product == 0x393) {
> input_set_abs_params(input_dev, ABS_MT_POSITION_X,
> 0, 6400, 4, 0);
> input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
> @@ -4037,10 +4043,8 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
> fallthrough;
>
> case WACOM_27QHDT:
> - if (wacom_wac->shared->touch->product == 0x32C ||
> - wacom_wac->shared->touch->product == 0xF6) {
> - input_dev->evbit[0] |= BIT_MASK(EV_SW);
> - __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
> + if (hdev->product == 0x32C ||
> + hdev->product == 0xF6) {
> wacom_wac->has_mute_touch_switch = true;
> wacom_wac->is_soft_touch_switch = true;
> }
> @@ -4059,8 +4063,6 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
>
> case INTUOSHT:
> case INTUOSHT2:
> - input_dev->evbit[0] |= BIT_MASK(EV_SW);
> - __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
> fallthrough;
>
> case BAMBOO_PT:
> diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
> index 126bec6e5c0c..a8bbba4a6f37 100644
> --- a/drivers/hid/wacom_wac.h
> +++ b/drivers/hid/wacom_wac.h
> @@ -285,7 +285,7 @@ struct wacom_shared {
> /* for wireless device to access USB interfaces */
> unsigned touch_max;
> int type;
> - struct input_dev *touch_input;
> + struct input_dev __rcu *touch_input;
> struct hid_device *pen;
> struct hid_device *touch;
> bool has_mute_touch_switch;
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
>
^ permalink raw reply
* [PATCH v3] HID: cleanup help indentation in kconfig
From: Julian Braha @ 2026-06-30 23:34 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, Julian Braha
The indentation in this kconfig was all over the place:
Half of the 'help' texts were not indented, while the other
half indented by the more standard 2 spaces shown in the
kconfig documentation.
Let's standardize to 2 spaces.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
v3: fix even more lines' indentation (sashiko, again)
Link to v2:
https://lore.kernel.org/all/20260630150134.514348-1-julianbraha@gmail.com/
v2: fix 2 more lines' indentation, thanks sashiko
Link to v1:
https://lore.kernel.org/all/20260630142043.496559-1-julianbraha@gmail.com/
drivers/hid/Kconfig | 662 ++++++++++++++++++++++----------------------
1 file changed, 331 insertions(+), 331 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f9bcaeb66385..9f72b8b5966b 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -38,77 +38,77 @@ config HID_BATTERY_STRENGTH
select POWER_SUPPLY
default n
help
- This option adds support of reporting battery strength (for HID devices
- that support this feature) through power_supply class so that userspace
- tools, such as upower, can display it.
+ This option adds support of reporting battery strength (for HID devices
+ that support this feature) through power_supply class so that userspace
+ tools, such as upower, can display it.
config HIDRAW
bool "/dev/hidraw raw HID device support"
help
- Say Y here if you want to support HID devices (from the USB
- specification standpoint) that aren't strictly user interface
- devices, like monitor controls and Uninterruptible Power Supplies.
+ Say Y here if you want to support HID devices (from the USB
+ specification standpoint) that aren't strictly user interface
+ devices, like monitor controls and Uninterruptible Power Supplies.
- This module supports these devices separately using a separate
- event interface on /dev/hidraw.
+ This module supports these devices separately using a separate
+ event interface on /dev/hidraw.
- There is also a /dev/hiddev configuration option in the USB HID
- configuration menu. In comparison to hiddev, this device does not process
- the hid events at all (no parsing, no lookups). This lets applications
- to work on raw hid events when they want to, and avoid using transport-specific
- userspace libhid/libusb libraries.
+ There is also a /dev/hiddev configuration option in the USB HID
+ configuration menu. In comparison to hiddev, this device does not process
+ the hid events at all (no parsing, no lookups). This lets applications
+ to work on raw hid events when they want to, and avoid using transport-specific
+ userspace libhid/libusb libraries.
- If unsure, say Y.
+ If unsure, say Y.
config UHID
tristate "User-space I/O driver support for HID subsystem"
default n
help
- Say Y here if you want to provide HID I/O Drivers from user-space.
- This allows to write I/O drivers in user-space and feed the data from
- the device into the kernel. The kernel parses the HID reports, loads the
- corresponding HID Device Driver or provides input devices on top of your
- user-space device.
+ Say Y here if you want to provide HID I/O Drivers from user-space.
+ This allows to write I/O drivers in user-space and feed the data from
+ the device into the kernel. The kernel parses the HID reports, loads the
+ corresponding HID Device Driver or provides input devices on top of your
+ user-space device.
- This driver cannot be used to parse HID-reports in user-space and write
- special HID-drivers. You should use hidraw for that.
- Instead, this driver allows to write the transport-layer driver in
- user-space like USB-HID and Bluetooth-HID do in kernel-space.
+ This driver cannot be used to parse HID-reports in user-space and write
+ special HID-drivers. You should use hidraw for that.
+ Instead, this driver allows to write the transport-layer driver in
+ user-space like USB-HID and Bluetooth-HID do in kernel-space.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called uhid.
+ To compile this driver as a module, choose M here: the
+ module will be called uhid.
config HID_GENERIC
tristate "Generic HID driver"
default HID
help
- Support for generic devices on the HID bus. This includes most
- keyboards and mice, joysticks, tablets and digitizers.
+ Support for generic devices on the HID bus. This includes most
+ keyboards and mice, joysticks, tablets and digitizers.
- To compile this driver as a module, choose M here: the module
- will be called hid-generic.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-generic.
- If unsure, say Y.
+ If unsure, say Y.
config HID_HAPTIC
bool "Haptic touchpad support"
default n
help
- Support for touchpads with force sensors and haptic actuators instead of a
- traditional button.
- Adds extra parsing and FF device for the hid multitouch driver.
- It can be used for Elan 2703 haptic touchpad.
+ Support for touchpads with force sensors and haptic actuators instead of a
+ traditional button.
+ Adds extra parsing and FF device for the hid multitouch driver.
+ It can be used for Elan 2703 haptic touchpad.
- If unsure, say N.
+ If unsure, say N.
menu "Special HID drivers"
config HID_A4TECH
tristate "A4TECH mice"
help
- Support for some A4TECH mice with two scroll wheels.
+ Support for some A4TECH mice with two scroll wheels.
config HID_ACCUTOUCH
tristate "Accutouch touch device"
@@ -118,44 +118,44 @@ config HID_ACCUTOUCH
The driver works around a problem in the reported device capabilities
which causes userspace to detect the device as a mouse rather than
- a touchscreen.
+ a touchscreen.
Say Y here if you have a Accutouch 2216 touch controller.
config HID_ACRUX
tristate "ACRUX game controller support"
help
- Say Y here if you want to enable support for ACRUX game controllers.
+ Say Y here if you want to enable support for ACRUX game controllers.
config HID_ACRUX_FF
bool "ACRUX force feedback support"
depends on HID_ACRUX
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for ACRUX
- game controllers.
+ Say Y here if you want to enable force feedback support for ACRUX
+ game controllers.
config HID_APPLE
tristate "Apple {i,Power,Mac}Books"
depends on LEDS_CLASS
depends on NEW_LEDS
help
- Support for some Apple devices which less or more break
- HID specification.
+ Support for some Apple devices which less or more break
+ HID specification.
- Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
- MacBooks, MacBook Pros and Apple Aluminum.
+ Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
+ MacBooks, MacBook Pros and Apple Aluminum.
config HID_APPLEIR
tristate "Apple infrared receiver"
depends on (USB_HID)
help
- Support for Apple infrared remote control. All the Apple computers from
+ Support for Apple infrared remote control. All the Apple computers from
2005 onwards include such a port, except the unibody Macbook (2009),
and Mac Pros. This receiver is also used in the Apple TV set-top box
prior to the 2010 model.
- Say Y here if you want support for Apple infrared remote control.
+ Say Y here if you want support for Apple infrared remote control.
config HID_APPLETB_BL
tristate "Apple Touch Bar Backlight"
@@ -191,34 +191,34 @@ config HID_ASUS
depends on ASUS_WMI || ASUS_WMI=n
select POWER_SUPPLY
help
- Support for Asus notebook built-in keyboard and touchpad via i2c, and
- the Asus Republic of Gamers laptop keyboard special keys.
+ Support for Asus notebook built-in keyboard and touchpad via i2c, and
+ the Asus Republic of Gamers laptop keyboard special keys.
- Supported devices:
- - EeeBook X205TA
- - VivoBook E200HA
- - GL553V series
- - GL753V series
+ Supported devices:
+ - EeeBook X205TA
+ - VivoBook E200HA
+ - GL553V series
+ - GL753V series
config HID_AUREAL
tristate "Aureal"
help
- Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
+ Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
config HID_BELKIN
tristate "Belkin Flip KVM and Wireless keyboard"
help
- Support for Belkin Flip KVM and Wireless keyboard.
+ Support for Belkin Flip KVM and Wireless keyboard.
config HID_BETOP_FF
tristate "Betop Production Inc. force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- BETOP Production Ltd.
- Currently the following devices are known to be supported:
- - BETOP 2185 PC & BFM MODE
+ Say Y here if you want to enable force feedback support for devices by
+ BETOP Production Ltd.
+ Currently the following devices are known to be supported:
+ - BETOP 2185 PC & BFM MODE
config HID_BIGBEN_FF
tristate "BigBen Interactive Kids' gamepad support"
@@ -235,54 +235,54 @@ config HID_BIGBEN_FF
config HID_CHERRY
tristate "Cherry Cymotion keyboard"
help
- Support for Cherry Cymotion keyboard.
+ Support for Cherry Cymotion keyboard.
config HID_CHICONY
tristate "Chicony devices"
depends on USB_HID
help
- Support for Chicony Tactical pad and special keys on Chicony keyboards.
+ Support for Chicony Tactical pad and special keys on Chicony keyboards.
config HID_CORSAIR
tristate "Corsair devices"
depends on USB_HID && LEDS_CLASS
select POWER_SUPPLY
help
- Support for Corsair devices that are not fully compliant with the
- HID standard.
- Support for Corsair Void headsets.
+ Support for Corsair devices that are not fully compliant with the
+ HID standard.
+ Support for Corsair Void headsets.
- Supported devices:
- - Vengeance K90
- - Scimitar PRO RGB
- - Corsair Void headsets
+ Supported devices:
+ - Vengeance K90
+ - Scimitar PRO RGB
+ - Corsair Void headsets
config HID_COUGAR
tristate "Cougar devices"
help
- Support for Cougar devices that are not fully compliant with the
- HID standard.
+ Support for Cougar devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - Cougar 500k Gaming Keyboard
+ Supported devices:
+ - Cougar 500k Gaming Keyboard
config HID_MACALLY
tristate "Macally devices"
help
- Support for Macally devices that are not fully compliant with the
- HID standard.
+ Support for Macally devices that are not fully compliant with the
+ HID standard.
- supported devices:
- - Macally ikey keyboard
+ supported devices:
+ - Macally ikey keyboard
config HID_PRODIKEYS
tristate "Prodikeys PC-MIDI Keyboard support"
depends on USB_HID && SND
select SND_RAWMIDI
help
- Support for Prodikeys PC-MIDI Keyboard device support.
- Say Y here to enable support for this device.
- - Prodikeys PC-MIDI keyboard.
+ Support for Prodikeys PC-MIDI Keyboard device support.
+ Say Y here to enable support for this device.
+ - Prodikeys PC-MIDI keyboard.
The Prodikeys PC-MIDI acts as a USB Audio device, with one MIDI
input and one MIDI output. These MIDI jacks appear as
a sound "card" in the ALSA sound system.
@@ -293,97 +293,97 @@ config HID_PRODIKEYS
config HID_CMEDIA
tristate "CMedia audio chips"
help
- Support for CMedia CM6533 HID audio jack controls
- and HS100B mute buttons.
+ Support for CMedia CM6533 HID audio jack controls
+ and HS100B mute buttons.
config HID_CP2112
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
depends on USB_HID && HIDRAW && I2C && GPIOLIB
select GPIOLIB_IRQCHIP
help
- Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
- This is a HID device driver which registers as an i2c adapter
- and gpiochip to expose these functions of the CP2112. The
- customizable USB descriptor fields are exposed as sysfs attributes.
+ Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
+ This is a HID device driver which registers as an i2c adapter
+ and gpiochip to expose these functions of the CP2112. The
+ customizable USB descriptor fields are exposed as sysfs attributes.
config HID_CREATIVE_SB0540
tristate "Creative SB0540 infrared receiver"
depends on USB_HID
help
- Support for Creative infrared SB0540-compatible remote controls, such
- as the RM-1500 and RM-1800 remotes.
+ Support for Creative infrared SB0540-compatible remote controls, such
+ as the RM-1500 and RM-1800 remotes.
- Say Y here if you want support for Creative SB0540 infrared receiver.
+ Say Y here if you want support for Creative SB0540 infrared receiver.
config HID_CYPRESS
tristate "Cypress mouse and barcode readers"
help
- Support for cypress mouse and barcode readers.
+ Support for cypress mouse and barcode readers.
config HID_DRAGONRISE
tristate "DragonRise Inc. game controller"
help
- Say Y here if you have DragonRise Inc. game controllers.
- These might be branded as:
- - Tesun USB-703
- - Media-tech MT1504 "Rogue"
- - DVTech JS19 "Gear"
- - Defender Game Master
+ Say Y here if you have DragonRise Inc. game controllers.
+ These might be branded as:
+ - Tesun USB-703
+ - Media-tech MT1504 "Rogue"
+ - DVTech JS19 "Gear"
+ - Defender Game Master
config DRAGONRISE_FF
bool "DragonRise Inc. force feedback"
depends on HID_DRAGONRISE
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for DragonRise Inc.
- game controllers.
+ Say Y here if you want to enable force feedback support for DragonRise Inc.
+ game controllers.
config HID_EMS_FF
tristate "EMS Production Inc. force feedback support"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for devices by
- EMS Production Ltd.
- Currently the following devices are known to be supported:
- - Trio Linker Plus II
+ Say Y here if you want to enable force feedback support for devices by
+ EMS Production Ltd.
+ Currently the following devices are known to be supported:
+ - Trio Linker Plus II
config HID_ELAN
tristate "ELAN USB Touchpad Support"
depends on LEDS_CLASS && USB_HID
help
- Say Y to enable support for the USB ELAN touchpad
- Currently the following devices are known to be supported:
- - HP Pavilion X2 10-p0XX.
+ Say Y to enable support for the USB ELAN touchpad
+ Currently the following devices are known to be supported:
+ - HP Pavilion X2 10-p0XX.
config HID_ELECOM
tristate "ELECOM HID devices"
help
- Support for ELECOM devices:
- - BM084 Bluetooth Mouse
- - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
- - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
- - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
- - HUGE Plus Trackball (M-HT1MRBK)
+ Support for ELECOM devices:
+ - BM084 Bluetooth Mouse
+ - EX-G Trackballs (M-XT3DRBK, M-XT3URBK)
+ - DEFT Trackballs (M-DT1DRBK, M-DT1URBK, M-DT2DRBK, M-DT2URBK)
+ - HUGE Trackballs (M-HT1DRBK, M-HT1URBK)
+ - HUGE Plus Trackball (M-HT1MRBK)
config HID_ELO
tristate "ELO USB 4000/4500 touchscreen"
depends on USB_HID
help
- Support for the ELO USB 4000/4500 touchscreens. Note that this is for
- different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
+ Support for the ELO USB 4000/4500 touchscreens. Note that this is for
+ different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
config HID_EVISION
tristate "EVision Keyboards Support"
depends on HID
help
- Support for some EVision keyboards. Note that this is needed only when
- applying customization using userspace programs.
- Support for some EVision devices requiring report descriptor fixups.
+ Support for some EVision keyboards. Note that this is needed only when
+ applying customization using userspace programs.
+ Support for some EVision devices requiring report descriptor fixups.
config HID_EZKEY
tristate "Ezkey BTC 8193 keyboard"
help
- Support for Ezkey BTC 8193 keyboard.
+ Support for Ezkey BTC 8193 keyboard.
config HID_FT260
tristate "FTDI FT260 USB HID to I2C host support"
@@ -399,12 +399,12 @@ config HID_FT260
config HID_GEMBIRD
tristate "Gembird Joypad"
help
- Support for Gembird JPD-DualForce 2.
+ Support for Gembird JPD-DualForce 2.
config HID_GFRM
tristate "Google Fiber TV Box remote control support"
help
- Support for Google Fiber TV Box remote controls
+ Support for Google Fiber TV Box remote controls
config HID_GLORIOUS
tristate "Glorious PC Gaming Race mice"
@@ -416,14 +416,14 @@ config HID_HOLTEK
tristate "Holtek HID devices"
depends on USB_HID
help
- Support for Holtek based devices:
- - Holtek On Line Grip based game controller
- - Trust GXT 18 Gaming Keyboard
- - Sharkoon Drakonia / Perixx MX-2000 gaming mice
- - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
- Zalman ZM-GM1
- - SHARKOON DarkGlider Gaming mouse
- - LEETGION Hellion Gaming Mouse
+ Support for Holtek based devices:
+ - Holtek On Line Grip based game controller
+ - Trust GXT 18 Gaming Keyboard
+ - Sharkoon Drakonia / Perixx MX-2000 gaming mice
+ - Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
+ Zalman ZM-GM1
+ - SHARKOON DarkGlider Gaming mouse
+ - LEETGION Hellion Gaming Mouse
config HOLTEK_FF
bool "Holtek On Line Grip force feedback support"
@@ -452,14 +452,14 @@ config HID_GOOGLE_HAMMER
select INPUT_VIVALDIFMAP
depends on USB_HID && LEDS_CLASS && CROS_EC
help
- Say Y here if you have a Google Hammer device.
+ Say Y here if you have a Google Hammer device.
config HID_GOOGLE_STADIA_FF
tristate "Google Stadia force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Google
- Stadia controller.
+ Say Y here if you want to enable force feedback support for the Google
+ Stadia controller.
config HID_VIVALDI
tristate "Vivaldi Keyboard"
@@ -475,51 +475,51 @@ config HID_GT683R
tristate "MSI GT68xR LED support"
depends on LEDS_CLASS && USB_HID
help
- Say Y here if you want to enable support for the three MSI GT68xR LEDs
+ Say Y here if you want to enable support for the three MSI GT68xR LEDs
- This driver support following modes:
- - Normal: LEDs are fully on when enabled
- - Audio: LEDs brightness depends on sound level
- - Breathing: LEDs brightness varies at human breathing rate
+ This driver support following modes:
+ - Normal: LEDs are fully on when enabled
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
- Currently the following devices are know to be supported:
- - MSI GT683R
+ Currently the following devices are know to be supported:
+ - MSI GT683R
config HID_KEYTOUCH
tristate "Keytouch HID devices"
help
- Support for Keytouch HID devices not fully compliant with
- the specification. Currently supported:
+ Support for Keytouch HID devices not fully compliant with
+ the specification. Currently supported:
- Keytouch IEC 60945
config HID_KYE
tristate "KYE/Genius devices"
help
- Support for KYE/Genius devices not fully compliant with HID standard:
- - Ergo Mouse
- - EasyPen i405X tablet
- - MousePen i608X tablet
- - EasyPen M610X tablet
+ Support for KYE/Genius devices not fully compliant with HID standard:
+ - Ergo Mouse
+ - EasyPen i405X tablet
+ - MousePen i608X tablet
+ - EasyPen M610X tablet
config HID_KYSONA
tristate "Kysona devices"
depends on USB_HID
help
- Support for Kysona mice.
+ Support for Kysona mice.
- Say Y here if you have a Kysona M600 mouse
- and want to be able to read its battery capacity.
+ Say Y here if you have a Kysona M600 mouse
+ and want to be able to read its battery capacity.
config HID_UCLOGIC
tristate "UC-Logic"
depends on USB_HID
help
- Support for UC-Logic and Huion tablets.
+ Support for UC-Logic and Huion tablets.
config HID_WALTOP
tristate "Waltop"
help
- Support for Waltop tablets.
+ Support for Waltop tablets.
config HID_VIEWSONIC
tristate "ViewSonic/Signotec"
@@ -530,11 +530,11 @@ config HID_VRC2
tristate "VRC-2 Car Controller"
depends on HID
help
- Support for VRC-2 which is a 2-axis controller often used in
- car simulators.
+ Support for VRC-2 which is a 2-axis controller often used in
+ car simulators.
- To compile this driver as a module, choose M here: the
- module will be called hid-vrc2.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-vrc2.
config HID_XIAOMI
tristate "Xiaomi"
@@ -545,95 +545,95 @@ config HID_XIAOMI
config HID_GYRATION
tristate "Gyration remote control"
help
- Support for Gyration remote control.
+ Support for Gyration remote control.
config HID_ICADE
tristate "ION iCade arcade controller"
help
- Support for the ION iCade arcade controller to work as a joystick.
+ Support for the ION iCade arcade controller to work as a joystick.
- To compile this driver as a module, choose M here: the
- module will be called hid-icade.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-icade.
config HID_ITE
tristate "ITE devices"
help
- Support for ITE devices not fully compliant with HID standard.
+ Support for ITE devices not fully compliant with HID standard.
config HID_JABRA
tristate "Jabra USB HID Driver"
help
- Support for Jabra USB HID devices.
+ Support for Jabra USB HID devices.
- Prevents mapping of vendor defined HID usages to input events. Without
- this driver HID reports from Jabra devices may incorrectly be seen as
- mouse button events.
- Say M here if you may ever plug in a Jabra USB device.
+ Prevents mapping of vendor defined HID usages to input events. Without
+ this driver HID reports from Jabra devices may incorrectly be seen as
+ mouse button events.
+ Say M here if you may ever plug in a Jabra USB device.
config HID_TWINHAN
tristate "Twinhan IR remote control"
help
- Support for Twinhan IR remote control.
+ Support for Twinhan IR remote control.
config HID_KENSINGTON
tristate "Kensington Slimblade Trackball"
help
- Support for Kensington Slimblade Trackball.
+ Support for Kensington Slimblade Trackball.
config HID_LCPOWER
tristate "LC-Power"
help
- Support for LC-Power RC1000MCE RF remote control.
+ Support for LC-Power RC1000MCE RF remote control.
config HID_LED
tristate "Simple RGB LED support"
depends on LEDS_CLASS
help
- Support for simple RGB LED devices. Currently supported are:
- - Riso Kagaku Webmail Notifier
- - Dream Cheeky Webmail Notifier and Friends Alert
- - ThingM blink(1)
- - Delcom Visual Signal Indicator Generation 2
- - Greynut Luxafor
+ Support for simple RGB LED devices. Currently supported are:
+ - Riso Kagaku Webmail Notifier
+ - Dream Cheeky Webmail Notifier and Friends Alert
+ - ThingM blink(1)
+ - Delcom Visual Signal Indicator Generation 2
+ - Greynut Luxafor
- To compile this driver as a module, choose M here: the
- module will be called hid-led.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-led.
config HID_LENOVO
tristate "Lenovo / Thinkpad devices"
depends on LEDS_CLASS
help
- Support for IBM/Lenovo devices that are not fully compliant with HID standard.
+ Support for IBM/Lenovo devices that are not fully compliant with HID standard.
- Say Y if you want support for horizontal scrolling of the IBM/Lenovo
- Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
- standalone keyboards, e.g:
- - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
- configuration)
- - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
- - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
+ Say Y if you want support for horizontal scrolling of the IBM/Lenovo
+ Scrollpoint mice or the non-compliant features of the Lenovo Thinkpad
+ standalone keyboards, e.g:
+ - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
+ configuration)
+ - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
+ - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
config HID_LENOVO_GO
tristate "HID Driver for Lenovo Legion Go Series Controllers"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go devices with detachable controllers.
+ Support for Lenovo Legion Go devices with detachable controllers.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- and Legion Go 2 Handheld Console Controllers. Say M here to compile this
- driver as a module. The module will be called hid-lenovo-go.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ and Legion Go 2 Handheld Console Controllers. Say M here to compile this
+ driver as a module. The module will be called hid-lenovo-go.
config HID_LENOVO_GO_S
tristate "HID Driver for Lenovo Legion Go S Controller"
depends on USB_HID
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Lenovo Legion Go S Handheld Console Controller.
+ Support for Lenovo Legion Go S Handheld Console Controller.
- Say Y here to include configuration interface support for the Lenovo Legion Go
- S. Say M here to compile this driver as a module. The module will be called
- hid-lenovo-go-s.
+ Say Y here to include configuration interface support for the Lenovo Legion Go
+ S. Say M here to compile this driver as a module. The module will be called
+ hid-lenovo-go-s.
config HID_LETSKETCH
tristate "Letsketch WP9620N tablets"
@@ -655,7 +655,7 @@ config HID_LOGITECH
depends on LEDS_CLASS
depends on LEDS_CLASS_MULTICOLOR
help
- Support for Logitech devices that are not fully compliant with HID standard.
+ Support for Logitech devices that are not fully compliant with HID standard.
config HID_LOGITECH_DJ
tristate "Logitech receivers full support"
@@ -664,23 +664,23 @@ config HID_LOGITECH_DJ
depends on HID_LOGITECH
select HID_LOGITECH_HIDPP
help
- Say Y if you want support for Logitech receivers and devices.
- Logitech receivers are capable of pairing multiple Logitech compliant
- devices to the same receiver. Without this driver it will be handled by
- generic USB_HID driver and all incoming events will be multiplexed
- into a single mouse and a single keyboard device.
+ Say Y if you want support for Logitech receivers and devices.
+ Logitech receivers are capable of pairing multiple Logitech compliant
+ devices to the same receiver. Without this driver it will be handled by
+ generic USB_HID driver and all incoming events will be multiplexed
+ into a single mouse and a single keyboard device.
config HID_LOGITECH_HIDPP
tristate "Logitech HID++ devices support"
depends on HID_LOGITECH
select POWER_SUPPLY
help
- Support for Logitech devices relying on the HID++ Logitech specification
+ Support for Logitech devices relying on the HID++ Logitech specification
- Say Y if you want support for Logitech devices relying on the HID++
- specification. Such devices are the various Logitech Touchpads (T650,
- T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
- Keyboard).
+ Say Y if you want support for Logitech devices relying on the HID++
+ specification. Such devices are the various Logitech Touchpads (T650,
+ T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
+ Keyboard).
config LOGITECH_FF
bool "Logitech force feedback support"
@@ -740,31 +740,31 @@ config LOGIWHEELS_FF
config HID_MAGICMOUSE
tristate "Apple Magic Mouse/Trackpad multi-touch support"
help
- Support for the Apple Magic Mouse/Trackpad multi-touch.
+ Support for the Apple Magic Mouse/Trackpad multi-touch.
- Say Y here if you want support for the multi-touch features of the
- Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
+ Say Y here if you want support for the multi-touch features of the
+ Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
config HID_MALTRON
tristate "Maltron L90 keyboard"
help
- Adds support for the volume up, volume down, mute, and play/pause buttons
- of the Maltron L90 keyboard.
+ Adds support for the volume up, volume down, mute, and play/pause buttons
+ of the Maltron L90 keyboard.
config HID_MAYFLASH
tristate "Mayflash game controller adapter force feedback"
select INPUT_FF_MEMLESS
help
- Say Y here if you have HJZ Mayflash PS3 game controller adapters
- and want to enable force feedback support.
+ Say Y here if you have HJZ Mayflash PS3 game controller adapters
+ and want to enable force feedback support.
config HID_MEGAWORLD_FF
tristate "Mega World based game controller force feedback support"
depends on USB_HID
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Mega World based game controller and want
- to have force feedback support for it.
+ Say Y here if you have a Mega World based game controller and want
+ to have force feedback support for it.
config HID_RAKK
tristate "Rakk support"
@@ -778,18 +778,18 @@ config HID_RAKK
config HID_REDRAGON
tristate "Redragon keyboards"
help
- Support for Redragon keyboards that need fix-ups to work properly.
+ Support for Redragon keyboards that need fix-ups to work properly.
config HID_MICROSOFT
tristate "Microsoft non-fully HID-compliant devices"
select INPUT_FF_MEMLESS
help
- Support for Microsoft devices that are not fully compliant with HID standard.
+ Support for Microsoft devices that are not fully compliant with HID standard.
config HID_MONTEREY
tristate "Monterey Genius KB29E keyboard"
help
- Support for Monterey Genius KB29E.
+ Support for Monterey Genius KB29E.
config HID_MULTITOUCH
tristate "HID Multitouch panels"
@@ -843,35 +843,35 @@ config HID_NINTENDO
depends on LEDS_CLASS
select POWER_SUPPLY
help
- Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
- All controllers support bluetooth, and the Pro Controller also supports
- its USB mode. This also includes support for the Nintendo Switch Online
- Controllers which include the NES, Genesis, SNES, and N64 controllers.
+ Adds support for the Nintendo Switch Joy-Cons, NSO, Pro Controller.
+ All controllers support bluetooth, and the Pro Controller also supports
+ its USB mode. This also includes support for the Nintendo Switch Online
+ Controllers which include the NES, Genesis, SNES, and N64 controllers.
- To compile this driver as a module, choose M here: the
- module will be called hid-nintendo.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-nintendo.
config NINTENDO_FF
bool "Nintendo Switch controller force feedback support"
depends on HID_NINTENDO
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Nintendo Switch controller and want to enable
- force feedback support for it. This works for both joy-cons, the pro
- controller, and the NSO N64 controller. For the pro controller, both
- rumble motors can be controlled individually.
+ Say Y here if you have a Nintendo Switch controller and want to enable
+ force feedback support for it. This works for both joy-cons, the pro
+ controller, and the NSO N64 controller. For the pro controller, both
+ rumble motors can be controlled individually.
config HID_NTI
tristate "NTI keyboard adapters"
help
- Support for the "extra" Sun keyboard keys on keyboards attached
- through Network Technologies USB-SUN keyboard adapters.
+ Support for the "extra" Sun keyboard keys on keyboards attached
+ through Network Technologies USB-SUN keyboard adapters.
config HID_NTRIG
tristate "N-Trig touch screen"
depends on USB_HID
help
- Support for N-Trig touch screen.
+ Support for N-Trig touch screen.
config HID_NVIDIA_SHIELD
tristate "NVIDIA SHIELD devices"
@@ -896,14 +896,14 @@ config NVIDIA_SHIELD_FF
config HID_ORTEK
tristate "Ortek PKB-1700/WKB-2000/Skycable wireless keyboard and mouse trackpad"
help
- There are certain devices which have LogicalMaximum wrong in the keyboard
- usage page of their report descriptor. The most prevailing ones so far
- are manufactured by Ortek, thus the name of the driver. Currently
- supported devices by this driver are
+ There are certain devices which have LogicalMaximum wrong in the keyboard
+ usage page of their report descriptor. The most prevailing ones so far
+ are manufactured by Ortek, thus the name of the driver. Currently
+ supported devices by this driver are
- - Ortek PKB-1700
- - Ortek WKB-2000
- - Skycable wireless presenter
+ - Ortek PKB-1700
+ - Ortek WKB-2000
+ - Skycable wireless presenter
config HID_OXP
tristate "OneXPlayer handheld controller configuration support"
@@ -946,7 +946,7 @@ config HID_PENMOUNT
config HID_PETALYNX
tristate "Petalynx Maxter remote control"
help
- Support for Petalynx Maxter remote control.
+ Support for Petalynx Maxter remote control.
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
@@ -1038,77 +1038,77 @@ config PLAYSTATION_FF
PlayStation game controllers.
config HID_PXRC
- tristate "PhoenixRC HID Flight Controller"
- depends on HID
- help
- Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
+ tristate "PhoenixRC HID Flight Controller"
+ depends on HID
+ help
+ Support for PhoenixRC HID Flight Controller, a 8-axis flight controller.
- To compile this driver as a module, choose M here: the
- module will be called hid-pxrc.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-pxrc.
config HID_RAPOO
tristate "Rapoo non-fully HID-compliant devices"
help
- Support for Rapoo devices that are not fully compliant with the
- HID standard.
+ Support for Rapoo devices that are not fully compliant with the
+ HID standard.
config HID_RAZER
tristate "Razer non-fully HID-compliant devices"
help
- Support for Razer devices that are not fully compliant with the
- HID standard.
+ Support for Razer devices that are not fully compliant with the
+ HID standard.
config HID_PRIMAX
tristate "Primax non-fully HID-compliant devices"
help
- Support for Primax devices that are not fully compliant with the
- HID standard.
+ Support for Primax devices that are not fully compliant with the
+ HID standard.
config HID_RETRODE
tristate "Retrode 2 USB adapter for vintage video games"
depends on USB_HID
help
- Support for
- * Retrode 2 cartridge and controller adapter
+ Support for
+ * Retrode 2 cartridge and controller adapter
config HID_ROCCAT
tristate "Roccat device support"
depends on USB_HID
help
- Support for Roccat devices.
- Say Y here if you have a Roccat mouse or keyboard and want
- support for its special functionalities.
+ Support for Roccat devices.
+ Say Y here if you have a Roccat mouse or keyboard and want
+ support for its special functionalities.
config HID_SAITEK
tristate "Saitek (Mad Catz) non-fully HID-compliant devices"
help
- Support for Saitek devices that are not fully compliant with the
- HID standard.
+ Support for Saitek devices that are not fully compliant with the
+ HID standard.
- Supported devices:
- - PS1000 Dual Analog Pad
- - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
- - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
+ Supported devices:
+ - PS1000 Dual Analog Pad
+ - Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
+ - Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
config HID_SAMSUNG
tristate "Samsung InfraRed remote control or keyboards"
depends on USB_HID
help
- Support for Samsung InfraRed remote control or keyboards.
+ Support for Samsung InfraRed remote control or keyboards.
config HID_SEMITEK
tristate "Semitek USB keyboards"
help
- Support for Semitek USB keyboards that are not fully compliant
- with the HID standard.
+ Support for Semitek USB keyboards that are not fully compliant
+ with the HID standard.
- There are many variants, including:
- - GK61, GK64, GK68, GK84, GK96, etc.
- - SK61, SK64, SK68, SK84, SK96, etc.
- - Dierya DK61/DK66
- - Tronsmart TK09R
- - Woo-dy
- - X-Bows Nature/Knight
+ There are many variants, including:
+ - GK61, GK64, GK68, GK84, GK96, etc.
+ - SK61, SK64, SK68, SK84, SK96, etc.
+ - Dierya DK61/DK66
+ - Tronsmart TK09R
+ - Woo-dy
+ - X-Bows Nature/Knight
config HID_SIGMAMICRO
tristate "SiGma Micro-based keyboards"
@@ -1128,58 +1128,58 @@ config HID_SONY
select POWER_SUPPLY
select CRC32
help
- Support for
+ Support for
- * Sixaxis controllers for PS3
- * Buzz controllers
- * Blu-ray Disc Remote Control for PS3
- * Logitech Harmony adapter for PS3
- * Guitar Hero Live PS3, Wii U and PS4 guitars
- * Guitar Hero PS3 and PC guitars
- * Rock Band 1, 2 and 3 PS3 and Wii instruments
- * Rock Band 4 PS4 and PS5 guitars
- * DJ Hero Turntable for PS3
+ * Sixaxis controllers for PS3
+ * Buzz controllers
+ * Blu-ray Disc Remote Control for PS3
+ * Logitech Harmony adapter for PS3
+ * Guitar Hero Live PS3, Wii U and PS4 guitars
+ * Guitar Hero PS3 and PC guitars
+ * Rock Band 1, 2 and 3 PS3 and Wii instruments
+ * Rock Band 4 PS4 and PS5 guitars
+ * DJ Hero Turntable for PS3
config SONY_FF
bool "Sony PS2/3/4 accessories force feedback support"
depends on HID_SONY
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Sony PS2/3/4 accessory and want to enable
- force feedback support for it.
+ Say Y here if you have a Sony PS2/3/4 accessory and want to enable
+ force feedback support for it.
config HID_SPEEDLINK
tristate "Speedlink VAD Cezanne mouse support"
help
- Support for Speedlink Vicious and Divine Cezanne mouse.
+ Support for Speedlink Vicious and Divine Cezanne mouse.
config HID_STEAM
tristate "Steam Controller/Deck support"
select POWER_SUPPLY
help
- Say Y here if you have a Steam Controller or Deck if you want to use it
- without running the Steam Client. It supports both the wired and
- the wireless adaptor.
+ Say Y here if you have a Steam Controller or Deck if you want to use it
+ without running the Steam Client. It supports both the wired and
+ the wireless adaptor.
config STEAM_FF
bool "Steam Deck force feedback support"
depends on HID_STEAM
select INPUT_FF_MEMLESS
help
- Say Y here if you want to enable force feedback support for the Steam
- Deck.
+ Say Y here if you want to enable force feedback support for the Steam
+ Deck.
config HID_STEELSERIES
tristate "Steelseries devices support"
depends on USB_HID
help
- Support for Steelseries SRW-S1 steering wheel, and the Steelseries
- Arctis 1 Wireless for XBox headset.
+ Support for Steelseries SRW-S1 steering wheel, and the Steelseries
+ Arctis 1 Wireless for XBox headset.
config HID_SUNPLUS
tristate "Sunplus wireless desktop"
help
- Support for Sunplus wireless desktop.
+ Support for Sunplus wireless desktop.
config HID_RMI
tristate "Synaptics RMI4 device support"
@@ -1190,9 +1190,9 @@ config HID_RMI
select RMI4_F30
select RMI4_F3A
help
- Support for Synaptics RMI4 touchpads.
- Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Synaptics RMI4 touchpads.
+ Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_GREENASIA
tristate "GreenAsia (Product ID 0x12) game controller support"
@@ -1205,59 +1205,59 @@ config GREENASIA_FF
depends on HID_GREENASIA
select INPUT_FF_MEMLESS
help
- Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
- (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
- and want to enable force feedback support for it.
+ Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
+ (like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
+ and want to enable force feedback support for it.
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
depends on HYPERV_VMBUS
help
- Select this option to enable the Hyper-V mouse driver.
+ Select this option to enable the Hyper-V mouse driver.
config HID_SMARTJOYPLUS
tristate "SmartJoy PLUS PS2/USB adapter support"
help
- Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
- Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
+ Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
+ Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
- Note that DDR (Dance Dance Revolution) mode is not supported, nor
- is pressure sensitive buttons on the pro models.
+ Note that DDR (Dance Dance Revolution) mode is not supported, nor
+ is pressure sensitive buttons on the pro models.
config SMARTJOYPLUS_FF
bool "SmartJoy PLUS PS2/USB adapter force feedback support"
depends on HID_SMARTJOYPLUS
select INPUT_FF_MEMLESS
help
- Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
- enable force feedback support for it.
+ Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
+ enable force feedback support for it.
config HID_TIVO
tristate "TiVo Slide Bluetooth remote control support"
help
- Say Y if you have a TiVo Slide Bluetooth remote control.
+ Say Y if you have a TiVo Slide Bluetooth remote control.
config HID_TOPSEED
tristate "TopSeed Cyberlink, BTC Emprex, Conceptronic remote control support"
help
- Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
- CLLRCMCE remote control.
+ Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
+ CLLRCMCE remote control.
config HID_TOPRE
tristate "Topre REALFORCE keyboards"
depends on HID
help
Say Y for N-key rollover support on Topre REALFORCE R2 108/87 key and
- Topre REALFORCE R3S 87 key keyboards.
+ Topre REALFORCE R3S 87 key keyboards.
config HID_THINGM
tristate "ThingM blink(1) USB RGB LED"
depends on LEDS_CLASS
select HID_LED
help
- Support for the ThingM blink(1) USB RGB LED. This driver has been
- merged into the generic hid led driver. Config symbol HID_THINGM
- just selects HID_LED and will be removed soon.
+ Support for the ThingM blink(1) USB RGB LED. This driver has been
+ merged into the generic hid led driver. Config symbol HID_THINGM
+ just selects HID_LED and will be removed soon.
config HID_THRUSTMASTER
tristate "ThrustMaster devices support"
@@ -1332,23 +1332,23 @@ config HID_WIIMOTE
select POWER_SUPPLY
select INPUT_FF_MEMLESS
help
- Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
- devices are the Wii Remote and its extension devices, but also devices
- based on the Wii Remote like the Wii U Pro Controller or the
- Wii Balance Board.
+ Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
+ devices are the Wii Remote and its extension devices, but also devices
+ based on the Wii Remote like the Wii U Pro Controller or the
+ Wii Balance Board.
- Support for all official Nintendo extensions is available, however, 3rd
- party extensions might not be supported. Please report these devices to:
+ Support for all official Nintendo extensions is available, however, 3rd
+ party extensions might not be supported. Please report these devices to:
http://github.com/dvdhrm/xwiimote/issues
- Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
- the Wii U Gamepad) might be supported in the future. But currently
- support is limited to Bluetooth based devices.
+ Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
+ the Wii U Gamepad) might be supported in the future. But currently
+ support is limited to Bluetooth based devices.
- If unsure, say N.
+ If unsure, say N.
- To compile this driver as a module, choose M here: the
- module will be called hid-wiimote.
+ To compile this driver as a module, choose M here: the
+ module will be called hid-wiimote.
config HID_WINWING
tristate "WinWing Orion2 throttle support"
@@ -1371,9 +1371,9 @@ config HID_WINWING
config HID_XINMO
tristate "Xin-Mo non-fully compliant devices"
help
- Support for Xin-Mo devices that are not fully compliant with the HID
- standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
- if you have a Xin-Mo Dual Arcade controller.
+ Support for Xin-Mo devices that are not fully compliant with the HID
+ standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
+ if you have a Xin-Mo Dual Arcade controller.
config HID_ZEROPLUS
tristate "Zeroplus based game controller support"
@@ -1391,7 +1391,7 @@ config ZEROPLUS_FF
config HID_ZYDACRON
tristate "Zydacron remote control support"
help
- Support for Zydacron remote control.
+ Support for Zydacron remote control.
config HID_SENSOR_HUB
tristate "HID Sensors framework support"
@@ -1425,9 +1425,9 @@ config HID_SENSOR_CUSTOM_SENSOR
config HID_ALPS
tristate "Alps HID device support"
help
- Support for Alps I2C HID touchpads and StickPointer.
- Say Y here if you have a Alps touchpads over i2c-hid or usbhid
- and want support for its special functionalities.
+ Support for Alps I2C HID touchpads and StickPointer.
+ Say Y here if you have a Alps touchpads over i2c-hid or usbhid
+ and want support for its special functionalities.
config HID_MCP2200
tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
@@ -1444,11 +1444,11 @@ config HID_MCP2221
imply GPIOLIB
imply IIO
help
- Provides I2C and SMBUS host adapter functionality over USB-HID
- through MCP2221 device.
+ Provides I2C and SMBUS host adapter functionality over USB-HID
+ through MCP2221 device.
- To compile this driver as a module, choose M here: the module
- will be called hid-mcp2221.ko.
+ To compile this driver as a module, choose M here: the module
+ will be called hid-mcp2221.ko.
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, arnd, brgl, andrew, sebastian.hesselbarth,
gregory.clement, Frank.Li, robert.jarzmik, krzk, gerg, tsbogend,
hauke, zajec5, ysato, glaubitz, linusw, dmitry.torokhov, kuba,
pabeni, linux, linux-kernel, linux-arm-kernel, linux-samsung-soc,
patches, linux-m68k, linux-mips, linux-sh, linux-input,
linux-media, netdev, linux-sunxi, linux-phy, linux-rockchip,
linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 15:26:20 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> [...]
Here is the summary with links:
- [01/13] ARM: replace linux/gpio.h inclusions
(no matching commit)
- [02/13] m68k/coldfire: replace linux/gpio.h inclusions
(no matching commit)
- [03/13] mips: replace linux/gpio.h inclusions
(no matching commit)
- [04/13] sh: replace linux/gpio.h inclusions
(no matching commit)
- [05/13] mfd: replace linux/gpio.h inclusions
(no matching commit)
- [06/13,net-next] net: replace linux/gpio.h inclusions
https://git.kernel.org/netdev/net-next/c/a53d1872f2be
- [07/13] ASoC: replace linux/gpio.h inclusions
(no matching commit)
- [08/13] pcmcia: replace linux/gpio.h inclusions
(no matching commit)
- [09/13] phy: replace linux/gpio.h inclusions
(no matching commit)
- [10/13] media: replace linux/gpio.h inclusions
(no matching commit)
- [11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
(no matching commit)
- [12/13] gpib: gpio: replace linux/gpio.h inclusion
(no matching commit)
- [13/13] gpiolib: remove linux/gpio.h
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH 0/3] HID: Intel-thc-hid: Refine error recovery flow
From: Even Xu @ 2026-07-01 2:04 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
This series refines the fatal error recovery flow for the Intel THC
(Touch Host Controller) subsystem, covering both the QuickI2C and
QuickSPI drivers.
Currently, when a fatal DMA error is detected in the IRQ thread handler,
the recovery is performed inline: the interrupt handler calls
try_recover() directly, which unconfigures and reconfigures the DMA
engine.
This approach has several problems:
1. Recovery runs in the IRQ thread context, which is not ideal for
potentially slow reset operations.
2. The interrupt is re-enabled before recovery completes, risking an
interrupt storm if DMA errors persist.
3. The DMA reset logic is open-coded in each protocol driver, leading
to duplication and divergence over time.
This patch series addresses all of the above:
By adding a new thc_rxdma_reset() API to the THC core layer, QuickI2C
and QuickSPI drivers can call it respectively to refine the recovery
callback.
The synchronous try_recover() call in the IRQ thread is replaced with
schedule_work(), deferring recovery to a workqueue. Within the work
function:
- The interrupt line is disabled before any DMA manipulation.
- thc_rxdma_reset() is used instead of the open-coded sequence.
- On failure the device is marked DISABLED and the interrupt remains
off, preventing an interrupt storm.
Even Xu (3):
HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
HID: Intel-thc-hid: Intel-quickspi: Refine recover callback
.../intel-quicki2c/pci-quicki2c.c | 31 +++++++---------
.../intel-quicki2c/quicki2c-dev.h | 2 +
.../intel-quickspi/pci-quickspi.c | 37 +++++++------------
.../intel-quickspi/quickspi-dev.h | 2 +
.../intel-thc-hid/intel-thc/intel-thc-dma.c | 37 +++++++++++++++++++
.../intel-thc-hid/intel-thc/intel-thc-dma.h | 1 +
6 files changed, 68 insertions(+), 42 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/3] HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
From: Even Xu @ 2026-07-01 2:04 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
In-Reply-To: <20260701020432.3774514-1-even.xu@intel.com>
Add a helper function thc_rxdam_reset() to do read DMA reset, it can be
called when fatal DMA error happens.
Signed-off-by: Even Xu <even.xu@intel.com>
---
.../intel-thc-hid/intel-thc/intel-thc-dma.c | 37 +++++++++++++++++++
.../intel-thc-hid/intel-thc/intel-thc-dma.h | 1 +
2 files changed, 38 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
index 6ee675e0a738..d771c85dff28 100644
--- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
+++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
@@ -532,6 +532,43 @@ void thc_dma_unconfigure(struct thc_device *dev)
}
EXPORT_SYMBOL_NS_GPL(thc_dma_unconfigure, "INTEL_THC");
+/**
+ * thc_rxdma_reset - Reset all read DMA engines
+ *
+ * @dev: The pointer of THC private device context
+ *
+ * This is a helper function to reset RxDMA configure. It's typically used
+ * for RxDMA recovery when fatal error happens.
+ */
+int thc_rxdma_reset(struct thc_device *dev)
+{
+ int ret;
+
+ if (mutex_lock_interruptible(&dev->thc_bus_lock))
+ return -EINTR;
+
+ ret = thc_interrupt_quiesce(dev, true);
+ if (ret) {
+ dev_err_once(dev->dev, "Quiesce interrupt failed during RxDMA reset\n");
+ goto end;
+ }
+
+ thc_dma_unconfigure(dev);
+
+ ret = thc_dma_configure(dev);
+ if (ret) {
+ dev_err_once(dev->dev, "Re-config DMA failed during RxDMA reset\n");
+ goto end;
+ }
+
+ thc_interrupt_quiesce(dev, false);
+
+end:
+ mutex_unlock(&dev->thc_bus_lock);
+ return ret;
+}
+EXPORT_SYMBOL_NS_GPL(thc_rxdma_reset, "INTEL_THC");
+
static int thc_wait_for_dma_pause(struct thc_device *dev, enum thc_dma_channel channel)
{
u32 ctrl_reg, sts_reg, sts;
diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.h b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.h
index 541d33995baf..715423453a9d 100644
--- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.h
+++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.h
@@ -145,6 +145,7 @@ int thc_dma_allocate(struct thc_device *dev);
int thc_dma_configure(struct thc_device *dev);
void thc_dma_unconfigure(struct thc_device *dev);
void thc_dma_release(struct thc_device *dev);
+int thc_rxdma_reset(struct thc_device *dev);
int thc_rxdma_read(struct thc_device *dev, enum thc_dma_channel dma_channel,
void *read_buff, size_t *read_len, int *read_finished);
int thc_swdma_read(struct thc_device *dev, void *write_buff, size_t write_len,
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
From: Even Xu @ 2026-07-01 2:04 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
In-Reply-To: <20260701020432.3774514-1-even.xu@intel.com>
Refine recover flow:
1. Use workqueue to handle recover flow instead of processing in irq
handler.
2. Call thc_rxdma_reset() API to simplify the recover operation.
3. Disable interrupt during whole recover flow.
4. If recover fails, disable interrupt to avoid interrupt storm.
Signed-off-by: Even Xu <even.xu@intel.com>
---
.../intel-quicki2c/pci-quicki2c.c | 31 ++++++++-----------
.../intel-quicki2c/quicki2c-dev.h | 2 ++
2 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index 46d3e9a01999..411d7a0ab90e 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -245,28 +245,23 @@ static irqreturn_t quicki2c_irq_quick_handler(int irq, void *dev_id)
}
/**
- * try_recover - Try to recovery THC and Device
- * @qcdev: Pointer to quicki2c_device structure
+ * try_recover - Recover callback to recover THC
+ * @work: pointer to work_struct
*
* This function is an error handler, called when fatal error happens.
- * It try to reset touch device and re-configure THC to recovery
- * communication between touch device and THC.
- *
- * Return: 0 if successful or error code on failure
+ * It try to reset Touch Device and re-configure THC to recover
+ * transferring between Device and THC.
*/
-static int try_recover(struct quicki2c_device *qcdev)
+static void try_recover(struct work_struct *work)
{
- int ret;
+ struct quicki2c_device *qcdev = container_of(work, struct quicki2c_device, recover_work);
- thc_dma_unconfigure(qcdev->thc_hw);
-
- ret = thc_dma_configure(qcdev->thc_hw);
- if (ret) {
- dev_err(qcdev->dev, "Reconfig DMA failed\n");
- return ret;
- }
+ thc_interrupt_enable(qcdev->thc_hw, false);
- return 0;
+ if (thc_rxdma_reset(qcdev->thc_hw))
+ qcdev->state = QUICKI2C_DISABLED;
+ else
+ thc_interrupt_enable(qcdev->thc_hw, true);
}
static int handle_input_report(struct quicki2c_device *qcdev)
@@ -346,8 +341,7 @@ static irqreturn_t quicki2c_irq_thread_handler(int irq, void *dev_id)
thc_interrupt_enable(qcdev->thc_hw, true);
if (err_recover)
- if (try_recover(qcdev))
- qcdev->state = QUICKI2C_DISABLED;
+ schedule_work(&qcdev->recover_work);
pm_runtime_put_autosuspend(qcdev->dev);
@@ -386,6 +380,7 @@ static struct quicki2c_device *quicki2c_dev_init(struct pci_dev *pdev, void __io
qcdev->ddata = ddata;
init_waitqueue_head(&qcdev->reset_ack_wq);
+ INIT_WORK(&qcdev->recover_work, try_recover);
/* THC hardware init */
qcdev->thc_hw = thc_dev_init(qcdev->dev, qcdev->mem_addr);
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
index 61dbdece59a1..aedf85291e60 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
@@ -222,6 +222,8 @@ struct quicki2c_device {
wait_queue_head_t reset_ack_wq;
bool reset_ack;
+ struct work_struct recover_work;
+
u32 i2c_max_frame_size_enable;
u32 i2c_max_frame_size;
u32 i2c_int_delay_enable;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/3] HID: Intel-thc-hid: Intel-quickspi: Refine recover callback
From: Even Xu @ 2026-07-01 2:04 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
In-Reply-To: <20260701020432.3774514-1-even.xu@intel.com>
Refine recover flow:
1. Use workqueue to handle recover flow instead of processing in irq
handler.
2. Call thc_rxdma_reset() API to simplify the recover operation.
3. Disable interrupt during whole recover flow.
4. If recover fails, disable interrupt to avoid interrupt storm.
Signed-off-by: Even Xu <even.xu@intel.com>
---
.../intel-quickspi/pci-quickspi.c | 37 +++++++------------
.../intel-quickspi/quickspi-dev.h | 2 +
2 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index f669235f1883..1e63b183b3b1 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -252,34 +252,23 @@ static irqreturn_t quickspi_irq_quick_handler(int irq, void *dev_id)
}
/**
- * try_recover - Try to recovery THC and Device
- * @qsdev: pointer to quickspi device
+ * try_recover - Recover callback to recover THC
+ * @work: pointer to work_struct
*
- * This function is a error handler, called when fatal error happens.
- * It try to reset Touch Device and re-configure THC to recovery
+ * This function is an error handler, called when fatal error happens.
+ * It try to reset Touch Device and re-configure THC to recover
* transferring between Device and THC.
- *
- * Return: 0 if successful or error code on failed.
*/
-static int try_recover(struct quickspi_device *qsdev)
+static void try_recover(struct work_struct *work)
{
- int ret;
+ struct quickspi_device *qsdev = container_of(work, struct quickspi_device, recover_work);
- ret = reset_tic(qsdev);
- if (ret) {
- dev_err(qsdev->dev, "Reset touch device failed, ret = %d\n", ret);
- return ret;
- }
-
- thc_dma_unconfigure(qsdev->thc_hw);
-
- ret = thc_dma_configure(qsdev->thc_hw);
- if (ret) {
- dev_err(qsdev->dev, "Re-configure THC DMA failed, ret = %d\n", ret);
- return ret;
- }
+ thc_interrupt_enable(qsdev->thc_hw, false);
- return 0;
+ if (thc_rxdma_reset(qsdev->thc_hw))
+ qsdev->state = QUICKSPI_DISABLED;
+ else
+ thc_interrupt_enable(qsdev->thc_hw, true);
}
/**
@@ -340,8 +329,7 @@ static irqreturn_t quickspi_irq_thread_handler(int irq, void *dev_id)
thc_interrupt_enable(qsdev->thc_hw, true);
if (err_recover)
- if (try_recover(qsdev))
- qsdev->state = QUICKSPI_DISABLED;
+ schedule_work(&qsdev->recover_work);
pm_runtime_put_autosuspend(qsdev->dev);
@@ -385,6 +373,7 @@ static struct quickspi_device *quickspi_dev_init(struct pci_dev *pdev, void __io
init_waitqueue_head(&qsdev->report_desc_got_wq);
init_waitqueue_head(&qsdev->get_report_cmpl_wq);
init_waitqueue_head(&qsdev->set_report_cmpl_wq);
+ INIT_WORK(&qsdev->recover_work, try_recover);
/* thc hw init */
qsdev->thc_hw = thc_dev_init(qsdev->dev, qsdev->mem_addr);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
index bf5e18f5a5f4..b0c1219866a4 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
@@ -173,6 +173,8 @@ struct quickspi_device {
wait_queue_head_t set_report_cmpl_wq;
bool set_report_cmpl;
+
+ struct work_struct recover_work;
};
#endif /* _QUICKSPI_DEV_H_ */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/3] HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
From: sashiko-bot @ 2026-07-01 2:15 UTC (permalink / raw)
To: Even Xu; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260701020432.3774514-3-even.xu@intel.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing cancellation of the scheduled asynchronous recovery work during device removal and shutdown leads to a Use-After-Free.
- [High] Unconditionally re-enabling hardware interrupts before the asynchronous recovery completes causes an immediate interrupt storm.
- [High] The deferred `try_recover` work function accesses hardware registers directly without acquiring a Runtime PM reference.
--
commit 8f5c7d640eb5d690c93bdf294d89a5d9087edae5
Author: Even Xu <even.xu@intel.com>
HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
This commit refines the recover flow by moving the hardware recovery operation
to an asynchronous workqueue. It replaces the inline recover operation with a
call to schedule_work() and simplifies the recover callback using
thc_rxdma_reset().
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 46d3e9a019995..411d7a0ab90ef 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
[ ... ]
> @@ -245,28 +245,23 @@ static irqreturn_t quicki2c_irq_quick_handler(int irq, void *dev_id)
> }
>
> -static int try_recover(struct quicki2c_device *qcdev)
> +static void try_recover(struct work_struct *work)
> {
> + struct quicki2c_device *qcdev = container_of(work, struct quicki2c_device, recover_work);
>
> + thc_interrupt_enable(qcdev->thc_hw, false);
>
[Severity: High]
Is it safe to access the hardware registers in this work function without
holding a runtime PM reference?
Since the IRQ handler calls pm_runtime_put_autosuspend() right after
scheduling the work, could the device transition to a suspended state before
try_recover() executes, resulting in invalid MMIO accesses when trying to
manipulate the THC registers?
> - thc_dma_unconfigure(qcdev->thc_hw);
> -
> - ret = thc_dma_configure(qcdev->thc_hw);
> - if (ret) {
> - dev_err(qcdev->dev, "Reconfig DMA failed\n");
> - return ret;
> - }
> + if (thc_rxdma_reset(qcdev->thc_hw))
> + qcdev->state = QUICKI2C_DISABLED;
> + else
> + thc_interrupt_enable(qcdev->thc_hw, true);
> }
[ ... ]
> @@ -346,8 +341,7 @@ static irqreturn_t quicki2c_irq_thread_handler(int irq, void *dev_id)
> thc_interrupt_enable(qcdev->thc_hw, true);
>
[Severity: High]
Does re-enabling the interrupt here before the recovery work executes cause
an interrupt storm?
Because the actual hardware error state isn't cleared until thc_rxdma_reset()
runs asynchronously in the workqueue, unmasking the interrupt here might
cause the hardware to instantly re-assert the interrupt. Could this lead to
an infinite loop between the hard IRQ and threaded IRQ handlers, thereby
starving the system workqueue from ever executing try_recover()?
> if (err_recover)
> - if (try_recover(qcdev))
> - qcdev->state = QUICKI2C_DISABLED;
> + schedule_work(&qcdev->recover_work);
>
> pm_runtime_put_autosuspend(qcdev->dev);
[ ... ]
> @@ -386,6 +380,7 @@ static struct quicki2c_device *quicki2c_dev_init(struct pci_dev *pdev, void __io
> qcdev->ddata = ddata;
>
> init_waitqueue_head(&qcdev->reset_ack_wq);
> + INIT_WORK(&qcdev->recover_work, try_recover);
>
[Severity: High]
When the device is removed, could the scheduled work run after the device
context is freed?
Looking at quicki2c_remove(), there is no call to cancel_work_sync() before
tearing down the device. Since qcdev is allocated with devres, might
this lead to a use-after-free if the recovery work is still queued on the
system workqueue when the removal path finishes?
> /* THC hardware init */
> qcdev->thc_hw = thc_dev_init(qcdev->dev, qcdev->mem_addr);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701020432.3774514-1-even.xu@intel.com?part=2
^ permalink raw reply
* Re: [PATCH 3/3] HID: Intel-thc-hid: Intel-quickspi: Refine recover callback
From: sashiko-bot @ 2026-07-01 2:16 UTC (permalink / raw)
To: Even Xu; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260701020432.3774514-4-even.xu@intel.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] Use-after-free of qsdev during device removal due to uncanceled async work
- [High] Missing runtime PM protection during asynchronous hardware recovery
- [High] Unconditional interrupt unmasking causes severe interrupt storm
- [High] Data race on DMA configuration between IRQ thread and async recovery
Pre-existing issues:
- [High] Invalid runtime PM teardown causes unpowered hardware accesses during removal
--
commit b4ff70b4c528a251392ae3368aa0d2f80233ab2e
Author: Even Xu <even.xu@intel.com>
Subject: HID: Intel-thc-hid: Intel-quickspi: Refine recover callback
This commit refines the recovery flow by using a workqueue to handle
recovery instead of processing it in the IRQ handler. It calls
thc_rxdma_reset() to simplify operations and disables interrupts during
the recovery process.
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> index 4ae2e1718b30c..a2428db5f9414 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> @@ -252,34 +252,23 @@ static irqreturn_t quickspi_irq_quick_handler(int irq, void *dev_id)
[ ... ]
> +static void try_recover(struct work_struct *work)
> +{
> + struct quickspi_device *qsdev = container_of(work, struct quickspi_device, recover_work);
> +
> + thc_interrupt_enable(qsdev->thc_hw, false);
> +
[Severity: High]
Does this asynchronously scheduled work need to acquire its own runtime PM
reference?
The IRQ thread drops its PM reference with pm_runtime_put_autosuspend()
immediately after scheduling this work. If the autosuspend delay expires
before this workqueue executes, the device may enter a suspended state.
Will calling thc_interrupt_enable() and thc_rxdma_reset() here cause a system
crash or silent failure by accessing unpowered hardware registers?
> + if (thc_rxdma_reset(qsdev->thc_hw))
[Severity: High]
Is there a potential data race here with the IRQ thread?
The try_recover() function calls thc_rxdma_reset(), which holds the
thc_bus_lock while unconfiguring and reconfiguring the DMA hardware.
However, if a concurrent interrupt occurs, quickspi_irq_thread_handler()
calls thc_rxdma_read() without holding thc_bus_lock.
Could this allow the IRQ thread to read from DMA rings while they are
actively being torn down and rebuilt by the recovery work on another CPU?
> + qsdev->state = QUICKSPI_DISABLED;
> + else
> + thc_interrupt_enable(qsdev->thc_hw, true);
> }
[ ... ]
> @@ -340,8 +329,7 @@ static irqreturn_t quickspi_irq_thread_handler(int irq, void *dev_id)
> thc_interrupt_enable(qsdev->thc_hw, true);
>
> if (err_recover)
> - if (try_recover(qsdev))
> - qsdev->state = QUICKSPI_DISABLED;
> + schedule_work(&qsdev->recover_work);
[Severity: High]
Could this unconditional interrupt unmasking cause an interrupt storm?
When the hardware signals a fatal error, the handler unmasks the interrupt
here before returning, but the hardware reset is deferred to the asynchronous
workqueue.
Since the hardware error condition hasn't been cleared yet, won't the
device immediately re-assert the interrupt and trap the CPU in an endless
hardirq-to-thread loop before the workqueue ever has a chance to execute?
>
> pm_runtime_put_autosuspend(qsdev->dev);
>
> @@ -385,6 +373,7 @@ static struct quickspi_device *quickspi_dev_init(struct pci_dev *pdev, void __io
> init_waitqueue_head(&qsdev->report_desc_got_wq);
> init_waitqueue_head(&qsdev->get_report_cmpl_wq);
> init_waitqueue_head(&qsdev->set_report_cmpl_wq);
> + INIT_WORK(&qsdev->recover_work, try_recover);
[Severity: High]
Does this newly added work item need to be explicitly canceled during device
removal?
In the driver removal path in quickspi_remove(), there is no call to
cancel_work_sync().
Since qsdev is allocated with devm_kzalloc(), it will be freed shortly after
quickspi_remove() returns. If a fatal error interrupt schedules this work just
before or during driver unbind, could the workqueue execute after qsdev is
freed, causing a use-after-free when try_recover() dereferences it?
[Severity: High]
This is a pre-existing issue, but does quickspi_remove() properly wake the
device before accessing its hardware registers?
Currently, quickspi_remove() uses pm_runtime_get_noresume():
quickspi_remove() {
...
pm_runtime_get_noresume(qsdev->dev);
quickspi_dev_deinit(qsdev);
...
}
Calling pm_runtime_get_noresume() only increments the usage counter, it does
not resume the device. If the device was already auto-suspended,
quickspi_dev_deinit() will write to unpowered registers.
Could this lead to dropped writes or a PCIe bus error?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701020432.3774514-1-even.xu@intel.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
From: sashiko-bot @ 2026-07-01 2:19 UTC (permalink / raw)
To: Even Xu; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260701020432.3774514-2-even.xu@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Using dev_err_once() hides subsequent failures during fatal error recovery.
Pre-existing issues:
- [High] Zeroing the Physical Region Descriptor (PRD) base addresses before pausing the DMA engines can cause IOMMU faults or memory corruption.
--
commit fb285a619300634b9f208053996047e32855d49b
Author: Even Xu <even.xu@intel.com>
Date: Wed Jul 1 02:04:30 2026 +0000
HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
Add a helper function thc_rxdam_reset() to do read DMA reset, it can be
called when fatal DMA error happens.
> diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> index 6ee675e0a7384..d771c85dff28b 100644
> --- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> +++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
[ ... ]
> @@ -532,6 +532,43 @@ void thc_dma_unconfigure(struct thc_device *dev)
> }
> EXPORT_SYMBOL_NS_GPL(thc_dma_unconfigure, "INTEL_THC");
>
> +/**
> + * thc_rxdma_reset - Reset all read DMA engines
> + *
> + * @dev: The pointer of THC private device context
> + *
> + * This is a helper function to reset RxDMA configure. It's typically used
> + * for RxDMA recovery when fatal error happens.
> + */
> +int thc_rxdma_reset(struct thc_device *dev)
> +{
> + int ret;
> +
> + if (mutex_lock_interruptible(&dev->thc_bus_lock))
> + return -EINTR;
> +
> + ret = thc_interrupt_quiesce(dev, true);
> + if (ret) {
> + dev_err_once(dev->dev, "Quiesce interrupt failed during RxDMA reset\n");
[Severity: Medium]
Since thc_rxdma_reset() is called as part of a recurring fatal error
recovery flow, will dev_err_once() hide subsequent failures?
If a device successfully recovers the first time but encounters an
unrecoverable failure during a subsequent fatal error later in its uptime,
the failure will be silently ignored because dev_err_once() only prints
once per boot.
Should dev_err_ratelimited() or dev_err() be used instead?
> + goto end;
> + }
> +
> + thc_dma_unconfigure(dev);
[Severity: High]
This is a pre-existing issue, but does calling thc_dma_unconfigure()
here risk IOMMU faults or memory corruption?
When thc_rxdma_reset() invokes thc_dma_unconfigure() during fatal error
recovery, the hardware DMA engine might still be actively fetching or in
an unpredictable state.
Looking at thc_dma_unconfigure(), it zeroes out the PRD base addresses
before clearing the DMA START bits:
thc_dma_unconfigure() {
for (chan = 0; chan < MAX_THC_DMA_CHANNEL; chan++) {
dma_set_prd_base_addr(dev, 0, &dev->dma_ctx->dma_config[chan]);
...
}
regmap_write_bits(dev->thc_regmap, THC_M_PRT_READ_DMA_CNTRL_1_OFFSET,
THC_M_PRT_READ_DMA_CNTRL_START, 0);
}
If the hardware DMA engine is active and continues fetching descriptors
before the START bit is cleared, will it attempt to fetch from physical
address 0x0?
Should it wait for the ACTIVE status to clear (e.g., using
thc_wait_for_dma_pause()) before clearing the base addresses?
> +
> + ret = thc_dma_configure(dev);
> + if (ret) {
> + dev_err_once(dev->dev, "Re-config DMA failed during RxDMA reset\n");
> + goto end;
> + }
> +
> + thc_interrupt_quiesce(dev, false);
> +
> +end:
> + mutex_unlock(&dev->thc_bus_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_NS_GPL(thc_rxdma_reset, "INTEL_THC");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701020432.3774514-1-even.xu@intel.com?part=1
^ permalink raw reply
* [PATCH v8 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Vicki Pfau @ 2026-07-01 3:15 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires, linux-input
Cc: Vicki Pfau, Silvan Jegen
This series adds preliminary support for Switch 2 controllers using the
same split-driver model as previous versions. This is a minor iteration on
v7, fixing errors pointed out by sashiko as well as trying to clean up
unplug somewhat further beyond what it pointed out.
Vicki Pfau (3):
HID: nintendo: Add preliminary Switch 2 controller driver
HID: nintendo: Add rumble support for Switch 2 controllers
HID: nintendo: Add unified report format support
MAINTAINERS | 1 +
drivers/hid/Kconfig | 19 +-
drivers/hid/hid-ids.h | 4 +
drivers/hid/hid-nintendo.c | 1668 ++++++++++++++++-
drivers/hid/hid-nintendo.h | 72 +
drivers/input/joystick/Kconfig | 11 +
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/nintendo-switch2-usb.c | 453 +++++
8 files changed, 2188 insertions(+), 41 deletions(-)
create mode 100644 drivers/hid/hid-nintendo.h
create mode 100644 drivers/input/joystick/nintendo-switch2-usb.c
--
2.54.0
^ permalink raw reply
* [PATCH v8 2/3] HID: nintendo: Add rumble support for Switch 2 controllers
From: Vicki Pfau @ 2026-07-01 3:15 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires, linux-input
Cc: Vicki Pfau, Silvan Jegen
In-Reply-To: <20260701031513.3068035-1-vi@endrift.com>
This adds rumble support for both the "HD Rumble" linear resonant actuator
type as used in the Joy-Cons and Pro Controller, as well as the eccentric
rotating mass type used in the GameCube controller. Note that since there's
currently no API for exposing full control of LRAs with evdev, it only
simulates a basic rumble for now.
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/hid/Kconfig | 8 +-
drivers/hid/hid-nintendo.c | 217 ++++++++++++++++++++++++++++++++++++-
2 files changed, 218 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 19c77c323ec9..851eed76c236 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -859,10 +859,10 @@ config NINTENDO_FF
depends on HID_NINTENDO
select INPUT_FF_MEMLESS
help
- Say Y here if you have a Nintendo Switch controller and want to enable
- force feedback support for it. This works for both joy-cons, the pro
- controller, and the NSO N64 controller. For the pro controller, both
- rumble motors can be controlled individually.
+ Say Y here if you have a Nintendo Switch or Switch 2 controller and want
+ to enable force feedback support for it. This works for Joy-Cons, the Pro
+ Controllers, and the NSO N64 and GameCube controller. For the Pro
+ Controller, both rumble motors can be controlled individually.
config HID_NTI
tristate "NTI keyboard adapters"
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 20e5b18039b8..00ab4bee3dab 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -2989,6 +2989,7 @@ enum switch2_init_step {
NS2_INIT_READ_USER_SECONDARY_CALIB,
NS2_INIT_SET_FEATURE_MASK,
NS2_INIT_ENABLE_FEATURES,
+ NS2_INIT_ENABLE_RUMBLE,
NS2_INIT_GRIP_BUTTONS,
NS2_INIT_REPORT_FORMAT,
NS2_INIT_SET_PLAYER_LEDS,
@@ -3020,6 +3021,18 @@ struct switch2_stick_calibration {
struct switch2_axis_calibration y;
};
+struct switch2_hd_rumble {
+ uint16_t hi_freq : 10;
+ uint16_t hi_amp : 10;
+ uint16_t lo_freq : 10;
+ uint16_t lo_amp : 10;
+} __packed;
+
+struct switch2_erm_rumble {
+ uint16_t error;
+ uint16_t amplitude;
+};
+
struct switch2_controller {
struct hid_device *hdev;
struct switch2_cfg_intf *cfg;
@@ -3043,8 +3056,45 @@ struct switch2_controller {
uint32_t player_id;
struct led_classdev leds[4];
+
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ spinlock_t rumble_lock;
+ uint8_t rumble_seq;
+ union {
+ struct switch2_hd_rumble hd;
+ struct switch2_erm_rumble sd;
+ } rumble;
+ uint64_t last_rumble_work;
+ struct delayed_work rumble_work;
+ uint8_t *rumble_buffer;
+#endif
};
+enum gc_rumble {
+ GC_RUMBLE_OFF = 0,
+ GC_RUMBLE_ON = 1,
+ GC_RUMBLE_STOP = 2,
+};
+
+/*
+ * The highest rumble level for "HD Rumble" is strong enough to potentially damage the controller,
+ * and also leaves your hands feeling like melted jelly, so we set a semi-arbitrary scaling factor
+ * to artificially limit the maximum for safety and comfort. It is currently unknown if the Switch
+ * 2 itself does something similar, but it's quite likely.
+ *
+ * This value must be between 0 and 1024, otherwise the math below will overflow.
+ */
+#define RUMBLE_MAX 450u
+
+/*
+ * Semi-arbitrary values used to simulate the "rumble" sensation of an eccentric rotating
+ * mass type haptic motor on the Switch 2 controllers' linear resonant actuator type haptics.
+ *
+ * The units used are unknown, but the values must be between 0 and 1023.
+ */
+#define RUMBLE_HI_FREQ 0x187
+#define RUMBLE_LO_FREQ 0x112
+
static DEFINE_MUTEX(switch2_controllers_lock);
static LIST_HEAD(switch2_controllers);
@@ -3136,7 +3186,7 @@ static const uint8_t switch2_init_cmd_data[] = {
static const uint8_t switch2_one_data[] = { 0x01, 0x00, 0x00, 0x00 };
static const uint8_t switch2_feature_mask[] = {
- NS2_FEATURE_BUTTONS | NS2_FEATURE_ANALOG | NS2_FEATURE_IMU,
+ NS2_FEATURE_BUTTONS | NS2_FEATURE_ANALOG | NS2_FEATURE_IMU | NS2_FEATURE_RUMBLE,
0x00, 0x00, 0x00
};
@@ -3197,7 +3247,11 @@ static void switch2_controller_put(struct switch2_controller *ns2)
static void switch2_kref_put(struct kref *refcount)
{
struct switch2_controller *ns2 = container_of(refcount,
- struct switch2_controller, refcount);
+ struct switch2_controller, refcount);
+
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ cancel_delayed_work_sync(&ns2->rumble_work);
+#endif
guard(mutex)(&switch2_controllers_lock);
list_del_init(&ns2->entry);
@@ -3205,6 +3259,125 @@ static void switch2_kref_put(struct kref *refcount)
kfree(ns2);
}
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+static void switch2_encode_rumble(struct switch2_hd_rumble *rumble, uint8_t buffer[5])
+{
+ buffer[0] = rumble->hi_freq;
+ buffer[1] = (rumble->hi_freq >> 8) | (rumble->hi_amp << 2);
+ buffer[2] = (rumble->hi_amp >> 6) | (rumble->lo_freq << 4);
+ buffer[3] = (rumble->lo_freq >> 4) | (rumble->lo_amp << 6);
+ buffer[4] = rumble->lo_amp >> 2;
+}
+
+static int switch2_play_effect(struct input_dev *dev, void *data, struct ff_effect *effect)
+{
+ struct switch2_controller *ns2 = input_get_drvdata(dev);
+ unsigned long flags;
+
+ if (effect->type != FF_RUMBLE)
+ return 0;
+
+ spin_lock_irqsave(&ns2->rumble_lock, flags);
+ if (ns2->ctlr_type == NS2_CTLR_TYPE_GC) {
+ ns2->rumble.sd.amplitude = max(effect->u.rumble.strong_magnitude,
+ (uint16_t) (effect->u.rumble.weak_magnitude >> 1));
+ } else {
+ ns2->rumble.hd.hi_freq = RUMBLE_HI_FREQ;
+ ns2->rumble.hd.lo_freq = RUMBLE_LO_FREQ;
+ ns2->rumble.hd.hi_amp = effect->u.rumble.weak_magnitude * RUMBLE_MAX >> 16;
+ ns2->rumble.hd.lo_amp = effect->u.rumble.strong_magnitude * RUMBLE_MAX >> 16;
+ }
+ spin_unlock_irqrestore(&ns2->rumble_lock, flags);
+
+ schedule_delayed_work(&ns2->rumble_work, 0);
+
+ return 0;
+}
+
+static void switch2_rumble_work(struct work_struct *work)
+{
+ struct switch2_controller *ns2 = container_of(to_delayed_work(work),
+ struct switch2_controller, rumble_work);
+ unsigned long flags;
+ bool active;
+ int ret = 0;
+
+ spin_lock_irqsave(&ns2->rumble_lock, flags);
+ ns2->rumble_buffer[0x1] = 0x50 | ns2->rumble_seq;
+ if (ns2->ctlr_type == NS2_CTLR_TYPE_GC) {
+ ns2->rumble_buffer[0] = 3;
+ if (ns2->rumble.sd.amplitude == 0) {
+ ns2->rumble_buffer[2] = GC_RUMBLE_STOP;
+ ns2->rumble.sd.error = 0;
+ active = false;
+ } else {
+ if (ns2->rumble.sd.error < ns2->rumble.sd.amplitude) {
+ ns2->rumble_buffer[2] = GC_RUMBLE_ON;
+ ns2->rumble.sd.error += U16_MAX - ns2->rumble.sd.amplitude;
+ } else {
+ ns2->rumble_buffer[2] = GC_RUMBLE_OFF;
+ ns2->rumble.sd.error -= ns2->rumble.sd.amplitude;
+ }
+ active = true;
+ }
+ } else {
+ ns2->rumble_buffer[0] = 1;
+ switch2_encode_rumble(&ns2->rumble.hd, &ns2->rumble_buffer[0x2]);
+ active = ns2->rumble.hd.hi_amp || ns2->rumble.hd.lo_amp;
+ if (ns2->ctlr_type == NS2_CTLR_TYPE_PRO) {
+ /*
+ * The Pro Controller contains separate LRAs on each
+ * side that can be controlled individually.
+ */
+ ns2->rumble_buffer[0] = 2;
+ ns2->rumble_buffer[0x11] = 0x50 | ns2->rumble_seq;
+ switch2_encode_rumble(&ns2->rumble.hd, &ns2->rumble_buffer[0x12]);
+ }
+ }
+ ns2->rumble_seq = (ns2->rumble_seq + 1) & 0xF;
+ spin_unlock_irqrestore(&ns2->rumble_lock, flags);
+
+ if (active) {
+ unsigned long interval = msecs_to_jiffies(4);
+ uint64_t current_jiffies = get_jiffies_64();
+
+ if (!ns2->last_rumble_work)
+ ns2->last_rumble_work = current_jiffies;
+ else
+ ns2->last_rumble_work += interval;
+
+ /* Reschedule a little early to make sure the buffer never underruns */
+ interval += msecs_to_jiffies(2);
+ if (ns2->last_rumble_work + interval >= current_jiffies)
+ schedule_delayed_work(&ns2->rumble_work,
+ ns2->last_rumble_work + interval - current_jiffies);
+ else
+ schedule_delayed_work(&ns2->rumble_work, 0);
+ } else {
+ ns2->last_rumble_work = 0;
+ }
+
+ mutex_lock(&ns2->lock);
+ if (!ns2->hdev) {
+ cancel_delayed_work(&ns2->rumble_work);
+ } else {
+ ret = hid_hw_output_report(ns2->hdev, ns2->rumble_buffer, 64);
+ /*
+ * Don't log on ENODEV, ESHUTDOWN, or EPROTO, which can happen
+ * mid-hotplug. Also cancel any further work on ENODEV or
+ * ESHUTDOWN as they're clear indications that the endpoint
+ * is dead.
+ */
+ if (ret == -ENODEV || ret == -ESHUTDOWN)
+ cancel_delayed_work(&ns2->rumble_work);
+ else if (ret < 0 && ret != -EPROTO)
+ hid_warn_ratelimited(ns2->hdev,
+ "Failed to send output report ret=%d\n", ret);
+ }
+ mutex_unlock(&ns2->lock);
+}
+#endif
+
static int switch2_set_leds(struct switch2_controller *ns2)
{
int i;
@@ -3275,6 +3448,9 @@ static void switch2_input_deref(struct input_dev *input)
{
struct switch2_controller *ns2 = input_get_drvdata(input);
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ cancel_delayed_work_sync(&ns2->rumble_work);
+#endif
kref_put(&ns2->refcount, switch2_kref_put);
}
@@ -3346,6 +3522,20 @@ static int switch2_init_input(struct switch2_controller *ns2)
return -EINVAL;
}
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ ns2->rumble_buffer = devm_kzalloc(&input->dev, 64, GFP_KERNEL);
+ if (!ns2->rumble_buffer) {
+ input_free_device(input);
+ return -ENOMEM;
+ }
+ input_set_capability(input, EV_FF, FF_RUMBLE);
+ ret = input_ff_create_memless(input, NULL, switch2_play_effect);
+ if (ret) {
+ input_free_device(input);
+ return ret;
+ }
+#endif
+
hid_info(ns2->hdev, "Firmware version %u.%u.%u (type %i)\n", ns2->version.major,
ns2->version.minor, ns2->version.patch, ns2->version.ctlr_type);
if (ns2->version.dsp_type >= 0)
@@ -3749,7 +3939,16 @@ static int switch2_init_controller(struct switch2_controller *ns2)
return ns2->cfg->send_command(NS2_CMD_FEATSEL, NS2_SUBCMD_FEATSEL_SET_MASK,
switch2_feature_mask, sizeof(switch2_feature_mask), ns2->cfg);
case NS2_INIT_ENABLE_FEATURES:
- return switch2_features_enable(ns2, NS2_FEATURE_BUTTONS | NS2_FEATURE_ANALOG);
+ return switch2_features_enable(ns2, NS2_FEATURE_BUTTONS |
+ NS2_FEATURE_ANALOG | NS2_FEATURE_RUMBLE);
+ case NS2_INIT_ENABLE_RUMBLE:
+ /*
+ * It is unclear what this packet is supposed to be for, but it
+ * appears to be needed for rumble to work reliably. The reply
+ * data indicates it might be a query of some sort, but we
+ * ignore the reply so long as it doesn't return an error.
+ */
+ return ns2->cfg->send_command(0x11, 1, NULL, 0, ns2->cfg);
case NS2_INIT_GRIP_BUTTONS:
if (!switch2_ctlr_is_joycon(ns2->ctlr_type)) {
switch2_init_step_done(ns2, ns2->init_step);
@@ -3861,6 +4060,10 @@ int switch2_receive_command(struct switch2_controller *ns2,
switch2_init_step_done(ns2, NS2_INIT_GET_FIRMWARE_INFO);
}
break;
+ case 0x11:
+ if (header->subcommand == 1)
+ switch2_init_step_done(ns2, NS2_INIT_ENABLE_RUMBLE);
+ break;
default:
break;
}
@@ -3979,6 +4182,11 @@ static int switch2_probe(struct hid_device *hdev, const struct hid_device_id *id
switch2_leds_create(ns2);
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ spin_lock_init(&ns2->rumble_lock);
+ INIT_DELAYED_WORK(&ns2->rumble_work, switch2_rumble_work);
+#endif
+
ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
if (ret) {
hid_err(hdev, "hw_start failed %d\n", ret);
@@ -4018,6 +4226,9 @@ static void switch2_remove(struct hid_device *hdev)
{
struct switch2_controller *ns2 = hid_get_drvdata(hdev);
+#if IS_ENABLED(CONFIG_NINTENDO_FF)
+ cancel_delayed_work_sync(&ns2->rumble_work);
+#endif
hid_hw_close(hdev);
hid_hw_stop(hdev);
mutex_lock(&ns2->lock);
--
2.54.0
^ permalink raw reply related
* [PATCH v8 3/3] HID: nintendo: Add unified report format support
From: Vicki Pfau @ 2026-07-01 3:15 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires, linux-input
Cc: Vicki Pfau, Silvan Jegen
In-Reply-To: <20260701031513.3068035-1-vi@endrift.com>
This adds support for the "unified" report format that all controllers also
support, which has overlapping fields for like buttons and axes between
them.
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/hid/hid-nintendo.c | 151 +++++++++++++++++++++++++++++++++++--
1 file changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 00ab4bee3dab..0bddfd84fd17 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -2872,6 +2872,36 @@ static int joycon_suspend(struct hid_device *hdev, pm_message_t message)
#define NS2_BTN3_SR BIT(6)
#define NS2_BTN3_SL BIT(7)
+#define NS2_BTN_U1_Y BIT(0)
+#define NS2_BTN_U1_X BIT(1)
+#define NS2_BTN_U1_B BIT(2)
+#define NS2_BTN_U1_A BIT(3)
+#define NS2_BTN_U1_SR BIT(4)
+#define NS2_BTN_U1_SL BIT(5)
+#define NS2_BTN_U1_R BIT(6)
+#define NS2_BTN_U1_ZR BIT(7)
+
+#define NS2_BTN_U2_MINUS BIT(0)
+#define NS2_BTN_U2_PLUS BIT(1)
+#define NS2_BTN_U2_RS BIT(2)
+#define NS2_BTN_U2_LS BIT(3)
+#define NS2_BTN_U2_HOME BIT(4)
+#define NS2_BTN_U2_CAPTURE BIT(5)
+#define NS2_BTN_U2_C BIT(6)
+
+#define NS2_BTN_U3_DOWN BIT(0)
+#define NS2_BTN_U3_UP BIT(1)
+#define NS2_BTN_U3_RIGHT BIT(2)
+#define NS2_BTN_U3_LEFT BIT(3)
+#define NS2_BTN_U3_SR BIT(4)
+#define NS2_BTN_U3_SL BIT(5)
+#define NS2_BTN_U3_L BIT(6)
+#define NS2_BTN_U3_ZL BIT(7)
+
+#define NS2_BTN_U4_GR BIT(0)
+#define NS2_BTN_U4_GL BIT(1)
+#define NS2_BTN_U4_HEADSET BIT(5)
+
#define NS2_BTN_JCR_HOME BIT(0)
#define NS2_BTN_JCR_GR BIT(2)
#define NS2_BTN_JCR_C NS2_BTN3_C
@@ -3120,6 +3150,22 @@ static const struct switch2_ctlr_button_mapping ns2_left_joycon_button_mappings[
{ /* sentinel */ },
};
+static const struct switch2_ctlr_button_mapping ns2_left_joycon_button_unified_mappings[] = {
+ { BTN_DPAD_LEFT, 2, NS2_BTN_U3_LEFT, },
+ { BTN_DPAD_UP, 2, NS2_BTN_U3_UP, },
+ { BTN_DPAD_DOWN, 2, NS2_BTN_U3_DOWN, },
+ { BTN_DPAD_RIGHT, 2, NS2_BTN_U3_RIGHT, },
+ { BTN_TL, 2, NS2_BTN_U3_L, },
+ { BTN_TL2, 2, NS2_BTN_U3_ZL, },
+ { BTN_SELECT, 1, NS2_BTN_U2_MINUS, },
+ { BTN_THUMBL, 1, NS2_BTN_U2_LS, },
+ { KEY_RECORD, 1, NS2_BTN_U2_CAPTURE, },
+ { BTN_GRIPR, 2, NS2_BTN_U3_SL, },
+ { BTN_GRIPR2, 2, NS2_BTN_U3_SR, },
+ { BTN_GRIPL, 3, NS2_BTN_U4_GL, },
+ { /* sentinel */ },
+};
+
static const struct switch2_ctlr_button_mapping ns2_right_joycon_button_mappings[] = {
{ BTN_SOUTH, 0, NS2_BTNR_A, },
{ BTN_EAST, 0, NS2_BTNR_B, },
@@ -3137,6 +3183,23 @@ static const struct switch2_ctlr_button_mapping ns2_right_joycon_button_mappings
{ /* sentinel */ },
};
+static const struct switch2_ctlr_button_mapping ns2_right_joycon_button_unified_mappings[] = {
+ { BTN_SOUTH, 0, NS2_BTN_U1_A, },
+ { BTN_EAST, 0, NS2_BTN_U1_B, },
+ { BTN_NORTH, 0, NS2_BTN_U1_X, },
+ { BTN_WEST, 0, NS2_BTN_U1_Y, },
+ { BTN_TR, 0, NS2_BTN_U1_R, },
+ { BTN_TR2, 0, NS2_BTN_U1_ZR },
+ { BTN_START, 1, NS2_BTN_U2_PLUS, },
+ { BTN_THUMBR, 1, NS2_BTN_U2_RS, },
+ { BTN_C, 1, NS2_BTN_U2_C, },
+ { BTN_MODE, 1, NS2_BTN_U2_HOME, },
+ { BTN_GRIPL2, 0, NS2_BTN_U1_SL, },
+ { BTN_GRIPL, 0, NS2_BTN_U1_SR, },
+ { BTN_GRIPR, 3, NS2_BTN_U4_GR, },
+ { /* sentinel */ },
+};
+
static const struct switch2_ctlr_button_mapping ns2_procon_mappings[] = {
{ BTN_SOUTH, 0, NS2_BTNR_A, },
{ BTN_EAST, 0, NS2_BTNR_B, },
@@ -3158,6 +3221,27 @@ static const struct switch2_ctlr_button_mapping ns2_procon_mappings[] = {
{ /* sentinel */ },
};
+static const struct switch2_ctlr_button_mapping ns2_procon_unified_mappings[] = {
+ { BTN_SOUTH, 0, NS2_BTN_U1_A, },
+ { BTN_EAST, 0, NS2_BTN_U1_B, },
+ { BTN_NORTH, 0, NS2_BTN_U1_X, },
+ { BTN_WEST, 0, NS2_BTN_U1_Y, },
+ { BTN_TL, 2, NS2_BTN_U3_L, },
+ { BTN_TR, 0, NS2_BTN_U1_R, },
+ { BTN_TL2, 2, NS2_BTN_U3_ZL, },
+ { BTN_TR2, 0, NS2_BTN_U1_ZR, },
+ { BTN_SELECT, 1, NS2_BTN_U2_MINUS, },
+ { BTN_START, 1, NS2_BTN_U2_PLUS, },
+ { BTN_THUMBL, 1, NS2_BTN_U2_LS, },
+ { BTN_THUMBR, 1, NS2_BTN_U2_RS, },
+ { BTN_MODE, 1, NS2_BTN_U2_HOME },
+ { KEY_RECORD, 1, NS2_BTN_U2_CAPTURE },
+ { BTN_GRIPR, 3, NS2_BTN_U4_GR },
+ { BTN_GRIPL, 3, NS2_BTN_U4_GL },
+ { BTN_C, 1, NS2_BTN_U2_C },
+ { /* sentinel */ },
+};
+
static const struct switch2_ctlr_button_mapping ns2_gccon_mappings[] = {
{ BTN_SOUTH, 0, NS2_BTNR_A, },
{ BTN_EAST, 0, NS2_BTNR_B, },
@@ -3175,6 +3259,23 @@ static const struct switch2_ctlr_button_mapping ns2_gccon_mappings[] = {
{ /* sentinel */ },
};
+static const struct switch2_ctlr_button_mapping ns2_gccon_unified_mappings[] = {
+ { BTN_SOUTH, 0, NS2_BTN_U1_A, },
+ { BTN_EAST, 0, NS2_BTN_U1_B, },
+ { BTN_NORTH, 0, NS2_BTN_U1_X, },
+ { BTN_WEST, 0, NS2_BTN_U1_Y, },
+ { BTN_TL2, 2, NS2_BTN_U3_L, },
+ { BTN_TR2, 0, NS2_BTN_U1_R, },
+ { BTN_TL, 2, NS2_BTN_U3_ZL },
+ { BTN_TR, 0, NS2_BTN_U1_ZR },
+ { BTN_SELECT, 1, NS2_BTN_U2_MINUS, },
+ { BTN_START, 1, NS2_BTN_U2_PLUS, },
+ { BTN_MODE, 1, NS2_BTN_U2_HOME },
+ { KEY_RECORD, 1, NS2_BTN_U2_CAPTURE },
+ { BTN_C, 1, NS2_BTN_U2_C },
+ { /* sentinel */ },
+};
+
static const uint8_t switch2_init_cmd_data[] = {
/*
* The last 6 bytes of this packet are the MAC address of
@@ -3787,11 +3888,51 @@ static int switch2_event(struct hid_device *hdev, struct hid_report *report, uin
switch (report->id) {
case NS2_REPORT_UNIFIED:
- /*
- * TODO
- * This won't be sent unless the report type gets changed via command
- * 03-0A, but we should support it at some point regardless.
- */
+ if (size < 0x3f)
+ return -EINVAL;
+
+ switch (ns2->ctlr_type) {
+ case NS2_CTLR_TYPE_JCL:
+ switch2_report_stick(input, &ns2->stick_calib[0],
+ ABS_X, false, ABS_Y, true, &raw_data[11]);
+ switch2_report_buttons(input, &raw_data[5],
+ ns2_left_joycon_button_unified_mappings);
+ break;
+ case NS2_CTLR_TYPE_JCR:
+ switch2_report_stick(input, &ns2->stick_calib[0],
+ ABS_X, false, ABS_Y, true, &raw_data[14]);
+ switch2_report_buttons(input, &raw_data[5],
+ ns2_right_joycon_button_unified_mappings);
+ break;
+ case NS2_CTLR_TYPE_GC:
+ input_report_abs(input, ABS_HAT0X,
+ !!(raw_data[7] & NS2_BTN_U3_RIGHT) -
+ !!(raw_data[7] & NS2_BTN_U3_LEFT));
+ input_report_abs(input, ABS_HAT0Y,
+ !!(raw_data[7] & NS2_BTN_U3_DOWN) -
+ !!(raw_data[7] & NS2_BTN_U3_UP));
+ switch2_report_buttons(input, &raw_data[5], ns2_gccon_unified_mappings);
+ switch2_report_stick(input, &ns2->stick_calib[0],
+ ABS_X, false, ABS_Y, true, &raw_data[11]);
+ switch2_report_stick(input, &ns2->stick_calib[1],
+ ABS_RX, false, ABS_RY, true, &raw_data[14]);
+ switch2_report_trigger(input, ns2->lt_zero, ABS_Z, raw_data[0x3d]);
+ switch2_report_trigger(input, ns2->rt_zero, ABS_RZ, raw_data[0x3e]);
+ break;
+ case NS2_CTLR_TYPE_PRO:
+ input_report_abs(input, ABS_HAT0X,
+ !!(raw_data[7] & NS2_BTN_U3_RIGHT) -
+ !!(raw_data[7] & NS2_BTN_U3_LEFT));
+ input_report_abs(input, ABS_HAT0Y,
+ !!(raw_data[7] & NS2_BTN_U3_DOWN) -
+ !!(raw_data[7] & NS2_BTN_U3_UP));
+ switch2_report_buttons(input, &raw_data[5], ns2_procon_unified_mappings);
+ switch2_report_stick(input, &ns2->stick_calib[0],
+ ABS_X, false, ABS_Y, true, &raw_data[11]);
+ switch2_report_stick(input, &ns2->stick_calib[1],
+ ABS_RX, false, ABS_RY, true, &raw_data[14]);
+ break;
+ }
break;
case NS2_REPORT_JCL:
switch2_report_stick(input, &ns2->stick_calib[0], ABS_X, false,
--
2.54.0
^ permalink raw reply related
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