* Re: [PATCH 1/6] Input: mms114 - fix touch indexing for MMS134S and MMS136
From: Dmitry Torokhov @ 2026-06-16 21:58 UTC (permalink / raw)
To: Bryam Vargas; +Cc: linux-input, Linus Walleij, linux-kernel
In-Reply-To: <20260616070529.156342-1-hexlabsecurity@proton.me>
Hi Bryam,
On Tue, Jun 16, 2026 at 07:05:34AM +0000, Bryam Vargas wrote:
> Hi Dmitry,
>
> The indexing fix looks correct -- deriving the byte offset from event_size
> instead of leaning on sizeof(struct mms114_touch) is the right call, and the
> cast is fine since the struct is __packed (no alignment issue at the 6-byte
> stride, and the consumers only touch bytes 0..5).
>
> Two things that might be worth folding into the series:
>
> 1) Fixes: tag. The 6-byte event path for MMS136 -- and therefore this
> stride-vs-index mismatch -- predates ab108678195f. It was introduced in
>
> 53fefdd1d3a3 ("Input: mms114 - support MMS136")
>
> which added MMS136_EVENT_SIZE and the "packet_size / MMS136_EVENT_SIZE"
> branch while the loop already indexed with the 8-byte struct stride;
> ab108678195f ("support MMS134S") only extended that branch to MMS134S.
> So MMS136 hardware has mis-parsed multi-touch since v5.13. Tagging
>
> Fixes: 53fefdd1d3a3 ("Input: mms114 - support MMS136")
>
> (in addition to, or instead of, ab108678195f) lets stable pick it up for
> the MMS136 range as well.
Thanks, I'll update the tag.
>
> 2) Unbounded packet_size. Since 1/6 already rewrites this handler: packet_size
> comes straight from the device's PACKET_SIZE register (a single byte, so
> 1..255 after the "<= 0" guard) and is then used unclamped both as the read
> length
>
> __mms114_read_reg(data, MMS114_INFORMATION, packet_size, (u8 *)touch);
>
> into the 80-byte touch[MMS114_MAX_TOUCH] stack buffer, and as the divisor
> for touch_size -- which is never bounded by MMS114_MAX_TOUCH. A device that
> reports packet_size > 80 overflows the stack buffer on the read, and even
> with the indexing fix the loop still walks past it (touch_size > 10). A
> one-liner before the division closes both:
>
> if (packet_size <= 0)
> goto out;
> + packet_size = min_t(int, packet_size, sizeof(touch));
>
> This one is pre-existing -- the unbounded read goes back to the original
> driver -- so it is really a separate patch in the series rather than part
> of the indexing fix, but it seemed worth raising while the code is in
> flight.
This is fixed by the patch you sent earlier, right? It's been applied so
I did not send it out again with the series.
Thank you for looking at this, please do not hesitate to add your
Reviewed-by to any patches that you are satisfied with.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: Dmitry Torokhov @ 2026-06-16 21:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <CAPVz0n2fnM6zYtP9bCtsY9mcLdce_R+1UPmMo0o4JRgjnhuhKA@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:25:25AM +0300, Svyatoslav Ryhel wrote:
> вт, 16 черв. 2026 р. о 07:26 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Thu, May 28, 2026 at 08:32:00AM +0300, Svyatoslav Ryhel wrote:
> > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > >
> > > Add support for multimedia top button row of ASUS Transformer's Mobile
> > > Dock keyboard. Driver is made that function keys (F1-F12) are used by
> > > default which suits average Linux use better and with pressing
> > > ScreenLock + AltGr function keys layout is switched to multimedia keys.
> > > Since this only modifies codes sent by asus-ec-keys it doesn't affect
> > > normal keyboards at all.
> >
> > I think using input handler to intercept ScreenLock + AltGr is quite
> > awkward. I think this also passes the original key events (unless you
> > make it a filter not a regular handler).
> >
> > I do not see benefit for reacting to AltGr+ScreenLock on other keyboards
> > to activate the special mode on this one. So given the fact that you
> > already mange the data stream when you split it into "serio" ports,
> > maybe just intercept this key combo right there and create the input
> > device and signal input events right there?
> >
>
> Though it seems awkward at a first glance, media keys are integrated
> with a standard keyboard in a detachable dock. It is highly unlikely
> that media keys will be used with a different keyboard then the one
> that is integrated with dock. Additionally, the ScreenLock key has a
> code specific to this driver and is not in general use, so even if any
> standard keyboard has AltGr but none has ScreenLock specific to this
> driver except the dock itself. Handler is also set as observer so it
> should not interfere with work of other input devices.
I am not concerned about it interfering with other drivers, I am
concerned about it unnecessarily connecting to unrelated devices
(anything that declares EV_KEY).
Again, I think having input handler is not appropriate here. I would
fold this patch into the patch that introduces the 2 serio ports,
enhanced the data stream analysis to detect your key combo, and then
report through this new input device. You do not need to have the round
trip through atkbd and the new input handler for this.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: sony: use dedicated raw_event() handlers in sony_raw_event()
From: sashiko-bot @ 2026-06-16 21:08 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260616205042.6671-3-rosalie@mailbox.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Race Condition / Null Pointer Dereference in RB4_GUITAR_PS5 initialization.
- [High] Sleeping in Atomic Context in rb3_pro_instrument_raw_event.
--
commit ce2aa734b3cbe3b5ae8274fe7a1ef679e83470b5
Author: Rosalie Wanders <rosalie@mailbox.org>
Subject: HID: sony: use dedicated raw_event() handlers in sony_raw_event()
This commit simplifies how the sony driver processes raw events by introducing
dedicated handler function pointers inside the sony_sc structure. The
appropriate handler is now assigned during device configuration based on
hardware quirks.
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index 315343415e8f1..7da1fd1e52fea 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
[ ... ]
> +static int rb3_pro_instrument_raw_event(struct sony_sc *sc, u8 *rd, int size)
> +{
> + /* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
> + * sending full reports, and 0x02 when only sending navigation.
> + */
> + if (size < 25 || rd[24] != 0x02)
> + return 0;
> +
> + /* Only attempt to enable full report every 8 seconds */
> + if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
> + sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
> + rb3_pro_instrument_enable_full_report(sc);
[Severity: High]
This is a pre-existing issue, but can this call sequence sleep in an atomic
context?
The raw event handler usually executes in an atomic context, such as a USB URB
completion handler. This path calls rb3_pro_instrument_enable_full_report()
which allocates memory using GFP_KERNEL and issues a synchronous USB control
transfer via hid_hw_raw_request().
Could calling these blocking functions in atomic context trigger a might_sleep
warning or lead to a kernel panic?
> + }
> +
> + return 0;
> +}
[ ... ]
> -static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
> +static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
> {
> u8 charging_status;
> u8 battery_data;
> @@ -1094,6 +1150,9 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
> u8 battery_status;
> unsigned long flags;
>
> + if (unlikely(size != 64 || rd[0] != 0x01))
> + return 0;
> +
> /*
> * Rock Band 4 PS5 guitars have whammy and
> * tilt functionality, they're located at
[Severity: High]
This isn't a bug introduced by this patch, but could this handler dereference
a null pointer if an event arrives during device initialization?
Looking at sony_input_configured(), the raw event handler for the guitar is
registered, and hid_hw_open() is called because the device has battery support.
However, sc->input_dev is not assigned until after these initialization steps.
If the device sends a report immediately after the hardware connection opens,
would this event handler trigger and attempt to call input_report_abs() using
a null sc->input_dev pointer?
> @@ -1138,65 +1197,22 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
> spin_unlock_irqrestore(&sc->lock, flags);
>
> input_sync(sc->input_dev);
> + return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616205042.6671-2-rosalie@mailbox.org?part=1
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: sony: remove unneeded which argument from sony_schedule_work()
From: sashiko-bot @ 2026-06-16 21:04 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616205042.6671-5-rosalie@mailbox.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unbalanced `hid_hw_close()` calls lead to `hdev->ll_open_count` underflow.
--
commit 45be0bef88ed1ff7df93b4882f4865bcd24126c9
Author: Rosalie Wanders <rosalie@mailbox.org>
HID: sony: remove unneeded which argument from sony_schedule_work()
The sony_worker enum only had a single member, so removing it simplifies
sony_schedule_work().
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index aa5e65a13ecbc..9014c1db1ba5c 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
[ ... ]
> @@ -1859,7 +1849,7 @@ static int sony_play_effect(struct input_dev *dev, void *data,
> sc->left = effect->u.rumble.strong_magnitude / 256;
> sc->right = effect->u.rumble.weak_magnitude / 256;
>
> - sony_schedule_work(sc, SONY_WORKER_STATE);
> + sony_schedule_work(sc);
> return 0;
> }
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem with
unbalanced hid_hw_close() calls leading to an underflow of the open count
in this driver.
In sony_input_configured(), hid_hw_open() is only called if the device
supports battery reporting. However, both the error path in
sony_input_configured() and sony_remove() unconditionally call
hid_hw_close():
drivers/hid/hid-sony.c:sony_input_configured() {
...
err_close:
hid_hw_close(hdev);
...
}
drivers/hid/hid-sony.c:sony_remove() {
...
hid_hw_close(hdev);
...
}
For devices without battery support (such as motion controllers or
buzz controllers), does this cause an unbalanced close that steals an active
userspace open reference or underflows the open count?
If the force feedback initialization fails for a motion controller over USB,
would the error path execute an unbalanced hid_hw_close() and corrupt the
lifecycle state of the HID device, breaking the low-level driver open and
close state machine?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616205042.6671-2-rosalie@mailbox.org?part=3
^ permalink raw reply
* Re: [PATCH v2 0/4] HID: sony: more cleanup
From: Jiri Kosina @ 2026-06-16 20:55 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
On Tue, 16 Jun 2026, Rosalie Wanders wrote:
> This series cleans up hid-sony by utilizing modern helper functions.
>
> v2: the dependent patches have been included in this series
Thanks a lot for this, Rosalie!
Your patches have always been a little bit confusing to me when it came to
inter-dependencies ... now that this is sent as a series, I can easily
apply it on top altogether when the merge window is over.
>
> Rosalie Wanders (4):
> HID: sony: use dedicated raw_event() handlers in sony_raw_event()
> HID: sony: use guard() and scoped_guard()
> HID: sony: remove unneeded which argument from sony_schedule_work()
> HID: sony: use devm_kasprintf()
Thanks again,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2 4/4] HID: sony: use devm_kasprintf()
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
Using devm_kasprintf() makes the code less error-prone.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-sony.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index ff681ebc76ce..253fff4066eb 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1272,8 +1272,6 @@ static int sony_mapping(struct hid_device *hdev, struct hid_input *hi,
static int sony_register_touchpad(struct sony_sc *sc, int touch_count,
int w, int h, int touch_major, int touch_minor, int orientation)
{
- size_t name_sz;
- char *name;
int ret;
sc->touchpad = devm_input_allocate_device(&sc->hdev->dev);
@@ -1295,12 +1293,10 @@ static int sony_register_touchpad(struct sony_sc *sc, int touch_count,
* a suffix. Other devices which were added later like Sony TV remotes
* inhirited this suffix.
*/
- name_sz = strlen(sc->hdev->name) + sizeof(TOUCHPAD_SUFFIX);
- name = devm_kzalloc(&sc->hdev->dev, name_sz, GFP_KERNEL);
- if (!name)
+ sc->touchpad->name = devm_kasprintf(&sc->hdev->dev, GFP_KERNEL, "%s" TOUCHPAD_SUFFIX,
+ sc->hdev->name);
+ if (!sc->touchpad->name)
return -ENOMEM;
- snprintf(name, name_sz, "%s" TOUCHPAD_SUFFIX, sc->hdev->name);
- sc->touchpad->name = name;
/* We map the button underneath the touchpad to BTN_LEFT. */
__set_bit(EV_KEY, sc->touchpad->evbit);
@@ -1337,8 +1333,6 @@ static int sony_register_touchpad(struct sony_sc *sc, int touch_count,
static int sony_register_sensors(struct sony_sc *sc)
{
- size_t name_sz;
- char *name;
int ret;
sc->sensor_dev = devm_input_allocate_device(&sc->hdev->dev);
@@ -1357,12 +1351,10 @@ static int sony_register_sensors(struct sony_sc *sc)
/* Append a suffix to the controller name as there are various
* DS4 compatible non-Sony devices with different names.
*/
- name_sz = strlen(sc->hdev->name) + sizeof(SENSOR_SUFFIX);
- name = devm_kzalloc(&sc->hdev->dev, name_sz, GFP_KERNEL);
- if (!name)
+ sc->sensor_dev->name = devm_kasprintf(&sc->hdev->dev, GFP_KERNEL, "%s" SENSOR_SUFFIX,
+ sc->hdev->name);
+ if (!sc->sensor_dev->name)
return -ENOMEM;
- snprintf(name, name_sz, "%s" SENSOR_SUFFIX, sc->hdev->name);
- sc->sensor_dev->name = name;
if (sc->quirks & SIXAXIS_CONTROLLER) {
/* For the DS3 we only support the accelerometer, which works
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/4] HID: sony: remove unneeded which argument from sony_schedule_work()
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
The sony_worker enum only had a single member, so removing it simplifies
sony_schedule_work().
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-sony.c | 26 ++++++++------------------
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 84df55c3cbe1..ff681ebc76ce 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -523,10 +523,6 @@ static DEFINE_SPINLOCK(sony_dev_list_lock);
static LIST_HEAD(sony_device_list);
static DEFINE_IDA(sony_device_id_allocator);
-enum sony_worker {
- SONY_WORKER_STATE
-};
-
struct sony_sc {
spinlock_t lock;
struct list_head list_node;
@@ -569,17 +565,11 @@ struct sony_sc {
static void sony_set_leds(struct sony_sc *sc);
-static inline void sony_schedule_work(struct sony_sc *sc,
- enum sony_worker which)
+static inline void sony_schedule_work(struct sony_sc *sc)
{
- switch (which) {
- case SONY_WORKER_STATE:
- scoped_guard(spinlock_irqsave, &sc->lock) {
- if (!sc->defer_initialization && sc->state_worker_initialized)
- schedule_work(&sc->state_worker);
- }
- break;
- }
+ guard(spinlock_irqsave)(&sc->lock);
+ if (!sc->defer_initialization && sc->state_worker_initialized)
+ schedule_work(&sc->state_worker);
}
static void ghl_magic_poke_cb(struct urb *urb)
@@ -1211,7 +1201,7 @@ static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
if (unlikely(sc->defer_initialization)) {
sc->defer_initialization = 0;
- sony_schedule_work(sc, SONY_WORKER_STATE);
+ sony_schedule_work(sc);
}
return 0;
@@ -1520,7 +1510,7 @@ static void buzz_set_leds(struct sony_sc *sc)
static void sony_set_leds(struct sony_sc *sc)
{
if (!(sc->quirks & BUZZ_CONTROLLER))
- sony_schedule_work(sc, SONY_WORKER_STATE);
+ sony_schedule_work(sc);
else
buzz_set_leds(sc);
}
@@ -1631,7 +1621,7 @@ static int sony_led_blink_set(struct led_classdev *led, unsigned long *delay_on,
new_off != drv_data->led_delay_off[n]) {
drv_data->led_delay_on[n] = new_on;
drv_data->led_delay_off[n] = new_off;
- sony_schedule_work(drv_data, SONY_WORKER_STATE);
+ sony_schedule_work(drv_data);
}
return 0;
@@ -1859,7 +1849,7 @@ static int sony_play_effect(struct input_dev *dev, void *data,
sc->left = effect->u.rumble.strong_magnitude / 256;
sc->right = effect->u.rumble.weak_magnitude / 256;
- sony_schedule_work(sc, SONY_WORKER_STATE);
+ sony_schedule_work(sc);
return 0;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] HID: sony: use guard() and scoped_guard()
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
This replaces the spin_lock_irqsave() and spin_unlock_irqrestore() calls
with the RAII guard() and scoped_guard().
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-sony.c | 62 ++++++++++++++++++------------------------
1 file changed, 26 insertions(+), 36 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 2d9a5261b63f..84df55c3cbe1 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -29,6 +29,7 @@
* There will be no PIN request from the device.
*/
+#include <linux/cleanup.h>
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
@@ -571,14 +572,12 @@ static void sony_set_leds(struct sony_sc *sc);
static inline void sony_schedule_work(struct sony_sc *sc,
enum sony_worker which)
{
- unsigned long flags;
-
switch (which) {
case SONY_WORKER_STATE:
- spin_lock_irqsave(&sc->lock, flags);
- if (!sc->defer_initialization && sc->state_worker_initialized)
- schedule_work(&sc->state_worker);
- spin_unlock_irqrestore(&sc->lock, flags);
+ scoped_guard(spinlock_irqsave, &sc->lock) {
+ if (!sc->defer_initialization && sc->state_worker_initialized)
+ schedule_work(&sc->state_worker);
+ }
break;
}
}
@@ -951,7 +950,6 @@ static const u8 *sony_report_fixup(struct hid_device *hdev, u8 *rdesc,
static int sixaxis_raw_event(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;
@@ -999,10 +997,10 @@ static int sixaxis_raw_event(struct sony_sc *sc, u8 *rd, int size)
battery_status = POWER_SUPPLY_STATUS_DISCHARGING;
}
- spin_lock_irqsave(&sc->lock, flags);
- sc->battery_capacity = battery_capacity;
- sc->battery_status = battery_status;
- spin_unlock_irqrestore(&sc->lock, flags);
+ scoped_guard(spinlock_irqsave, &sc->lock) {
+ sc->battery_capacity = battery_capacity;
+ sc->battery_status = battery_status;
+ }
if (sc->quirks & SIXAXIS_CONTROLLER) {
int val;
@@ -1148,7 +1146,6 @@ static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
u8 battery_data;
u8 battery_capacity;
u8 battery_status;
- unsigned long flags;
if (unlikely(size != 64 || rd[0] != 0x01))
return 0;
@@ -1191,10 +1188,10 @@ static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
break;
}
- spin_lock_irqsave(&sc->lock, flags);
- sc->battery_capacity = battery_capacity;
- sc->battery_status = battery_status;
- spin_unlock_irqrestore(&sc->lock, flags);
+ scoped_guard(spinlock_irqsave, &sc->lock) {
+ sc->battery_capacity = battery_capacity;
+ sc->battery_status = battery_status;
+ }
input_sync(sc->input_dev);
return 0;
@@ -1885,15 +1882,14 @@ static int sony_battery_get_property(struct power_supply *psy,
union power_supply_propval *val)
{
struct sony_sc *sc = power_supply_get_drvdata(psy);
- unsigned long flags;
int ret = 0;
u8 battery_capacity;
int battery_status;
- spin_lock_irqsave(&sc->lock, flags);
- battery_capacity = sc->battery_capacity;
- battery_status = sc->battery_status;
- spin_unlock_irqrestore(&sc->lock, flags);
+ scoped_guard(spinlock_irqsave, &sc->lock) {
+ battery_capacity = sc->battery_capacity;
+ battery_status = sc->battery_status;
+ }
switch (psp) {
case POWER_SUPPLY_PROP_PRESENT:
@@ -1975,10 +1971,9 @@ static inline int sony_compare_connection_type(struct sony_sc *sc0,
static int sony_check_add_dev_list(struct sony_sc *sc)
{
struct sony_sc *entry;
- unsigned long flags;
int ret;
- spin_lock_irqsave(&sony_dev_list_lock, flags);
+ guard(spinlock_irqsave)(&sony_dev_list_lock);
list_for_each_entry(entry, &sony_device_list, list_node) {
ret = memcmp(sc->mac_address, entry->mac_address,
@@ -1992,26 +1987,23 @@ static int sony_check_add_dev_list(struct sony_sc *sc)
"controller with MAC address %pMR already connected\n",
sc->mac_address);
}
- goto unlock;
+ goto out;
}
}
ret = 0;
list_add(&(sc->list_node), &sony_device_list);
-unlock:
- spin_unlock_irqrestore(&sony_dev_list_lock, flags);
+out:
return ret;
}
static void sony_remove_dev_list(struct sony_sc *sc)
{
- unsigned long flags;
-
if (sc->list_node.next) {
- spin_lock_irqsave(&sony_dev_list_lock, flags);
- list_del(&(sc->list_node));
- spin_unlock_irqrestore(&sony_dev_list_lock, flags);
+ scoped_guard(spinlock_irqsave, &sony_dev_list_lock) {
+ list_del(&(sc->list_node));
+ }
}
}
@@ -2145,12 +2137,10 @@ static inline void sony_init_output_report(struct sony_sc *sc,
static inline void sony_cancel_work_sync(struct sony_sc *sc)
{
- unsigned long flags;
-
if (sc->state_worker_initialized) {
- spin_lock_irqsave(&sc->lock, flags);
- sc->state_worker_initialized = 0;
- spin_unlock_irqrestore(&sc->lock, flags);
+ scoped_guard(spinlock_irqsave, &sc->lock) {
+ sc->state_worker_initialized = 0;
+ }
cancel_work_sync(&sc->state_worker);
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/4] HID: sony: use dedicated raw_event() handlers in sony_raw_event()
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
This commit changes the way sony_raw_event() works by adding a function
pointer to a raw_event() handler in the sc struct instead of manually
checking the quirk in order to call the right function, this simplifies
the sony_raw_event() function alongside making the raw_event() handlers
more self-contained, thus making the code more readable.
The raw_event() handler should be configured using the new
sony_init_raw_event_handler() function in sony_input_configured(), where
we already check for quirks and apply device specific workarounds.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-sony.c | 145 +++++++++++++++++++++++++----------------
1 file changed, 90 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index e75246d29e16..2d9a5261b63f 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -81,6 +81,7 @@
#define SONY_FF_SUPPORT (SIXAXIS_CONTROLLER | MOTION_CONTROLLER)
#define SONY_BT_DEVICE (SIXAXIS_CONTROLLER_BT | MOTION_CONTROLLER_BT | NAVIGATION_CONTROLLER_BT)
#define NSG_MRXU_REMOTE (NSG_MR5U_REMOTE_BT | NSG_MR7U_REMOTE_BT)
+#define RB4_GUITAR_PS4 (RB4_GUITAR_PS4_USB | RB4_GUITAR_PS4_BT)
#define MAX_LEDS 4
#define NSG_MRXU_MAX_X 1667
@@ -534,6 +535,7 @@ struct sony_sc {
struct input_dev *sensor_dev;
struct led_classdev *leds[MAX_LEDS];
unsigned long quirks;
+ int (*raw_event)(struct sony_sc *sc, u8 *rd, int size);
struct work_struct state_worker;
void (*send_output_report)(struct sony_sc *sc);
struct power_supply *battery;
@@ -946,7 +948,7 @@ static const u8 *sony_report_fixup(struct hid_device *hdev, u8 *rdesc,
return rdesc;
}
-static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int sixaxis_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
static const u8 sixaxis_battery_capacity[] = { 0, 1, 25, 50, 75, 100 };
unsigned long flags;
@@ -955,6 +957,31 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
u8 battery_capacity;
int battery_status;
+ if (unlikely(size != 49 || rd[0] != 0x01))
+ return 0;
+
+ if (sc->quirks & SIXAXIS_CONTROLLER) {
+ /*
+ * When connected via Bluetooth the Sixaxis occasionally sends
+ * a report with the second byte 0xff and the rest zeroed.
+ *
+ * This report does not reflect the actual state of the
+ * controller must be ignored to avoid generating false input
+ * events.
+ */
+ if (rd[1] == 0xff)
+ return -EINVAL;
+
+ /*
+ * Sixaxis HID report has acclerometers/gyro with MSByte first, this
+ * has to be BYTE_SWAPPED before passing up to joystick interface
+ */
+ swap(rd[41], rd[42]);
+ swap(rd[43], rd[44]);
+ swap(rd[45], rd[46]);
+ swap(rd[47], rd[48]);
+ }
+
/*
* The sixaxis is charging if the battery value is 0xee
* and it is fully charged if the value is 0xef.
@@ -993,13 +1020,18 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_sync(sc->sensor_dev);
}
+
+ return 0;
}
-static void nsg_mrxu_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int nsg_mrxu_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
int n, offset, relx, rely;
u8 active;
+ if (unlikely(size < 12 || rd[0] != 0x02))
+ return 0;
+
/*
* The NSG-MRxU multi-touch trackpad data starts at offset 1 and
* the touch-related data starts at offset 2.
@@ -1067,10 +1099,33 @@ static void nsg_mrxu_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_mt_sync_frame(sc->touchpad);
input_sync(sc->touchpad);
+ return 0;
+}
+
+static int rb3_pro_instrument_raw_event(struct sony_sc *sc, u8 *rd, int size)
+{
+ /* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
+ * sending full reports, and 0x02 when only sending navigation.
+ */
+ if (size < 25 || rd[24] != 0x02)
+ return 0;
+
+ /* Only attempt to enable full report every 8 seconds */
+ if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
+ sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
+ rb3_pro_instrument_enable_full_report(sc);
+ }
+
+ return 0;
}
-static void rb4_ps4_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int rb4_ps4_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
+ const int expected_size = (sc->quirks & RB4_GUITAR_PS4_BT) ? 78 : 64;
+
+ if (unlikely(size != expected_size || rd[0] != 0x01))
+ return 0;
+
/*
* Rock Band 4 PS4 guitars have whammy and
* tilt functionality, they're located at
@@ -1084,9 +1139,10 @@ static void rb4_ps4_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_report_abs(sc->input_dev, ABS_RZ, rd[45]);
input_sync(sc->input_dev);
+ return 0;
}
-static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
u8 charging_status;
u8 battery_data;
@@ -1094,6 +1150,9 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
u8 battery_status;
unsigned long flags;
+ if (unlikely(size != 64 || rd[0] != 0x01))
+ return 0;
+
/*
* Rock Band 4 PS5 guitars have whammy and
* tilt functionality, they're located at
@@ -1138,65 +1197,22 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
spin_unlock_irqrestore(&sc->lock, flags);
input_sync(sc->input_dev);
+ return 0;
}
static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
u8 *rd, int size)
{
struct sony_sc *sc = hid_get_drvdata(hdev);
+ int ret;
- /*
- * Sixaxis HID report has acclerometers/gyro with MSByte first, this
- * has to be BYTE_SWAPPED before passing up to joystick interface
- */
- if ((sc->quirks & SIXAXIS_CONTROLLER) && rd[0] == 0x01 && size == 49) {
- /*
- * When connected via Bluetooth the Sixaxis occasionally sends
- * a report with the second byte 0xff and the rest zeroed.
- *
- * This report does not reflect the actual state of the
- * controller must be ignored to avoid generating false input
- * events.
- */
- if (rd[1] == 0xff)
- return -EINVAL;
-
- swap(rd[41], rd[42]);
- swap(rd[43], rd[44]);
- swap(rd[45], rd[46]);
- swap(rd[47], rd[48]);
-
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & MOTION_CONTROLLER_BT) && rd[0] == 0x01 && size == 49) {
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & NAVIGATION_CONTROLLER) && rd[0] == 0x01 && size == 49) {
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & NSG_MRXU_REMOTE) && rd[0] == 0x02 && size >= 12) {
- nsg_mrxu_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS4_USB) && rd[0] == 0x01 && size == 64) {
- rb4_ps4_guitar_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS4_BT) && rd[0] == 0x01 && size == 78) {
- rb4_ps4_guitar_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS5) && rd[0] == 0x01 && size == 64) {
- rb4_ps5_guitar_parse_report(sc, rd, size);
- return 1;
- }
-
- /* 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_PRO_INSTRUMENT) && size >= 25 && 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 + secs_to_jiffies(8);
- rb3_pro_instrument_enable_full_report(sc);
- }
+ if (sc->raw_event) {
+ ret = sc->raw_event(sc, rd, size);
+ if (unlikely(ret < 0))
+ return ret;
}
- if (sc->defer_initialization) {
+ if (unlikely(sc->defer_initialization)) {
sc->defer_initialization = 0;
sony_schedule_work(sc, SONY_WORKER_STATE);
}
@@ -1256,7 +1272,7 @@ static int sony_mapping(struct hid_device *hdev, struct hid_input *hi,
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))
+ if (sc->quirks & RB4_GUITAR_PS4)
return rb4_guitar_mapping(hdev, hi, field, usage, bit, max);
if (sc->quirks & RB4_GUITAR_PS5)
@@ -2110,6 +2126,12 @@ static void sony_release_device_id(struct sony_sc *sc)
}
}
+static inline void sony_init_raw_event_handler(struct sony_sc *sc,
+ int (*raw_event)(struct sony_sc *, u8 *, int))
+{
+ sc->raw_event = raw_event;
+}
+
static inline void sony_init_output_report(struct sony_sc *sc,
void (*send_output_report)(struct sony_sc *))
{
@@ -2185,6 +2207,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & NAVIGATION_CONTROLLER_BT) {
/*
@@ -2199,6 +2222,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & RB3_PRO_INSTRUMENT) {
/*
@@ -2213,6 +2237,8 @@ static int sony_input_configured(struct hid_device *hdev,
*/
hdev->quirks |= HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP;
hdev->quirks |= HID_QUIRK_SKIP_OUTPUT_REPORT_ID;
+
+ sony_init_raw_event_handler(sc, rb3_pro_instrument_raw_event);
} else if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
/*
* The Sony Sixaxis does not handle HID Output Reports on the
@@ -2237,6 +2263,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & SIXAXIS_CONTROLLER_BT) {
/*
@@ -2258,6 +2285,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & NSG_MRXU_REMOTE) {
/*
@@ -2273,8 +2301,15 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, nsg_mrxu_raw_event);
} else if (sc->quirks & MOTION_CONTROLLER) {
+ if (sc->quirks & MOTION_CONTROLLER_BT)
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, motion_send_output_report);
+ } else if (sc->quirks & RB4_GUITAR_PS4) {
+ sony_init_raw_event_handler(sc, rb4_ps4_guitar_raw_event);
+ } else if (sc->quirks & RB4_GUITAR_PS5) {
+ sony_init_raw_event_handler(sc, rb4_ps5_guitar_raw_event);
}
if (sc->quirks & SONY_LED_SUPPORT) {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] HID: sony: more cleanup
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
This series cleans up hid-sony by utilizing modern helper functions.
v2: the dependent patches have been included in this series
Rosalie Wanders (4):
HID: sony: use dedicated raw_event() handlers in sony_raw_event()
HID: sony: use guard() and scoped_guard()
HID: sony: remove unneeded which argument from sony_schedule_work()
HID: sony: use devm_kasprintf()
drivers/hid/hid-sony.c | 245 +++++++++++++++++++++--------------------
1 file changed, 126 insertions(+), 119 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-16 20:30 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n26H2t=pi_C+t8jP_cWXGSa5pk=1cpTZtkBh3=RQsUk2g@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:45:25AM +0300, Svyatoslav Ryhel wrote:
>
> I have tested your code on my P895 and it works perfectly fine. Should
> I resend with these changes or you can integrate them while picking
> patchset?
I think there was an update requested by Rob for the bindings?
>
> Thank you for your suggestions and efforts!
Thank you for your patience.
--
Dmitry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 66725039f7090afe14c31bd259e2059a68f04023
From: kernel test robot @ 2026-06-16 20:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 66725039f7090afe14c31bd259e2059a68f04023 Input: mms114 - reject an oversized device packet size
elapsed time: 730m
configs tested: 292
configs skipped: 2
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 allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-9.5.0
arc randconfig-001-20260616 gcc-9.5.0
arc randconfig-002 gcc-9.5.0
arc randconfig-002-20260616 gcc-9.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm lpc18xx_defconfig clang-23
arm randconfig-001 gcc-9.5.0
arm randconfig-001-20260616 gcc-9.5.0
arm randconfig-002 gcc-9.5.0
arm randconfig-002-20260616 gcc-9.5.0
arm randconfig-003 gcc-9.5.0
arm randconfig-003-20260616 gcc-9.5.0
arm randconfig-004 gcc-9.5.0
arm randconfig-004-20260616 gcc-9.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260616 clang-23
arm64 randconfig-001-20260616 gcc-13.4.0
arm64 randconfig-001-20260617 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260616 clang-23
arm64 randconfig-002-20260616 gcc-13.4.0
arm64 randconfig-002-20260617 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260616 clang-23
arm64 randconfig-003-20260616 gcc-13.4.0
arm64 randconfig-003-20260617 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260616 clang-23
arm64 randconfig-004-20260616 gcc-13.4.0
arm64 randconfig-004-20260617 gcc-12.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260616 clang-23
csky randconfig-001-20260616 gcc-13.4.0
csky randconfig-001-20260617 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260616 clang-23
csky randconfig-002-20260616 gcc-13.4.0
csky randconfig-002-20260617 gcc-12.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260616 clang-23
hexagon randconfig-001-20260616 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260616 clang-23
hexagon randconfig-002-20260616 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260616 clang-22
i386 buildonly-randconfig-001-20260617 gcc-14
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260616 clang-22
i386 buildonly-randconfig-002-20260617 gcc-14
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260616 clang-22
i386 buildonly-randconfig-003-20260617 gcc-14
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260616 clang-22
i386 buildonly-randconfig-004-20260617 gcc-14
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260616 clang-22
i386 buildonly-randconfig-005-20260617 gcc-14
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260616 clang-22
i386 buildonly-randconfig-006-20260617 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260616 gcc-14
i386 randconfig-002-20260616 gcc-14
i386 randconfig-003-20260616 gcc-14
i386 randconfig-004-20260616 gcc-14
i386 randconfig-005-20260616 gcc-14
i386 randconfig-006-20260616 gcc-14
i386 randconfig-007-20260616 gcc-14
i386 randconfig-011 clang-22
i386 randconfig-011-20260616 clang-22
i386 randconfig-012 clang-22
i386 randconfig-012-20260616 clang-22
i386 randconfig-013 clang-22
i386 randconfig-013-20260616 clang-22
i386 randconfig-014 clang-22
i386 randconfig-014-20260616 clang-22
i386 randconfig-015 clang-22
i386 randconfig-015-20260616 clang-22
i386 randconfig-016 clang-22
i386 randconfig-016-20260616 clang-22
i386 randconfig-017 clang-22
i386 randconfig-017-20260616 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260616 clang-23
loongarch randconfig-001-20260616 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260616 clang-23
loongarch randconfig-002-20260616 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
m68k hp300_defconfig gcc-16.1.0
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 malta_kvm_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260616 clang-23
nios2 randconfig-001-20260616 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260616 clang-23
nios2 randconfig-002-20260616 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260616 gcc-8.5.0
parisc randconfig-001-20260617 gcc-15.2.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260616 gcc-8.5.0
parisc randconfig-002-20260617 gcc-15.2.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc mpc8315_rdb_defconfig clang-23
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260616 gcc-8.5.0
powerpc randconfig-001-20260617 gcc-15.2.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260616 gcc-8.5.0
powerpc randconfig-002-20260617 gcc-15.2.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260616 gcc-8.5.0
powerpc64 randconfig-001-20260617 gcc-15.2.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260616 gcc-8.5.0
powerpc64 randconfig-002-20260617 gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260616 gcc-16.1.0
riscv randconfig-001-20260617 gcc-16.1.0
riscv randconfig-002-20260616 gcc-16.1.0
riscv randconfig-002-20260617 gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260616 gcc-16.1.0
s390 randconfig-001-20260617 gcc-16.1.0
s390 randconfig-002-20260616 gcc-16.1.0
s390 randconfig-002-20260617 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001-20260616 gcc-16.1.0
sh randconfig-001-20260617 gcc-16.1.0
sh randconfig-002-20260616 gcc-16.1.0
sh randconfig-002-20260617 gcc-16.1.0
sh sh7785lcr_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-8.5.0
sparc randconfig-001-20260616 gcc-8.5.0
sparc randconfig-002 gcc-8.5.0
sparc randconfig-002-20260616 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-8.5.0
sparc64 randconfig-001-20260616 gcc-8.5.0
sparc64 randconfig-002 gcc-8.5.0
sparc64 randconfig-002-20260616 gcc-8.5.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-8.5.0
um randconfig-001-20260616 gcc-8.5.0
um randconfig-002 gcc-8.5.0
um randconfig-002-20260616 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260616 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260616 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260616 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260616 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260616 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260616 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260616 clang-22
x86_64 randconfig-001-20260617 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260616 clang-22
x86_64 randconfig-002-20260617 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260616 clang-22
x86_64 randconfig-003-20260617 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260616 clang-22
x86_64 randconfig-004-20260617 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260616 clang-22
x86_64 randconfig-005-20260617 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260616 clang-22
x86_64 randconfig-006-20260617 clang-22
x86_64 randconfig-011 clang-22
x86_64 randconfig-011-20260616 clang-22
x86_64 randconfig-011-20260616 gcc-14
x86_64 randconfig-012 clang-22
x86_64 randconfig-012-20260616 clang-22
x86_64 randconfig-012-20260616 gcc-14
x86_64 randconfig-013 clang-22
x86_64 randconfig-013-20260616 clang-22
x86_64 randconfig-014 clang-22
x86_64 randconfig-014-20260616 clang-22
x86_64 randconfig-015 clang-22
x86_64 randconfig-015-20260616 clang-22
x86_64 randconfig-016 clang-22
x86_64 randconfig-016-20260616 clang-22
x86_64 randconfig-016-20260616 gcc-14
x86_64 randconfig-071 gcc-13
x86_64 randconfig-071-20260616 gcc-13
x86_64 randconfig-071-20260616 gcc-14
x86_64 randconfig-072 gcc-13
x86_64 randconfig-072-20260616 gcc-13
x86_64 randconfig-072-20260616 gcc-14
x86_64 randconfig-073 gcc-13
x86_64 randconfig-073-20260616 gcc-13
x86_64 randconfig-073-20260616 gcc-14
x86_64 randconfig-074 gcc-13
x86_64 randconfig-074-20260616 gcc-13
x86_64 randconfig-074-20260616 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260616 gcc-13
x86_64 randconfig-075-20260616 gcc-14
x86_64 randconfig-076 gcc-13
x86_64 randconfig-076-20260616 gcc-13
x86_64 randconfig-076-20260616 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 allyesconfig clang-20
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260616 gcc-8.5.0
xtensa randconfig-002 gcc-8.5.0
xtensa randconfig-002-20260616 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Dmitry Torokhov @ 2026-06-16 19:22 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Fenglin Wu, linux-arm-msm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <eb693705-c0c3-427b-a924-5aa907fd65bb@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 12:25:55PM +0200, Konrad Dybcio wrote:
> On 6/16/26 12:08 PM, Fenglin Wu wrote:
> > Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
> > named as HAP530_HV. This module supports several play modes, including
> > DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
> > and hardware data handling logic. Currently, the driver provides support
> > for two play modes using the input force-feedback framework: FF_CONSTANT
> > effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
> > waveform for FIFO mode.
> >
> > Assisted-by: Claude:claude-4-6-sonnet
> > Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
>
> static inline
No, let compiler do its job and decide whether it should be inlined or
not.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: yealink - stop URB resubmission on completion error
From: Dmitry Torokhov @ 2026-06-16 19:17 UTC (permalink / raw)
To: Jie Wang
Cc: Henk Vergonet, linux-input, linux-kernel,
syzbot+039eab266c6321a174bd, syzkaller-bugs
In-Reply-To: <20260616110440.1073059-1-jie.wang@intel.com>
Hi Jie,
On Tue, Jun 16, 2026 at 11:04:40AM +0000, Jie Wang wrote:
> urb_irq_callback() and urb_ctl_callback() resubmit each other's URBs
> regardless of completion status. When the device returns a persistent
> error (-EPROTO), this creates an unthrottled resubmission loop that
> starves the CPU and triggers RCU stalls.
>
> Stop resubmitting on any non-zero URB status, following the standard
> completion pattern used by other USB input drivers.
>
> Reported-by: syzbot+039eab266c6321a174bd@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=039eab266c6321a174bd
> Signed-off-by: Jie Wang <jie.wang@intel.com>
It would be good to have a helper like
bool usb_is_permanent_error(struct urb *urb, struct device *dev);
instead of having this "switch" in all the drivers. It also unclear
whether we should not attempt to re-submit the URB on errors other than
ECONNRESET, ENOENT, or ESHUTDOWN.
> ---
> drivers/input/misc/yealink.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
> index 8786ed8b3565..bbfa1a9c23d1 100644
> --- a/drivers/input/misc/yealink.c
> +++ b/drivers/input/misc/yealink.c
> @@ -414,9 +414,20 @@ static void urb_irq_callback(struct urb *urb)
> struct yealink_dev *yld = urb->context;
> int ret, status = urb->status;
>
> - if (status)
> + switch (status) {
> + case 0:
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + dev_dbg(&yld->intf->dev, "%s - urb shutting down with status %d\n",
> + __func__, status);
> + return;
> + default:
> dev_err(&yld->intf->dev, "%s - urb status %d\n",
> __func__, status);
> + return;
> + }
>
> switch (yld->irq_data->cmd) {
> case CMD_KEYPRESS:
> @@ -452,9 +463,20 @@ static void urb_ctl_callback(struct urb *urb)
> struct yealink_dev *yld = urb->context;
> int ret = 0, status = urb->status;
>
> - if (status)
> + switch (status) {
> + case 0:
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + dev_dbg(&yld->intf->dev, "%s - urb shutting down with status %d\n",
> + __func__, status);
> + return;
> + default:
> dev_err(&yld->intf->dev, "%s - urb status %d\n",
> __func__, status);
> + return;
> + }
>
> switch (yld->ctl_data->cmd) {
> case CMD_KEYPRESS:
> --
> 2.34.1
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC] Adding device-initiated haptic feedback knobs for pressurepads
From: Rong Zhang @ 2026-06-16 19:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Peter Hutterer, linux-input,
LKML
In-Reply-To: <ajGbFNj73yxaEj0y@google.com>
Hi Dmitry,
On Tue, 2026-06-16 at 11:56 -0700, Dmitry Torokhov wrote:
> Hi Rong,
>
> On Tue, Jun 16, 2026 at 11:34:45PM +0800, Rong Zhang wrote:
> > Hi all,
> >
> > A pressurepad is a MT touchpad that simulates haptic feedback. The
> > haptic feedback may be either device-initiated or host-initiated. While
> > drivers/hid/hid-haptic.c [1] provides comprehensive support for host-
> > initiated ones, device-initiated ones are currently not configurable at
> > all.
> >
> > According to Microsoft's Input Device Haptics Implementation Guide [2],
> > pressurepads with device-initiated haptic feedback can support
> > SET_FEATURE reports to allow users to customize the intensity of the
> > haptic feedback (usage page 0x0e Haptics, usage 0x23 Intensity) and/or
> > the force required to trigger a button press (usage page 0x0d
> > Digitizers, usage 0xb0 Button Press Threshold). Each knob should occupy
> > a dedicated report ID.
> >
> > The first knob maps to "ClickForceSensitivity" in Windows registry and
> > "Touchpad feedback" => "Intensity" in Windows Settings [3]. The second
> > knob maps to "ClickForceSensitivity" in Windows registry.
> >
> > The pressurepad on my laptop supports the first knob:
> >
> > # 0x05, 0x0e, // Usage Page (Haptic) 595
> > # 0x09, 0x01, // Usage (Simple Haptic Controller) 597
> > # 0xa1, 0x02, // Collection (Logical) 599
> > # 0x09, 0x23, // Usage (Intensity) 601
> > # 0x85, 0x09, // Report ID (9) 603
> > # 0x15, 0x00, // Logical Minimum (0) 605
> > # 0x25, 0x64, // Logical Maximum (100) 607
> > # 0x75, 0x08, // Report Size (8) 609
> > # 0x95, 0x01, // Report Count (1) 611
> > # 0xb1, 0x02, // Feature (Data,Var,Abs) 613
> > # 0xc0, // End Collection 615
> >
> > I hardly use Windows but the last time I booted it I did see "Touchpad
> > feedback" => "Intensity" in Windows Settings.
> >
> > On Linux, I can tune the knob by setting the corresponding feature
> > report via HIDRAW. The pressurepad remembers the knob value until it
> > loses power. However, getting the feature report returns garbage data
> > (probably from the last input report in the buffer), which makes some
> > sense as the implementation guide only requires SET_FEATURE support.
> >
> > I'd like to add device-initiated haptic feedback configurations for
> > Linux. For now, I only focus on the first knob, i.e., Haptics Intensity,
> > since it's supported on my device. If I somehow get a device with the
> > second knob I may work on it too.
>
> The question is why would we want to support device-initiated feedback
> instead of enhancing userspace to fully control it. For the record on
> ChromeOS we tried implementing support for device-initiated feedback but
> it made the kernel code very cumbersome and left a lot of gaps/rough
> edges when combining device- and host-initiated haptic effects.
Sorry, I didn't explain it clearly enough.
Most Windows laptops shipping with a pressurepad don't support host-
initiated feedback at all. That's also the case of my device.
>
> I'd prefer it all being driven from userspace.
... so The only force feedback stuff we can control on these
pressurepads are the said one or two knobs, really :-(
Hopefully one day we will live in a host-initiated haptic world...
Thanks,
Rong
>
> Thanks.
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Rob Herring @ 2026-06-16 18:57 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2LiMHnaTK6QnsLxJDtw0fZ_N9LELw0iCorOZwHuWXus0g@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:32 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
> >
> > Nothing is using this so it is a dead file that doesn't get tested.
>
> Hi, it's not referenced as the dtsi inclusion was removed in the
> original patch from 2019 for an easier merging of support for mt8516
> pumpkin boards [1][2].
> If you prefer in the next revision I can add another patch to readd it
> to the existing pumpkin board.
That or move this patch to the series for the board(s). If the board
is already upstream, then add the include in *this* patch.
Rob
^ permalink raw reply
* Re: [RFC] Adding device-initiated haptic feedback knobs for pressurepads
From: Dmitry Torokhov @ 2026-06-16 18:56 UTC (permalink / raw)
To: Rong Zhang
Cc: Jiri Kosina, Benjamin Tissoires, Peter Hutterer, linux-input,
LKML
In-Reply-To: <bbee6e61a243a0ae4db6ea155909607326a80dac.camel@rong.moe>
Hi Rong,
On Tue, Jun 16, 2026 at 11:34:45PM +0800, Rong Zhang wrote:
> Hi all,
>
> A pressurepad is a MT touchpad that simulates haptic feedback. The
> haptic feedback may be either device-initiated or host-initiated. While
> drivers/hid/hid-haptic.c [1] provides comprehensive support for host-
> initiated ones, device-initiated ones are currently not configurable at
> all.
>
> According to Microsoft's Input Device Haptics Implementation Guide [2],
> pressurepads with device-initiated haptic feedback can support
> SET_FEATURE reports to allow users to customize the intensity of the
> haptic feedback (usage page 0x0e Haptics, usage 0x23 Intensity) and/or
> the force required to trigger a button press (usage page 0x0d
> Digitizers, usage 0xb0 Button Press Threshold). Each knob should occupy
> a dedicated report ID.
>
> The first knob maps to "ClickForceSensitivity" in Windows registry and
> "Touchpad feedback" => "Intensity" in Windows Settings [3]. The second
> knob maps to "ClickForceSensitivity" in Windows registry.
>
> The pressurepad on my laptop supports the first knob:
>
> # 0x05, 0x0e, // Usage Page (Haptic) 595
> # 0x09, 0x01, // Usage (Simple Haptic Controller) 597
> # 0xa1, 0x02, // Collection (Logical) 599
> # 0x09, 0x23, // Usage (Intensity) 601
> # 0x85, 0x09, // Report ID (9) 603
> # 0x15, 0x00, // Logical Minimum (0) 605
> # 0x25, 0x64, // Logical Maximum (100) 607
> # 0x75, 0x08, // Report Size (8) 609
> # 0x95, 0x01, // Report Count (1) 611
> # 0xb1, 0x02, // Feature (Data,Var,Abs) 613
> # 0xc0, // End Collection 615
>
> I hardly use Windows but the last time I booted it I did see "Touchpad
> feedback" => "Intensity" in Windows Settings.
>
> On Linux, I can tune the knob by setting the corresponding feature
> report via HIDRAW. The pressurepad remembers the knob value until it
> loses power. However, getting the feature report returns garbage data
> (probably from the last input report in the buffer), which makes some
> sense as the implementation guide only requires SET_FEATURE support.
>
> I'd like to add device-initiated haptic feedback configurations for
> Linux. For now, I only focus on the first knob, i.e., Haptics Intensity,
> since it's supported on my device. If I somehow get a device with the
> second knob I may work on it too.
The question is why would we want to support device-initiated feedback
instead of enhancing userspace to fully control it. For the record on
ChromeOS we tried implementing support for device-initiated feedback but
it made the kernel code very cumbersome and left a lot of gaps/rough
edges when combining device- and host-initiated haptic effects.
I'd prefer it all being driven from userspace.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)
From: Dmitry Torokhov @ 2026-06-16 18:49 UTC (permalink / raw)
To: Raphaël Larocque; +Cc: linux-input, linux-kernel
In-Reply-To: <20260616171137.19069-1-rlarocque@disroot.org>
Hi Raphaël,
On Tue, Jun 16, 2026 at 01:11:36PM -0400, Raphaël Larocque wrote:
> The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a
> Synaptics touchpad whose SMBus companion is not ready at boot and
> takes roughly 200 seconds to appear. During this window the touchpad
> and TrackPoint are completely unresponsive on approximately 50% of
> boots, making the machine unusable until the companion finally
> registers.
>
> The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the
> kernel attempts to use SMBus/RMI4 mode by default. When the companion
> is not ready, psmouse_smbus_init() leaves breadcrumbs and returns
> -EAGAIN, the PS/2 fallback path is taken, but the device does not
> function properly until the companion appears and RMI4 takes over.
>
> Disable SMBus InterTouch for board id 2722 so the touchpad and
> TrackPoint work immediately via PS/2 from boot. Users can still force
> SMBus with psmouse.synaptics_intertouch=1 if needed.
Is this board ID unique to T440p? Or it may be used in other devices as
well?
I also wonder, if you try loading psmouse later in the initialization
cycle, after SMBus has been loaded, if that would help it detect the
touchpad quicker? Is there anything interested in DTS regarding device
interconnect/hierarchy that we might be missing?
>
> Tested-by: Raphaël Larocque <rlarocque@disroot.org>
> Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
> ---
> drivers/input/mouse/synaptics.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index c70502e24031..8f38bc498798 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1837,6 +1837,14 @@ static int synaptics_setup_intertouch(struct psmouse *psmouse,
>
> return -ENXIO;
> }
> +
> + /* Disable intertouch on known-broken board revisions */
> + if (info->board_id == 2722) {
> + psmouse_info(psmouse,
> + "Disabling intertouch for board id %d\n",
> + info->board_id);
> + return -ENXIO;
> + }
> }
>
> psmouse_info(psmouse, "Trying to set up SMBus access\n");
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: xpad - replace symbolic permissions with octal
From: Jack Lee @ 2026-06-16 18:44 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Jack Lee
Symbolic permissions S_IRUGO and S_IWUSR are not preferred. Replace
with octal permissions 0444 and 0644 as recommended by checkpatch.
Signed-off-by: Jack Lee <skunkolee@gmail.com>
---
drivers/input/joystick/xpad.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index feb8f368f834..f6e02016a0c0 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -74,19 +74,19 @@
#define FLAG_DELAY_INIT BIT(0)
static bool dpad_to_buttons;
-module_param(dpad_to_buttons, bool, S_IRUGO);
+module_param(dpad_to_buttons, bool, 0444);
MODULE_PARM_DESC(dpad_to_buttons, "Map D-PAD to buttons rather than axes for unknown pads");
static bool triggers_to_buttons;
-module_param(triggers_to_buttons, bool, S_IRUGO);
+module_param(triggers_to_buttons, bool, 0444);
MODULE_PARM_DESC(triggers_to_buttons, "Map triggers to buttons rather than axes for unknown pads");
static bool sticks_to_null;
-module_param(sticks_to_null, bool, S_IRUGO);
+module_param(sticks_to_null, bool, 0444);
MODULE_PARM_DESC(sticks_to_null, "Do not map sticks at all for unknown pads");
static bool auto_poweroff = true;
-module_param(auto_poweroff, bool, S_IWUSR | S_IRUGO);
+module_param(auto_poweroff, bool, 0644);
MODULE_PARM_DESC(auto_poweroff, "Power off wireless controllers on suspend");
static const struct xpad_device {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] HID: wacom: handle kmemdup failure in Bluetooth IRQ path
From: Jason Gerecke @ 2026-06-16 18:27 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <20260606040344.4-1-ruoyuw560@gmail.com>
On Fri, Jun 5, 2026 at 9:04 PM Ruoyu Wang <ruoyuw560@gmail.com> wrote:
>
> wacom_intuos_bt_irq() duplicates the input report with kmemdup() and then
> uses data[0] to dispatch the report type. If the allocation fails, the
> switch statement dereferences a NULL pointer.
>
> Handle allocation failure by dropping the report. This keeps the
> interrupt path from dereferencing a NULL buffer while preserving the
> existing return convention for ignored or malformed reports.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/hid/wacom_wac.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625d..c42af15e7dba0 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1206,6 +1206,9 @@ static int wacom_intuos_bt_irq(struct wacom_wac *wacom, size_t len)
> int i = 1;
> unsigned power_raw, battery_capacity, bat_charging, ps_connected;
>
> + if (!data)
> + return 0;
> +
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Though, I think we should also (or instead?) entertain a change that
does away with the kmemdup entirely... Replacing this kmemdup and the
memcpy in wacom_intuos_bt_process_data with some simple pointer
manipulation should have the same effect with less work.
Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
> switch (data[0]) {
> case 0x04:
> if (len < 32) {
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] HID: bpf: Fix hid_bpf_get_data() range check
From: bot+bpf-ci @ 2026-06-16 17:18 UTC (permalink / raw)
To: chenyy23, jikos, bentiss, bpf, linux-input
Cc: chenyy23, shuah, ast, daniel, andrii, martin.lau, eddyz87, memxor,
song, yonghong.song, jolsa, linux-kselftest, linux-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <783681f27625a11ed58f00221be046643232a2fc.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]
> commit 7c433bf4ab2de03b77e22dbd3984e39a386997a2
> Author: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
> Date: Tue Jun 16 16:35:06 2026 +0000
>
> HID: bpf: Fix hid_bpf_get_data() range check
>
> hid_bpf_get_data() returns a pointer into the HID-BPF context data when
> the caller-provided offset and size fit inside ctx->allocated_size.
>
> The current check adds rdwr_buf_size and offset before comparing the
> result against ctx->allocated_size. Since both values are unsigned, a
> very large size can wrap the sum below ctx->allocated_size and make the
> helper return a pointer even though the requested range is not contained
> in the backing buffer.
>
> Use a non-wrapping range check instead: reject offsets beyond the
> allocation, then compare the requested size with the remaining bytes
> after the offset.
>
> Fixes: 4171954f56fb ("HID: bpf/dispatch: regroup kfuncs definitions")
> Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
The Fixes tag points to commit 4171954f56fb, but that commit only moved
hid_bpf_get_data() without changing its logic. Its commit message states
"No code change, just move down the hid_bpf_get_data() kfunc definition".
The vulnerable addition pattern 'rdwr_buf_size + offset > ctx->allocated_size'
was actually introduced in commit 658ee5a64fcf ("HID: bpf: allocate data
memory for device_event BPF programs"), which changed the field from ctx->size
to ctx->allocated_size while keeping the same overflow-prone check.
Should the Fixes tag reference the commit that introduced the buggy code:
Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index d0130658091b..09b45c40d84f 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
>
> ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
>
> - if (rdwr_buf_size + offset > ctx->allocated_size)
> + if (offset > ctx->allocated_size ||
> + rdwr_buf_size > ctx->allocated_size - offset)
> return NULL;
>
> return ctx_kern->data + offset;
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27633665618
^ permalink raw reply
* [PATCH] Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)
From: Raphaël Larocque @ 2026-06-16 17:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Raphaël Larocque
The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a
Synaptics touchpad whose SMBus companion is not ready at boot and
takes roughly 200 seconds to appear. During this window the touchpad
and TrackPoint are completely unresponsive on approximately 50% of
boots, making the machine unusable until the companion finally
registers.
The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the
kernel attempts to use SMBus/RMI4 mode by default. When the companion
is not ready, psmouse_smbus_init() leaves breadcrumbs and returns
-EAGAIN, the PS/2 fallback path is taken, but the device does not
function properly until the companion appears and RMI4 takes over.
Disable SMBus InterTouch for board id 2722 so the touchpad and
TrackPoint work immediately via PS/2 from boot. Users can still force
SMBus with psmouse.synaptics_intertouch=1 if needed.
Tested-by: Raphaël Larocque <rlarocque@disroot.org>
Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
---
drivers/input/mouse/synaptics.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c70502e24031..8f38bc498798 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1837,6 +1837,14 @@ static int synaptics_setup_intertouch(struct psmouse *psmouse,
return -ENXIO;
}
+
+ /* Disable intertouch on known-broken board revisions */
+ if (info->board_id == 2722) {
+ psmouse_info(psmouse,
+ "Disabling intertouch for board id %d\n",
+ info->board_id);
+ return -ENXIO;
+ }
}
psmouse_info(psmouse, "Trying to set up SMBus access\n");
--
2.53.0
^ permalink raw reply related
* [PATCH bpf-next 2/2] selftests/hid: Cover hid_bpf_get_data() size overflow
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <cover.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
Add a HID-BPF regression check for hid_bpf_get_data() requests whose
size would overflow when added to the offset.
The new rdesc fixup callback asks for offset 2 and size ~0ULL, then
records whether the helper returns NULL. A vulnerable kernel returns a
non-NULL pointer because the runtime check wraps the addition. A fixed
kernel rejects the request. The test only checks the helper result and
does not dereference the returned pointer.
Also add KHDR_INCLUDES to the HID selftest build so hid_bpf.c sees the
current kernel UAPI HID definitions on systems whose installed headers do
not provide enum hid_report_type.
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 11 +++++++++++
tools/testing/selftests/hid/progs/hid.c | 18 ++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/hid/Makefile b/tools/testing/selftests/hid/Makefile
index 50ec9e0406aba..357c6eb5ff5ee 100644
--- a/tools/testing/selftests/hid/Makefile
+++ b/tools/testing/selftests/hid/Makefile
@@ -24,7 +24,7 @@ CXX ?= $(CROSS_COMPILE)g++
HOSTPKG_CONFIG := pkg-config
-CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT)
+CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT) $(KHDR_INCLUDES)
CFLAGS += -I$(OUTPUT)/tools/include
LDLIBS += -lelf -lz -lrt -lpthread
diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
index 1e979fb3542ba..f0a210900e63d 100644
--- a/tools/testing/selftests/hid/hid_bpf.c
+++ b/tools/testing/selftests/hid/hid_bpf.c
@@ -887,6 +887,17 @@ TEST_F(hid_bpf, test_rdesc_fixup)
ASSERT_EQ(rpt_desc.value[4], 0x42);
}
+TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)
+{
+ const struct test_program progs[] = {
+ { .name = "hid_rdesc_fixup_get_data_overflow" },
+ };
+
+ LOAD_PROGRAMS(progs);
+
+ ASSERT_EQ(self->skel->bss->get_data_overflow_check, 1);
+}
+
static int libbpf_print_fn(enum libbpf_print_level level,
const char *format, va_list args)
{
diff --git a/tools/testing/selftests/hid/progs/hid.c b/tools/testing/selftests/hid/progs/hid.c
index 5ecc845ef7921..c6ae2cd045b0e 100644
--- a/tools/testing/selftests/hid/progs/hid.c
+++ b/tools/testing/selftests/hid/progs/hid.c
@@ -13,6 +13,7 @@ struct attach_prog_args {
__u64 callback_check = 52;
__u64 callback2_check = 52;
+__u64 get_data_overflow_check;
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_first_event, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
@@ -240,6 +241,23 @@ struct hid_bpf_ops rdesc_fixup = {
.hid_rdesc_fixup = (void *)hid_rdesc_fixup,
};
+SEC("?struct_ops.s/hid_rdesc_fixup")
+int BPF_PROG(hid_rdesc_fixup_get_data_overflow, struct hid_bpf_ctx *hid_ctx)
+{
+ __u8 *data;
+
+ data = hid_bpf_get_data(hid_ctx, 2 /* offset */, ~0ULL /* size */);
+ if (!data)
+ get_data_overflow_check = 1;
+
+ return 0;
+}
+
+SEC(".struct_ops.link")
+struct hid_bpf_ops rdesc_fixup_get_data_overflow = {
+ .hid_rdesc_fixup = (void *)hid_rdesc_fixup_get_data_overflow,
+};
+
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_test_insert1, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
{
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next 1/2] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <cover.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
hid_bpf_get_data() returns a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The current check adds rdwr_buf_size and offset before comparing the
result against ctx->allocated_size. Since both values are unsigned, a
very large size can wrap the sum below ctx->allocated_size and make the
helper return a pointer even though the requested range is not contained
in the backing buffer.
Use a non-wrapping range check instead: reject offsets beyond the
allocation, then compare the requested size with the remaining bytes
after the offset.
Fixes: 4171954f56fb ("HID: bpf/dispatch: regroup kfuncs definitions")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index d0130658091b0..09b45c40d84f0 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
- if (rdwr_buf_size + offset > ctx->allocated_size)
+ if (offset > ctx->allocated_size ||
+ rdwr_buf_size > ctx->allocated_size - offset)
return NULL;
return ctx_kern->data + offset;
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next 0/2] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
hid_bpf_get_data() exposes a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The helper currently checks that range with:
rdwr_buf_size + offset > ctx->allocated_size
Since both operands are unsigned, a very large size can wrap the sum and
make an out-of-range request look valid.
Patch 1 changes the helper to reject offset values beyond the allocation
and then compare the requested size against the remaining bytes.
Patch 2 adds a HID-BPF regression check that asks hid_bpf_get_data() for
offset 2 and size ~0ULL from an rdesc_fixup callback and expects NULL.
It also adds KHDR_INCLUDES to the HID selftest build so the userspace
test sees current kernel UAPI HID definitions.
Validation, rebased and tested on bpf-next master e4287bf34f97
("selftests/bpf: Work around llvm stack overflow in crypto progs"):
git diff --check origin/master..HEAD: OK
scripts/checkpatch.pl --strict -g origin/master..HEAD: OK
make O=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616 \
drivers/hid/bpf/hid_bpf_dispatch.o: OK
make -C tools/testing/selftests/hid \
O=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616 \
OUTPUT=/tmp/hid-selftest-026 \
VMLINUX_BTF=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616/vmlinux \
KHDR_INCLUDES=-isystem /root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616/usr/include \
hid_bpf: OK
The sanitized UAPI headers were generated in the build tree with
headers_install. The final install/copy step reported missing rsync in
this environment, but the generated build-tree usr/include was present
and used for the selftest build.
Yiyang Chen (2):
HID: bpf: Fix hid_bpf_get_data() range check
selftests/hid: Cover hid_bpf_get_data() size overflow
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 11 +++++++++++
tools/testing/selftests/hid/progs/hid.c | 18 ++++++++++++++++++
4 files changed, 32 insertions(+), 2 deletions(-)
base-commit: e4287bf34f97a88c7d9322f5bde828724c073a6b
--
2.34.1
^ 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