* [PATCH v2] HID: quirks: update hid-sony supported devices
From: Rosalie Wanders @ 2026-04-07 19:53 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Rosalie Wanders, linux-input, linux-kernel
hid-sony has been updated with new device support, update the
hid_have_special_driver list accordingly.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
changes:
v2: rebase on v2 of 'HID: sony: add support for more instruments'
drivers/hid/hid-quirks.c | 46 ++++++++++++++++++++++++++++++++++------
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index edc4339adb50..7c411e59fa6b 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -690,22 +690,54 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SUPER_JOY_BOX_5_PRO) },
#endif
#if IS_ENABLED(CONFIG_HID_SONY)
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS4_GIBSON_SG) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS4_GIBSON_SG_DONGLE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS5_GIBSON_SG) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS5_GIBSON_SG_DONGLE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB1_DRUMS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB1_GUITAR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB2_DRUMS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB2_GUITAR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_KEYBOARD) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_DRUMS_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_KEYBOARD_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_MUSTANG_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_SQUIER_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MUSTANG_GUITAR) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_HARMONY_PS3) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_PS3_BDREMOTE) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_PS4_STRATOCASTER) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_PDP, USB_DEVICE_ID_PDP_PS4_JAGUAR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PDP, USB_DEVICE_ID_PDP_PS4_RIFFMASTER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PDP, USB_DEVICE_ID_PDP_PS5_RIFFMASTER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_REDOCTANE, USB_DEVICE_ID_REDOCTANE_GUITAR_DONGLE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_REDOCTANE, USB_DEVICE_ID_REDOCTANE_PS4_GHLIVE_DONGLE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SINO_LITE, USB_DEVICE_ID_SINO_LITE_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_NSG_MR5U_REMOTE) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_NSG_MR7U_REMOTE) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_PS3_BDREMOTE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_BUZZ_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_MOTION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_MOTION_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_MOTION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_BDREMOTE) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SINO_LITE, USB_DEVICE_ID_SINO_LITE_CONTROLLER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3WIIU_GHLIVE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_DJH_TURNTABLE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_GH_DRUMS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_GH_GUITAR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_KEYBOARD) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_DRUMS_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_KEYBOARD_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_MUSTANG_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIER_MODE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MUSTANG_GUITAR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB_DRUMS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB_GUITAR) },
#endif
#if IS_ENABLED(CONFIG_HID_SPEEDLINK)
{ HID_USB_DEVICE(USB_VENDOR_ID_X_TENSIONS, USB_DEVICE_ID_SPEEDLINK_VAD_CEZANNE) },
--
2.53.0
^ permalink raw reply related
* [PATCH v2] HID: sony: fix style issues
From: Rosalie Wanders @ 2026-04-07 19:49 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Henrik Rydberg
Cc: Rosalie Wanders, linux-input, linux-kernel
This commit fixes inconsistent quirk names and also fixes all the
checkpatch.pl issues alongside inconsistent code, it also adds static
asserts to assert struct sizes at compile time.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
changes:
v2: rebase on v2 of 'HID: sony: add support for more instruments'
drivers/hid/hid-sony.c | 77 +++++++++++++++++++-----------------------
1 file changed, 34 insertions(+), 43 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index a14e730318ce..e37e19c017af 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -67,8 +67,8 @@
#define RB4_GUITAR_PS4_USB BIT(18)
#define RB4_GUITAR_PS4_BT BIT(19)
#define RB4_GUITAR_PS5 BIT(20)
-#define RB3_PS3_PRO_INSTRUMENT BIT(21)
-#define PS3_DJH_TURNTABLE BIT(22)
+#define RB3_PRO_INSTRUMENT BIT(21)
+#define DJH_TURNTABLE BIT(22)
#define SIXAXIS_CONTROLLER (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)
#define MOTION_CONTROLLER (MOTION_CONTROLLER_USB | MOTION_CONTROLLER_BT)
@@ -110,13 +110,6 @@ static const char ghl_ps4_magic_data[] = {
0x30, 0x02, 0x08, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00
};
-/* Rock Band 3 PS3 Pro Instruments require sending a report
- * once an instrument is connected to its dongle.
- * We need to retry sending these reports,
- * but to avoid doing this too often we delay the retries
- */
-#define RB3_PRO_INSTRUMENT_POKE_RETRY_INTERVAL 8 /* In seconds */
-
/* PS/3 Motion controller */
static const u8 motion_rdesc[] = {
0x05, 0x01, /* Usage Page (Desktop), */
@@ -477,6 +470,7 @@ struct sixaxis_led {
u8 duty_off; /* % of duty_length the led is off (0xff means 100%) */
u8 duty_on; /* % of duty_length the led is on (0xff mean 100%) */
} __packed;
+static_assert(sizeof(struct sixaxis_led) == 5);
struct sixaxis_rumble {
u8 padding;
@@ -485,6 +479,7 @@ struct sixaxis_rumble {
u8 left_duration; /* Left motor duration (0xff means forever) */
u8 left_motor_force; /* left (large) motor, supports force values from 0 to 255 */
} __packed;
+static_assert(sizeof(struct sixaxis_rumble) == 5);
struct sixaxis_output_report {
u8 report_id;
@@ -494,11 +489,13 @@ struct sixaxis_output_report {
struct sixaxis_led led[4]; /* LEDx at (4 - x) */
struct sixaxis_led _reserved; /* LED5, not actually soldered */
} __packed;
+static_assert(sizeof(struct sixaxis_output_report) == 36);
union sixaxis_output_report_01 {
struct sixaxis_output_report data;
u8 buf[36];
};
+static_assert(sizeof(union sixaxis_output_report_01) == 36);
struct motion_output_report_02 {
u8 type, zero;
@@ -506,6 +503,7 @@ struct motion_output_report_02 {
u8 zero2;
u8 rumble;
};
+static_assert(sizeof(struct motion_output_report_02) == 7);
#define SIXAXIS_REPORT_0xF2_SIZE 17
#define SIXAXIS_REPORT_0xF5_SIZE 8
@@ -536,7 +534,7 @@ struct sony_sc {
struct led_classdev *leds[MAX_LEDS];
unsigned long quirks;
struct work_struct state_worker;
- void (*send_output_report)(struct sony_sc *);
+ void (*send_output_report)(struct sony_sc *sc);
struct power_supply *battery;
struct power_supply_desc battery_desc;
int device_id;
@@ -613,11 +611,11 @@ static int ghl_init_urb(struct sony_sc *sc, struct usb_device *usbdev,
pipe = usb_sndctrlpipe(usbdev, 0);
cr = devm_kzalloc(&sc->hdev->dev, sizeof(*cr), GFP_ATOMIC);
- if (cr == NULL)
+ if (!cr)
return -ENOMEM;
databuf = devm_kzalloc(&sc->hdev->dev, poke_size, GFP_ATOMIC);
- if (databuf == NULL)
+ if (!databuf)
return -ENOMEM;
cr->bRequestType =
@@ -952,6 +950,7 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
static const u8 sixaxis_battery_capacity[] = { 0, 1, 25, 50, 75, 100 };
unsigned long flags;
int offset;
+ u8 index;
u8 battery_capacity;
int battery_status;
@@ -967,7 +966,7 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
battery_capacity = 100;
battery_status = (rd[offset] & 0x01) ? POWER_SUPPLY_STATUS_FULL : POWER_SUPPLY_STATUS_CHARGING;
} else {
- u8 index = rd[offset] <= 5 ? rd[offset] : 5;
+ index = rd[offset] <= 5 ? rd[offset] : 5;
battery_capacity = sixaxis_battery_capacity[index];
battery_status = POWER_SUPPLY_STATUS_DISCHARGING;
}
@@ -1005,7 +1004,7 @@ static void nsg_mrxu_parse_report(struct sony_sc *sc, u8 *rd, int size)
* the touch-related data starts at offset 2.
* For the first byte, bit 0 is set when touchpad button is pressed.
* Bit 2 is set when a touch is active and the drag (Fn) key is pressed.
- * This drag key is mapped to BTN_LEFT. It is operational only when a
+ * This drag key is mapped to BTN_LEFT. It is operational only when a
* touch point is active.
* Bit 4 is set when only the first touch point is active.
* Bit 6 is set when only the second touch point is active.
@@ -1152,11 +1151,10 @@ static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
/* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
* sending full reports, and 0x02 when only sending navigation.
*/
- if ((sc->quirks & RB3_PS3_PRO_INSTRUMENT) && rd[24] == 0x02) {
- /* Only attempt to enable report every 8 seconds */
+ if ((sc->quirks & RB3_PRO_INSTRUMENT) && rd[24] == 0x02) {
+ /* Only attempt to enable full report every 8 seconds */
if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
- sc->rb3_pro_poke_jiffies = jiffies +
- (RB3_PRO_INSTRUMENT_POKE_RETRY_INTERVAL * HZ);
+ sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
rb3_pro_instrument_enable_full_report(sc);
}
}
@@ -1218,7 +1216,7 @@ static int sony_mapping(struct hid_device *hdev, struct hid_input *hi,
if (sc->quirks & GH_GUITAR_TILT)
return gh_guitar_mapping(hdev, hi, field, usage, bit, max);
- if (sc->quirks & PS3_DJH_TURNTABLE)
+ if (sc->quirks & DJH_TURNTABLE)
return djh_turntable_mapping(hdev, hi, field, usage, bit, max);
if (sc->quirks & (RB4_GUITAR_PS4_USB | RB4_GUITAR_PS4_BT))
@@ -1273,19 +1271,18 @@ static int sony_register_touchpad(struct sony_sc *sc, int touch_count,
input_set_abs_params(sc->touchpad, ABS_MT_POSITION_Y, 0, h, 0, 0);
if (touch_major > 0) {
- input_set_abs_params(sc->touchpad, ABS_MT_TOUCH_MAJOR,
+ input_set_abs_params(sc->touchpad, ABS_MT_TOUCH_MAJOR,
0, touch_major, 0, 0);
if (touch_minor > 0)
- input_set_abs_params(sc->touchpad, ABS_MT_TOUCH_MINOR,
+ input_set_abs_params(sc->touchpad, ABS_MT_TOUCH_MINOR,
0, touch_minor, 0, 0);
if (orientation > 0)
- input_set_abs_params(sc->touchpad, ABS_MT_ORIENTATION,
+ input_set_abs_params(sc->touchpad, ABS_MT_ORIENTATION,
0, orientation, 0, 0);
}
- if (sc->quirks & NSG_MRXU_REMOTE) {
+ if (sc->quirks & NSG_MRXU_REMOTE)
__set_bit(EV_REL, sc->touchpad->evbit);
- }
ret = input_mt_init_slots(sc->touchpad, touch_count, INPUT_MT_POINTER);
if (ret < 0)
@@ -1440,7 +1437,7 @@ static void sixaxis_set_leds_from_id(struct sony_sc *sc)
int id = sc->device_id;
- BUILD_BUG_ON(MAX_LEDS < ARRAY_SIZE(sixaxis_leds[0]));
+ BUILD_BUG_ON(ARRAY_SIZE(sixaxis_leds[0]) > MAX_LEDS);
if (id < 0)
return;
@@ -1458,7 +1455,7 @@ static void buzz_set_leds(struct sony_sc *sc)
struct hid_report, list);
s32 *value = report->field[0]->value;
- BUILD_BUG_ON(MAX_LEDS < 4);
+ BUILD_BUG_ON(4 > MAX_LEDS);
value[0] = 0x00;
value[1] = sc->led_state[0] ? 0xff : 0x00;
@@ -1655,15 +1652,12 @@ static int sony_leds_init(struct sony_sc *sc)
name_sz = strlen(dev_name(&hdev->dev)) + strlen(color_name_str[n]) + 2;
led = devm_kzalloc(&hdev->dev, sizeof(struct led_classdev) + name_sz, GFP_KERNEL);
- if (!led) {
- hid_err(hdev, "Couldn't allocate memory for LED %d\n", n);
+ if (!led)
return -ENOMEM;
- }
name = (void *)(&led[1]);
if (use_color_names)
- snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev),
- color_name_str[n]);
+ snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev), color_name_str[n]);
else
snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev), n + 1);
led->name = name;
@@ -2180,7 +2174,7 @@ static int sony_input_configured(struct hid_device *hdev,
}
sony_init_output_report(sc, sixaxis_send_output_report);
- } else if (sc->quirks & RB3_PS3_PRO_INSTRUMENT) {
+ } else if (sc->quirks & RB3_PRO_INSTRUMENT) {
/*
* Rock Band 3 PS3 Pro Instruments also do not handle HID Output
* Reports on the interrupt EP like they should, so we need to force
@@ -2309,10 +2303,8 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
quirks |= SHANWAN_GAMEPAD;
sc = devm_kzalloc(&hdev->dev, sizeof(*sc), GFP_KERNEL);
- if (sc == NULL) {
- hid_err(hdev, "can't alloc sony descriptor\n");
+ if (!sc)
return -ENOMEM;
- }
spin_lock_init(&sc->lock);
@@ -2360,9 +2352,8 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto err;
}
- if (sc->quirks & RB3_PS3_PRO_INSTRUMENT) {
+ if (sc->quirks & RB3_PRO_INSTRUMENT)
sc->rb3_pro_poke_jiffies = 0;
- }
if (sc->quirks & (GHL_GUITAR_PS3WIIU | GHL_GUITAR_PS4)) {
if (!hid_is_usb(hdev)) {
@@ -2514,7 +2505,7 @@ static const struct hid_device_id sony_devices[] = {
.driver_data = INSTRUMENT },
/* DJ Hero PS3 Guitar Dongle */
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_DJH_TURNTABLE),
- .driver_data = PS3_DJH_TURNTABLE | INSTRUMENT },
+ .driver_data = DJH_TURNTABLE | INSTRUMENT },
/* Guitar Hero Live PS4 guitar dongles */
{ HID_USB_DEVICE(USB_VENDOR_ID_REDOCTANE, USB_DEVICE_ID_REDOCTANE_PS4_GHLIVE_DONGLE),
.driver_data = GHL_GUITAR_PS4 | GH_GUITAR_TILT | INSTRUMENT },
@@ -2550,15 +2541,15 @@ static const struct hid_device_id sony_devices[] = {
.driver_data = INSTRUMENT },
/* Rock Band 3 PS3 Pro instruments */
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MUSTANG_GUITAR),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
+ .driver_data = INSTRUMENT | RB3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_MUSTANG_MODE),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
+ .driver_data = INSTRUMENT | RB3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIER_MODE),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
+ .driver_data = INSTRUMENT | RB3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_KEYBOARD),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
+ .driver_data = INSTRUMENT | RB3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_KEYBOARD_MODE),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
+ .driver_data = INSTRUMENT | RB3_PRO_INSTRUMENT },
/* Rock Band 4 PS4 guitars */
{ HID_USB_DEVICE(USB_VENDOR_ID_PDP, USB_DEVICE_ID_PDP_PS4_RIFFMASTER),
.driver_data = RB4_GUITAR_PS4_USB | INSTRUMENT },
--
2.53.0
^ permalink raw reply related
* [PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
From: Nícolas F. R. A. Prado @ 2026-04-07 20:59 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: kernel, linux-input, linux-kernel, Nícolas F. R. A. Prado
The Logitech Bolt receiver once connected to a wireless device will
generate data on interface 2. If this data isn't polled, when the USB
port it is connected to gets suspended (and if that happens within 5
minutes of the last input from the wireless device), it will trigger a
remote wakeup 3 seconds later, which will result in a spurious system
wakeup if the port was suspended as part of system sleep.
Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
always polled and this spurious wakeup never happens.
With this change in place the system can be suspended with the receiver
plugged in and the system can be woken up when an input is sent from the
wireless device.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
Hi,
Given that the polling only needs to happen before the device goes into
suspend, I wonder if it might make sense to introduce a new quirk type
that only does a poll before the device goes into suspend (both for
system sleep and runtime suspend). It would reduce the extra bit of USB
traffic that ends up happening in this case with ALWAYS_POLL every time
a wireless device connects to the receiver.
---
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 02f7db5c1056..eb811b1fb80f 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -134,6 +134,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS), HID_QUIRK_NOGET },
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-logi-bolt-hid-quirk-always-poll-5d9c9238c924
Best regards,
--
Nícolas F. R. A. Prado <nfraprado@collabora.com>
^ permalink raw reply related
* [PATCH] Input: zinitix: don't use finger_mask as bitmask when reporting contacts
From: Thanh Nguyen @ 2026-04-08 3:14 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, dmitry.torokhov, Thanh Nguyen
The zinitix touchscreen driver was treating touch_event.finger_mask as a
bitmask to iterate through finger slots. However, on some devices (e.g.,
Samsung Galaxy A3 2015), finger_mask behaves as a finger count rather than
a bitmask, causing multitouch to malfunction.
Instead of relying on finger_mask as a bitmask, iterate through all
possible finger slots and check if SUB_BIT_EXIST is set for each slot.
This restores proper multitouch functionality on affected devices.
Fixes: e941dc13fd (")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221278
Signed-off-by: Thanh Nguyen <thanhnguyxn07@gmail.com>
---
drivers/input/touchscreen/zinitix.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
index 716d6fa60..b80525443 100644
--- a/drivers/input/touchscreen/zinitix.c
+++ b/drivers/input/touchscreen/zinitix.c
@@ -445,7 +445,6 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
struct bt541_ts_data *bt541 = bt541_handler;
struct i2c_client *client = bt541->client;
struct touch_event touch_event;
- unsigned long finger_mask;
__le16 icon_events;
int error;
int i;
@@ -470,11 +469,12 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
zinitix_report_keys(bt541, le16_to_cpu(icon_events));
}
- finger_mask = touch_event.finger_mask;
- for_each_set_bit(i, &finger_mask, MAX_SUPPORTED_FINGER_NUM) {
+ /* Process all finger slots and check if they exist, rather than relying on finger_mask as a bitmask.
+ * On some devices (e.g., Samsung A3 2015), finger_mask behaves as finger count rather than bitmask.
+ * Only process contacts that are actually reported as existing. */
+ for (i = 0; i < MAX_SUPPORTED_FINGER_NUM; i++) {
const struct point_coord *p = &touch_event.point_coord[i];
- /* Only process contacts that are actually reported */
if (p->sub_status & SUB_BIT_EXIST)
zinitix_report_finger(bt541, i, p);
}
--
2.51.0.windows.2
^ permalink raw reply related
* Re: [PATCH] Input: zinitix: don't use finger_mask as bitmask when reporting contacts
From: Dmitry Torokhov @ 2026-04-08 4:51 UTC (permalink / raw)
To: Thanh Nguyen, Linus Walleij; +Cc: linux-input, linux-kernel
In-Reply-To: <20260408031440.955-1-thanhnguyxn07@gmail.com>
Hi Thanh,
On Tue, Apr 07, 2026 at 10:14:40PM -0500, Thanh Nguyen wrote:
> The zinitix touchscreen driver was treating touch_event.finger_mask as a
>
> bitmask to iterate through finger slots. However, on some devices (e.g.,
>
> Samsung Galaxy A3 2015), finger_mask behaves as a finger count rather than
>
> a bitmask, causing multitouch to malfunction.
>
> Instead of relying on finger_mask as a bitmask, iterate through all
>
> possible finger slots and check if SUB_BIT_EXIST is set for each slot.
>
> This restores proper multitouch functionality on affected devices.
>
> Fixes: e941dc13fd (")
So this is effectively a revert of e941dc13fd37 ("Input: zinitix - do
not report shadow fingers") and Linus reported that on his device
ignoring finger count/mask field results in "shadow" contains being
reported, so we obviously can not apply this as is.
So the question is whether this is a mask or a count? Could it be that
it is actually a count of reported slots and we need to stop the loop
after we process the "count" number of slots because the rest is simply
on-stack garbage?
Cc-ing Linus who authored the commit in question...
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221278
>
> Signed-off-by: Thanh Nguyen <thanhnguyxn07@gmail.com>
> ---
> drivers/input/touchscreen/zinitix.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
> index 716d6fa60..b80525443 100644
> --- a/drivers/input/touchscreen/zinitix.c
> +++ b/drivers/input/touchscreen/zinitix.c
> @@ -445,7 +445,6 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
> struct bt541_ts_data *bt541 = bt541_handler;
> struct i2c_client *client = bt541->client;
> struct touch_event touch_event;
> - unsigned long finger_mask;
> __le16 icon_events;
> int error;
> int i;
> @@ -470,11 +469,12 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
> zinitix_report_keys(bt541, le16_to_cpu(icon_events));
> }
>
> - finger_mask = touch_event.finger_mask;
> - for_each_set_bit(i, &finger_mask, MAX_SUPPORTED_FINGER_NUM) {
> + /* Process all finger slots and check if they exist, rather than relying on finger_mask as a bitmask.
> + * On some devices (e.g., Samsung A3 2015), finger_mask behaves as finger count rather than bitmask.
> + * Only process contacts that are actually reported as existing. */
> + for (i = 0; i < MAX_SUPPORTED_FINGER_NUM; i++) {
> const struct point_coord *p = &touch_event.point_coord[i];
>
> - /* Only process contacts that are actually reported */
> if (p->sub_status & SUB_BIT_EXIST)
> zinitix_report_finger(bt541, i, p);
> }
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Dmitry Torokhov @ 2026-04-08 4:52 UTC (permalink / raw)
To: Sanjay Govind
Cc: Vicki Pfau, Nilton Perim Neto, Mario Limonciello,
Antheas Kapenekakis, Pierre-Loup A. Griffais, linux-input,
linux-kernel
In-Reply-To: <CALQgdA0UpJb7Lztkts3LrFtWrAP3V3CivFv3NKJDFg1VY_q_0A@mail.gmail.com>
On Wed, Apr 08, 2026 at 07:22:08AM +1200, Sanjay Govind wrote:
> On Tue, Apr 7, 2026 at 4:46 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>
> > Sashuko correctly identified issues areoud re-scheduling work that
> already completed, please see:
>
> Is there a way to test a patch against sashiko without submitting it
> to the mailing list?
I think you'd have to spin up your own instance for that...
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: uinput - fix circular locking dependency with ff-core
From: Dmitry Torokhov @ 2026-04-08 4:56 UTC (permalink / raw)
To: Mikhail Gavrilov; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <20260407075031.38351-1-mikhail.v.gavrilov@gmail.com>
On Tue, Apr 07, 2026 at 12:50:31PM +0500, Mikhail Gavrilov wrote:
> A lockdep circular locking dependency warning can be triggered
> reproducibly when using a force-feedback gamepad with uinput (for
> example, playing ELDEN RING under Wine with a Flydigi Vader 5
> controller):
>
> ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
>
> The cycle is caused by four lock acquisition paths:
>
> 1. ff upload: input_ff_upload() holds ff->mutex and calls
> uinput_dev_upload_effect() -> uinput_request_submit() ->
> uinput_request_send(), which acquires udev->mutex.
>
> 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> uinput_create_device() -> input_register_device(), which acquires
> input_mutex.
>
> 3. device register: input_register_device() holds input_mutex and
> calls kbd_connect() -> input_register_handle(), which acquires
> dev->mutex.
>
> 4. evdev release: evdev_release() calls input_flush_device() under
> dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
>
> Fix this by introducing a new state_lock spinlock to protect
> udev->state and udev->dev access in uinput_request_send() instead of
> acquiring udev->mutex. The function only needs to atomically check
> device state and queue an input event into the ring buffer via
> uinput_dev_event() -- both operations are safe under a spinlock
> (ktime_get_ts64() and wake_up_interruptible() do not sleep). This
> breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in
> the lock ordering and cannot form cycles with mutexes.
>
> To keep state transitions visible to uinput_request_send(), protect
> writes to udev->state in uinput_create_device() and
> uinput_destroy_device() with the same state_lock spinlock.
>
> Additionally, move init_completion(&request->done) from
> uinput_request_send() to uinput_request_submit() before
> uinput_request_reserve_slot(). Once the slot is allocated,
> uinput_flush_requests() may call complete() on it at any time from
> the destroy path, so the completion must be initialised before the
> request becomes visible.
>
> Lock ordering after the fix:
>
> ff->mutex -> state_lock (spinlock, leaf)
> udev->mutex -> state_lock (spinlock, leaf)
> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)
>
> Fixes: ff462551235d ("Input: uinput - switch to the new FF interface")
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/all/CABXGCsMoxag+kEwHhb7KqhuyxfmGGd0P=tHZyb1uKE0pLr8Hkg@mail.gmail.com/
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Sanjay Govind @ 2026-04-08 5:04 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Vicki Pfau, Nilton Perim Neto, Mario Limonciello,
Antheas Kapenekakis, Pierre-Loup A. Griffais, linux-input,
linux-kernel
In-Reply-To: <adXe452989A6k2PJ@google.com>
On Wed, Apr 8, 2026 at 4:52 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> I think you'd have to spin up your own instance for that...
makes sense
^ permalink raw reply
* [PATCH] Input: uinput - take event lock when submitting FF request "event"
From: Dmitry Torokhov @ 2026-04-08 5:16 UTC (permalink / raw)
To: linux-input; +Cc: Mikhail Gavrilov, linux-kernel
To avoid racing with FF playback events and corrupting device's event
queue take event_lock spinlock when calling uinput_dev_event() when
submitting a FF upload or erase "event".
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Mikhail, could you please try this one?
drivers/input/misc/uinput.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index e24caf6fc8e8..d32fa4b508fc 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -25,8 +25,10 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/fs.h>
+#include <linux/lockdep.h>
#include <linux/miscdevice.h>
#include <linux/overflow.h>
+#include <linux/spinlock.h>
#include <linux/input/mt.h>
#include "../input-compat.h"
@@ -76,6 +78,8 @@ static int uinput_dev_event(struct input_dev *dev,
struct uinput_device *udev = input_get_drvdata(dev);
struct timespec64 ts;
+ lockdep_assert_held(&dev->event_lock);
+
ktime_get_ts64(&ts);
udev->buff[udev->head] = (struct input_event) {
@@ -147,6 +151,7 @@ static void uinput_request_release_slot(struct uinput_device *udev,
static int uinput_request_send(struct uinput_device *udev,
struct uinput_request *request)
{
+ unsigned long flags;
int retval = 0;
spin_lock(&udev->state_lock);
@@ -160,7 +165,9 @@ static int uinput_request_send(struct uinput_device *udev,
* Tell our userspace application about this new request
* by queueing an input event.
*/
+ spin_lock_irqsave(&udev->dev->event_lock, flags);
uinput_dev_event(udev->dev, EV_UINPUT, request->code, request->id);
+ spin_unlock_irqrestore(&udev->dev->event_lock, flags);
out:
spin_unlock(&udev->state_lock);
--
2.53.0.1213.gd9a14994de-goog
--
Dmitry
^ permalink raw reply related
* [PATCH] Input: zinitix: iterate contact slots by finger count
From: Thanh Nguyen @ 2026-04-08 5:19 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linux-input, linux-kernel, linus.walleij, timon37, Thanh Nguyen
On affected devices (for example Samsung A3 2015), the value in
touch_event.finger_mask appears to behave as a count of reported slots
rather than a bitmask. Using for_each_set_bit() can then skip valid
contacts and break multitouch gestures.
Keep filtering by SUB_BIT_EXIST to avoid reporting shadow contacts, but
iterate from slot 0 up to min(finger_mask, MAX_SUPPORTED_FINGER_NUM).
This follows the maintainer feedback to treat the field as a possible
count while preserving the anti-shadow check.
Fixes: e941dc13fd37 ("Input: zinitix - do not report shadow fingers")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221278
Signed-off-by: Thanh Nguyen <thanhnguyxn07@gmail.com>
---
v2:
- Address maintainer feedback: do not revert e941dc13fd37.
- Keep SUB_BIT_EXIST filtering to avoid shadow contacts.
- Treat finger_mask as a slot-count bound and iterate 0..min(mask, max).
drivers/input/touchscreen/zinitix.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
index 716d6fa60..a2edae7df 100644
--- a/drivers/input/touchscreen/zinitix.c
+++ b/drivers/input/touchscreen/zinitix.c
@@ -471,7 +471,8 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
}
finger_mask = touch_event.finger_mask;
- for_each_set_bit(i, &finger_mask, MAX_SUPPORTED_FINGER_NUM) {
+ for (i = 0; i < min_t(unsigned long, finger_mask,
+ MAX_SUPPORTED_FINGER_NUM); i++) {
const struct point_coord *p = &touch_event.point_coord[i];
/* Only process contacts that are actually reported */
--
2.51.0.windows.2
^ permalink raw reply related
* Re: [PATCH v8 1/7] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg @ 2026-04-08 11:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kaustabh Chakraborty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Casey Connolly, linux-input, devicetree,
linux-kernel, phone-devel, Krzysztof Kozlowski
In-Reply-To: <adSMQXgbco8fvRLo@google.com>
On 07/04/2026 06:48, Dmitry Torokhov wrote:
> On Wed, Mar 25, 2026 at 12:33:23PM +0100, David Heidelberg wrote:
>> On 24/03/2026 20:42, Dmitry Torokhov wrote:
>>> On Tue, Mar 24, 2026 at 08:40:34PM +0100, David Heidelberg via B4 Relay wrote:
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> Mostly irrelevant for authentic Synaptics touchscreens, but very important
>>>> for applying workarounds to cheap TS knockoffs.
>>>>
>>>> These knockoffs work well with the downstream driver, and since the user
>>>> has no way to distinguish them, later in this patch set, we introduce
>>>> workarounds to ensure they function as well as possible.
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> ---
>>>> Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
>>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> index 8685ef4481f4a..fb4804ac3544d 100644
>>>> --- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> @@ -18,9 +18,14 @@ description: |
>>>> properties:
>>>> compatible:
>>>> - enum:
>>>> - - syna,rmi4-i2c
>>>> - - syna,rmi4-spi
>>>> + oneOf:
>>>> + - enum:
>>>> + - syna,rmi4-i2c
>>>> + - syna,rmi4-spi
>>>> + - items:
>>>> + - enum:
>>>> + - syna,rmi4-s3706b # OnePlus 6/6T
>>>
>>> I thought that all the workarounds will be keyed off this new
>>> compatible, but I do not see that. What am I missing?
>>
>> The compatible is used for sequence in the
>>
>> Input: synaptics-rmi4 - support fallback values for PDT descriptor bytes
>>
>> where it is used to provide values missing for OP6 (and possible others in
>> the future, when added).
>>
>> From my understanding the series, only two patches (1st and last) are
>> specific for the OP6, rest will likely benefit various TS not implementing
>> full Synaptics set. All measures apply only when touchscreen reports
>> something wrong.
>
> If the sensor does not implement RMI4 protocol properly it should not
> use rmi4 compatibility. I will not apply any patches that work around
> incomplete implementations unless they are triggered by a dedicated
> compatible.
Ok, good.
Can we agree on subset which is correct now?
I think that
[PATCH v8 4/7] Input: synaptics-rmi4 - f55: handle zero electrode count
[PATCH v8 6/7] Input: synaptics-rmi4 - read product ID on aftermarket touch ICs
could be reasonable to keep as is, except I would reword the 6/7, as reading
product ID isn't anything aftermarket specific.
Then I would send this subset to get in first and work on the rest, does it
sounds good to you?
David>
> Thanks.
>
--
David Heidelberg
^ permalink raw reply
* [PATCH 2/2] Input: qt1070 - inline i2c_check_functionality check
From: Thorsten Blum @ 2026-04-08 14:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Thorsten Blum, linux-input, linux-kernel
In-Reply-To: <20260408141926.1181389-3-thorsten.blum@linux.dev>
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/input/keyboard/qt1070.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/qt1070.c b/drivers/input/keyboard/qt1070.c
index b3db2c7d0957..b255b997e279 100644
--- a/drivers/input/keyboard/qt1070.c
+++ b/drivers/input/keyboard/qt1070.c
@@ -133,8 +133,7 @@ static int qt1070_probe(struct i2c_client *client)
int i;
int err;
- err = i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE);
- if (!err) {
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)) {
dev_err(&client->dev, "%s adapter not supported\n",
dev_driver_string(&client->adapter->dev));
return -ENODEV;
^ permalink raw reply related
* [PATCH 1/2] Input: qt1050 - inline i2c_check_functionality check
From: Thorsten Blum @ 2026-04-08 14:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Thorsten Blum, linux-input, linux-kernel
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/input/keyboard/qt1050.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/qt1050.c b/drivers/input/keyboard/qt1050.c
index bce8157d1871..f9f480c91032 100644
--- a/drivers/input/keyboard/qt1050.c
+++ b/drivers/input/keyboard/qt1050.c
@@ -435,8 +435,7 @@ static int qt1050_probe(struct i2c_client *client)
int err;
/* Check basic functionality */
- err = i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE);
- if (!err) {
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)) {
dev_err(&client->dev, "%s adapter not supported\n",
dev_driver_string(&client->adapter->dev));
return -ENODEV;
^ permalink raw reply related
* Re: [PATCH 1/2] Input: qt1050 - inline i2c_check_functionality check
From: Dmitry Torokhov @ 2026-04-08 14:47 UTC (permalink / raw)
To: Thorsten Blum; +Cc: linux-input, linux-kernel
In-Reply-To: <20260408141926.1181389-3-thorsten.blum@linux.dev>
On Wed, Apr 08, 2026 at 04:19:25PM +0200, Thorsten Blum wrote:
> Inline the i2c_check_functionality() check, since the function returns a
> boolean status rather than an error code.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Applied both, thank you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 3/5] Input: pc110pad - remove driver
From: Dmitry Torokhov @ 2026-04-08 14:49 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-input, linux-kernel, Vojtech Pavlik, Jiri Kosina,
Benjamin Tissoires, Maciej W. Rozycki
In-Reply-To: <20260407195138.GA251078@bhelgaas>
On Tue, Apr 07, 2026 at 02:51:38PM -0500, Bjorn Helgaas wrote:
> [+cc Maciej]
>
> On Thu, Aug 08, 2024 at 10:27:29AM -0700, Dmitry Torokhov wrote:
> > Palm Top PC 110 is a handheld personal computer with 80486SX CPU that
> > was released exclusively in Japan in September 1995.
> >
> > While the kernel still supports 486 CPU it is highly unlikely that
> > anyone is using this device with the latest kernel.
> >
> > Remove the driver.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> I applied this patch only to remove pc110pad to pci/enumeration for
> v7.1, since "x86/cpu: Remove M486/M486SX/ELAN support" has been queued
> for v7.1:
> https://lore.kernel.org/all/20251214084710.3606385-2-mingo@kernel.org/
>
> I put this in the PCI tree because pc110pad was the only user of
> no_pci_devices(), which we can now remove as well.
And I am going to apply the rest of the series. They are really simply a
historical curiosity now.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)
From: Benjamin Tissoires @ 2026-04-08 15:41 UTC (permalink / raw)
To: Zhouwang Huang; +Cc: Jiri Kosina, denis.benato, linux-kernel, linux-input
In-Reply-To: <20260407173212.86942-1-honjow311@gmail.com>
Hi,
Definitely not a big fan of that new quirk. The issue is that current
hid-core fix is too restrictive because it doesn't have enough
information, like the actual allocated buffer size.
On Apr 08 2026, Zhouwang Huang wrote:
> Commit 9e2a17d2e808 ("HID: gpd: fix report descriptor on GPD Win
> handheld (2f24:0137)") used report_fixup to shrink Report Count from
> 63 to 11 so that short reports from firmware <= 1.09 would not be
> rejected by hid_report_raw_event().
>
> However, firmware 1.10 fixed the report length and now sends the full
> 63 bytes. Because report_fixup already shrank the descriptor,
> usbhid allocates a 12-byte URB buffer — far too small for the 64-byte
> transfer — causing continuous -EOVERFLOW on every interrupt-in URB.
> The HID report descriptor and bcdDevice are identical across firmware
> versions, so report_fixup cannot conditionally apply.
OK, so if a firmware already fixed the bug, I'll drop 9e2a17d2e808 from
for-next and not include it in the final 7.0 PR I'll need to send. We
can tell people to upgrade to the latest firmware while I work on a
proper fix.
BTW, technically we could also not change the report descriptor if we
detect the correct firmware version. That would be easier to implement
than a global quirk. But hopefully we won't have to do anything and get
the proper hid-core fix soon.
Cheers,
Benjamin
>
> Replace the report_fixup driver with a new per-device quirk
> HID_QUIRK_ALLOW_SHORT_REPORTS. When set, hid_report_raw_event()
> zero-pads short reports instead of rejecting them — the same behaviour
> the core had before commit 0a3fe972a7cb ("HID: core: Mitigate
> potential OOB by removing bogus memset()"). The descriptor is left
> unmodified so the URB buffer matches the declared report size and works
> with any firmware version.
>
> Remove hid-gpd.c, its Kconfig entry and Makefile line; the device is
> now handled by hid-generic with the quirk applied from hid-quirks.c.
>
> Fixes: 9e2a17d2e808 ("HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)")
> Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
> ---
> drivers/hid/Kconfig | 10 --------
> drivers/hid/Makefile | 1 -
> drivers/hid/hid-core.c | 11 +++++----
> drivers/hid/hid-gpd.c | 52 ----------------------------------------
> drivers/hid/hid-quirks.c | 2 ++
> include/linux/hid.h | 2 ++
> 6 files changed, 11 insertions(+), 67 deletions(-)
> delete mode 100644 drivers/hid/hid-gpd.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 2159d0fb7020..c1d9f7c6a5f2 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -419,16 +419,6 @@ config HID_GLORIOUS
> Support for Glorious PC Gaming Race mice such as
> the Glorious Model O, O- and D.
>
> -config HID_GPD
> - tristate "GPD Win handheld OEM HID support"
> - depends on USB_HID
> - help
> - Report descriptor fix for the OEM USB HID interface (GameSir
> - 2f24:0137) found on GPD Win handhelds. The firmware declares 63-byte
> - reports but only sends 11 bytes, which the HID core rejects.
> -
> - Say Y or M here if you use a GPD Win handheld with this interface.
> -
> config HID_HOLTEK
> tristate "Holtek HID devices"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index f69cd6015465..e01838239ae6 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -53,7 +53,6 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> -obj-$(CONFIG_HID_GPD) += hid-gpd.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index f5587b786f87..52e86f927a38 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,10 +2057,13 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> rsize = max_buffer_size;
>
> if (csize < rsize) {
> - hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> - report->id, rsize, csize);
> - ret = -EINVAL;
> - goto out;
> + if (!(hid->quirks & HID_QUIRK_ALLOW_SHORT_REPORTS)) {
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> + report->id, rsize, csize);
> + ret = -EINVAL;
> + goto out;
> + }
> + memset(cdata + csize, 0, rsize - csize);
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
> deleted file mode 100644
> index 5b4d203e2499..000000000000
> --- a/drivers/hid/hid-gpd.c
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * HID report descriptor fixup for GPD Win handhelds.
> - *
> - * The OEM HID interface (VID 2f24 / GameSir, PID 0137) declares Report ID 1
> - * with Report Count 63 (8-bit fields) for both Input and Feature, but the
> - * firmware only sends 11 bytes of payload after the report ID.
> - */
> -
> -#include <linux/hid.h>
> -#include <linux/module.h>
> -
> -#include "hid-ids.h"
> -
> -#define RDESC_LEN 38
> -#define RPT_COUNT_INPUT_OFF 21
> -#define RPT_COUNT_FEATURE_OFF 34
> -
> -static const __u8 *gpd_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> - unsigned int *rsize)
> -{
> - if (*rsize != RDESC_LEN)
> - return rdesc;
> -
> - if (rdesc[RPT_COUNT_INPUT_OFF - 1] == 0x95 &&
> - rdesc[RPT_COUNT_INPUT_OFF] == 0x3f &&
> - rdesc[RPT_COUNT_FEATURE_OFF - 1] == 0x95 &&
> - rdesc[RPT_COUNT_FEATURE_OFF] == 0x3f) {
> - hid_info(hdev, "fixing report counts (63 -> 11 bytes)\n");
> - rdesc[RPT_COUNT_INPUT_OFF] = 11;
> - rdesc[RPT_COUNT_FEATURE_OFF] = 11;
> - }
> -
> - return rdesc;
> -}
> -
> -static const struct hid_device_id gpd_devices[] = {
> - { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137) },
> - { }
> -};
> -MODULE_DEVICE_TABLE(hid, gpd_devices);
> -
> -static struct hid_driver gpd_driver = {
> - .name = "gpd",
> - .id_table = gpd_devices,
> - .report_fixup = gpd_report_fixup,
> -};
> -
> -module_hid_driver(gpd_driver);
> -
> -MODULE_DESCRIPTION("HID report descriptor fix for GPD Win handheld (GameSir 2f24:0137)");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index f6be3ffee023..b9ae1442eba9 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -97,6 +97,8 @@ static const struct hid_device_id hid_quirks[] = {
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> { HID_USB_DEVICE(USB_VENDOR_ID_GAMEVICE, USB_DEVICE_ID_GAMEVICE_KISHI),
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137),
> + HID_QUIRK_ALLOW_SHORT_REPORTS },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 31324609af4d..212dd13bfcfa 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -381,6 +381,7 @@ struct hid_item {
> * | @HID_QUIRK_X_INVERT:
> * | @HID_QUIRK_Y_INVERT:
> * | @HID_QUIRK_IGNORE_MOUSE:
> + * | @HID_QUIRK_ALLOW_SHORT_REPORTS: accept shorter-than-expected reports, zero-pad
> * | @HID_QUIRK_SKIP_OUTPUT_REPORTS:
> * | @HID_QUIRK_SKIP_OUTPUT_REPORT_ID:
> * | @HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP:
> @@ -408,6 +409,7 @@ struct hid_item {
> #define HID_QUIRK_X_INVERT BIT(12)
> #define HID_QUIRK_Y_INVERT BIT(13)
> #define HID_QUIRK_IGNORE_MOUSE BIT(14)
> +#define HID_QUIRK_ALLOW_SHORT_REPORTS BIT(15)
> #define HID_QUIRK_SKIP_OUTPUT_REPORTS BIT(16)
> #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID BIT(17)
> #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP BIT(18)
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Antheas Kapenekakis @ 2026-04-08 15:47 UTC (permalink / raw)
To: Sanjay Govind
Cc: Dmitry Torokhov, Vicki Pfau, Nilton Perim Neto, Mario Limonciello,
Pierre-Loup A. Griffais, linux-input, linux-kernel
In-Reply-To: <CALQgdA04mczQoJ4HyjSwgeXMHwLT+Rv0AEoArpwBohzL9oa1nw@mail.gmail.com>
On Wed, 8 Apr 2026 at 07:04, Sanjay Govind <sanjay.govind9@gmail.com> wrote:
>
> On Wed, Apr 8, 2026 at 4:52 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > I think you'd have to spin up your own instance for that...
>
> makes sense
>
Hi Sanjay,
I have a workflow for running an llm and getting reviews locally.
Perhaps I will post it to the mailing list soon. I can cc you. I have
been out for the Easter holidays
Of course, you will need your own LLM and harness for that, Claude
code/Antigravity/Copilot/Opencode, etc. I know they aren't
particularly cheap.
Dmitry, sashiko looks great, I left a star. I could also cc you. I
will also reference the prompts used in that as it claims some
subsystem specific ones. From a quick glance it seems to might suffer
from context bloat though. There are a lot of guideline files that
could have higher information density.
Antheas
^ permalink raw reply
* Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)
From: Zhouwang Huang @ 2026-04-08 16:07 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, denis.benato, linux-input, linux-kernel, honjow311
In-Reply-To: <adZ2PTzQ05iObcGt@beelink>
Hi Benjamin,
Thanks. Agreed, a core fix that checks the actual buffer size would be
much cleaner than a per-device quirk.
Happy to test when it's ready.
Thanks,
Zhouwang
^ permalink raw reply
* [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Mohamad Raizudeen @ 2026-04-08 16:28 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: Mohamad Raizudeen, kees, linux-input, linux-kernel
The current implementation restarts the scan from the beginning after
each disconnection(goto start_over) because serio_disconnect_port() may
delete the current list entry. This results in O(n^2) worst case
behaviour.
Replace with a two-phase approach:
1.Collect only top-level ports bound to the driver(skip those whose parent is also bound to the same driver) into a
temporary list.
2.Process each collected port once, moving it back to serio_list first to maintain invariants expected by serio_destroy_port().
This eliminates the restart loop, reduces complexity from O(n^2) to O(n)
and avoids use-after-free by never collecting child ports separately.
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
---
drivers/input/serio/serio.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 54dd26249b02..46b8faf1a46c 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -821,22 +821,27 @@ EXPORT_SYMBOL(__serio_register_driver);
void serio_unregister_driver(struct serio_driver *drv)
{
- struct serio *serio;
+ struct serio *serio, *next;
+ LIST_HEAD(disconnect_list);
+
guard(mutex)(&serio_mutex);
drv->manual_bind = true; /* so serio_find_driver ignores it */
serio_remove_pending_events(drv);
-start_over:
- list_for_each_entry(serio, &serio_list, node) {
- if (serio->drv == drv) {
- serio_disconnect_port(serio);
- serio_find_driver(serio);
- /* we could've deleted some ports, restart */
- goto start_over;
+ /*Collect all ports bound to this driver first*/
+ list_for_each_entry_safe(serio, next, &serio_list, node) {
+ if (serio->drv == drv && !(serio->parent && serio->parent->drv == drv)) {
+ list_move_tail(&serio->node, &disconnect_list);
}
}
+
+ list_for_each_entry_safe(serio, next, &disconnect_list, node) {
+ list_move_tail(&serio->node, &serio_list);
+ serio_disconnect_port(serio);
+ serio_find_driver(serio);
+ }
driver_unregister(&drv->driver);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input: uinput - take event lock when submitting FF request "event"
From: Mikhail Gavrilov @ 2026-04-08 16:47 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <adXkf6MWzlB8LA_s@google.com>
On Wed, Apr 8, 2026 at 10:16 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> To avoid racing with FF playback events and corrupting device's event
> queue take event_lock spinlock when calling uinput_dev_event() when
> submitting a FF upload or erase "event".
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>
> Mikhail, could you please try this one?
>
> drivers/input/misc/uinput.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index e24caf6fc8e8..d32fa4b508fc 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -25,8 +25,10 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/fs.h>
> +#include <linux/lockdep.h>
> #include <linux/miscdevice.h>
> #include <linux/overflow.h>
> +#include <linux/spinlock.h>
> #include <linux/input/mt.h>
> #include "../input-compat.h"
>
> @@ -76,6 +78,8 @@ static int uinput_dev_event(struct input_dev *dev,
> struct uinput_device *udev = input_get_drvdata(dev);
> struct timespec64 ts;
>
> + lockdep_assert_held(&dev->event_lock);
> +
> ktime_get_ts64(&ts);
>
> udev->buff[udev->head] = (struct input_event) {
> @@ -147,6 +151,7 @@ static void uinput_request_release_slot(struct uinput_device *udev,
> static int uinput_request_send(struct uinput_device *udev,
> struct uinput_request *request)
> {
> + unsigned long flags;
> int retval = 0;
>
> spin_lock(&udev->state_lock);
> @@ -160,7 +165,9 @@ static int uinput_request_send(struct uinput_device *udev,
> * Tell our userspace application about this new request
> * by queueing an input event.
> */
> + spin_lock_irqsave(&udev->dev->event_lock, flags);
> uinput_dev_event(udev->dev, EV_UINPUT, request->code, request->id);
> + spin_unlock_irqrestore(&udev->dev->event_lock, flags);
>
> out:
> spin_unlock(&udev->state_lock);
> --
> 2.53.0.1213.gd9a14994de-goog
>
>
> --
> Dmitry
Applied on top of my v2 patch, built and tested with Flydigi Vader 5
controller under Wine (ELDEN RING, Resident Evil Requiem) -- no issues observed.
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* Re: [PATCH v3] Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()
From: Dmitry Torokhov @ 2026-04-08 16:53 UTC (permalink / raw)
To: pip-izony
Cc: Kyungtae Kim, Sanghoon Choi, Dan Carpenter, linux-input,
linux-kernel
In-Reply-To: <20251221211442.841549-2-eeodqql09@gmail.com>
Hi,
On Sun, Dec 21, 2025 at 04:14:42PM -0500, pip-izony wrote:
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> The `ims_pcu_process_data()` processes incoming URB data byte by byte.
> However, it fails to check if the `read_pos` index exceeds
> IMS_PCU_BUF_SIZE.
>
> If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE,
> `read_pos` will increment indefinitely. Moreover, since `read_pos` is
> located immediately after `read_buf`, the attacker can overwrite
> `read_pos` itself to arbitrarily control the index.
>
> This manipulated `read_pos` is subsequently used in
> `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a
> heap buffer overflow.
>
> Specifically, an attacker can overwrite the `cmd_done.wait.head` located
> at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`.
> Consequently, when the driver calls `complete(&pcu->cmd_done)`, it
> triggers a control flow hijack by using the manipulated pointer.
>
> Fix this by adding a bounds check for `read_pos` before writing to
> `read_buf`. If the packet is too long, discard it, log a warning,
> and reset the parser state.
>
> Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver")
> Co-developed-by: Sanghoon Choi <csh0052@gmail.com>
> Signed-off-by: Sanghoon Choi <csh0052@gmail.com>
> Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
> ---
> v1 -> v2: Add warning and reset the state of the parser for bad packet
> v2 -> v3: Add co-author information
>
> drivers/input/misc/ims-pcu.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index 4581f1c53644..c98ef71c841e 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -450,6 +450,16 @@ static void ims_pcu_process_data(struct ims_pcu *pcu, struct urb *urb)
> continue;
>
> if (pcu->have_dle) {
> + if (pcu->read_pos >= IMS_PCU_BUF_SIZE) {
> + dev_warn(pcu->dev,
> + "Packet too long (%d bytes), discarding\n",
> + pcu->read_pos);
> + pcu->have_stx = false;
> + pcu->have_dle = false;
> + pcu->read_pos = 0;
Here and in the other place we also need to reset checksum, otherwise a
valid packet might get rejected.
I factored out the code resetting packet state and applied, thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Dmitry Torokhov @ 2026-04-08 16:59 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Frattaroli, Krzysztof Kozlowski, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Heiko Stuebner, kernel,
linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20251217133440.GA724723-robh@kernel.org>
On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > property. This makes it impossible to model devices that have ADC inputs
> > > > that should generate switch events.
> > >
> > > The solution is to use unevaluatedProps instead, which also allows
> > > dropping other properties.
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > >
> >
> > Hi Krzysztof,
> >
> > to understand the motivation behind this suggestion correctly:
> > are the "linux," vendor prefixed properties, especially with regards
> > to key codes, generally a bit of a thorn in the side of DT bindings
> > maintainers?
>
> Not really. Most have existed for decades. New ones get extra scrutiny
> and often end up dropping the linux prefix.
>
> > I'd imagine so since they technically tie the DT to a specific OS
> > kernel (though of course, others are free to translate those key
> > codes). And the whole idea of configuring which code is emitted
> > from something is basically abusing DT for configuring software
> > rather than describing hardware.
> >
> > I'm mainly interested because this is a thought that has been in
> > the back of my mind for a while now, and I'm curious if the DT
> > binding maintainers happen to have arrived at the same impassé,
> > where linux,input-type et al abuse the DT model for something we
> > would tell any other vendor not to abuse it for, but no better
> > solution exists right now to achieve the same thing.
>
> Not sure what the BSDs do here. It's never come up that I remember. Best
> I can tell is they just make it a userspace problem. So every possible
> keyboard needs a keymap file. Though I'm not sure how that would work
> with GPIO keys as you don't really have a scan code.
Is there an update for this binding or should I apply the current
version? I am OK with the driver changes...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Dmitry Torokhov @ 2026-04-08 17:07 UTC (permalink / raw)
To: Mohamad Raizudeen; +Cc: kees, linux-input, linux-kernel
In-Reply-To: <20260408162849.4639-1-raizudeen.kerneldev@gmail.com>
Hi Mohamad,
On Wed, Apr 08, 2026 at 09:58:47PM +0530, Mohamad Raizudeen wrote:
> The current implementation restarts the scan from the beginning after
> each disconnection(goto start_over) because serio_disconnect_port() may
> delete the current list entry. This results in O(n^2) worst case
> behaviour.
The "big O" notation only makes sense when numbers are big. Here we are
dealing with 6 serio ports max (1 KBC, 4xMUX, 1 Synaptics pass-through)
unless you have a serial port expander and hooked up a few ports there.
But still, the number if very limited.
>
> Replace with a two-phase approach:
>
> 1.Collect only top-level ports bound to the driver(skip those whose parent is also bound to the same driver) into a
> temporary list.
We do not have such setups at the moment, but what about parent's
parent's parent?
>
> 2.Process each collected port once, moving it back to serio_list first to maintain invariants expected by serio_destroy_port().
>
> This eliminates the restart loop, reduces complexity from O(n^2) to O(n)
> and avoids use-after-free by never collecting child ports separately.
Could you explain more about the use-after-free scenario?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] hid: wacom: add new usb id to device table
From: Roi L @ 2026-04-08 17:09 UTC (permalink / raw)
To: ping.cheng; +Cc: jason.gerecke, linux-input, Roi L
This adds the USB Device ID of Wacom CTL-4100 to the device ID
table.
Signed-off-by: Roi L <roeilev321_@outlook.com>
---
drivers/hid/wacom_wac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index da1f0ea85625..100f0ef03d1d 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -5116,6 +5116,7 @@ const struct hid_device_id wacom_ids[] = {
{ BT_DEVICE_WACOM(0x361) },
{ BT_DEVICE_WACOM(0x377) },
{ BT_DEVICE_WACOM(0x379) },
+ { USB_DEVICE_WACOM(0x374) },
{ USB_DEVICE_WACOM(0x37A) },
{ USB_DEVICE_WACOM(0x37B) },
{ BT_DEVICE_WACOM(0x393) },
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Nicolas Frattaroli @ 2026-04-08 17:11 UTC (permalink / raw)
To: Rob Herring, Dmitry Torokhov
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner, kernel, linux-input,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <adaJOEZHHmvZM_cB@google.com>
On Wednesday, 8 April 2026 18:59:08 Central European Summer Time Dmitry Torokhov wrote:
> On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> > On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > > property. This makes it impossible to model devices that have ADC inputs
> > > > > that should generate switch events.
> > > >
> > > > The solution is to use unevaluatedProps instead, which also allows
> > > > dropping other properties.
> > > >
> > > > Best regards,
> > > > Krzysztof
> > > >
> > > >
> > >
> > > Hi Krzysztof,
> > >
> > > to understand the motivation behind this suggestion correctly:
> > > are the "linux," vendor prefixed properties, especially with regards
> > > to key codes, generally a bit of a thorn in the side of DT bindings
> > > maintainers?
> >
> > Not really. Most have existed for decades. New ones get extra scrutiny
> > and often end up dropping the linux prefix.
> >
> > > I'd imagine so since they technically tie the DT to a specific OS
> > > kernel (though of course, others are free to translate those key
> > > codes). And the whole idea of configuring which code is emitted
> > > from something is basically abusing DT for configuring software
> > > rather than describing hardware.
> > >
> > > I'm mainly interested because this is a thought that has been in
> > > the back of my mind for a while now, and I'm curious if the DT
> > > binding maintainers happen to have arrived at the same impassé,
> > > where linux,input-type et al abuse the DT model for something we
> > > would tell any other vendor not to abuse it for, but no better
> > > solution exists right now to achieve the same thing.
> >
> > Not sure what the BSDs do here. It's never come up that I remember. Best
> > I can tell is they just make it a userspace problem. So every possible
> > keyboard needs a keymap file. Though I'm not sure how that would work
> > with GPIO keys as you don't really have a scan code.
>
> Is there an update for this binding or should I apply the current
> version? I am OK with the driver changes...
>
> Thanks.
>
>
I will send a new version that doesn't add the property but allows
unevaluatedProps instead. Thanks for reminding me.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox