* [PATCH 08/26] Input: maplemouse - remove redundant drvdata resetting
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
The driver core automatically resets driver data to NULL on probe
failures and device removal, so we can remove it from the driver.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/maplemouse.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index 97d520e7d66d..37f60bbd0ba4 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -109,7 +109,6 @@ static int probe_maple_mouse(struct device *dev)
fail_register:
input_free_device(input_dev);
- maple_set_drvdata(mdev, NULL);
fail_nomem:
kfree(mse);
fail:
@@ -122,7 +121,6 @@ static int remove_maple_mouse(struct device *dev)
struct dc_mouse *mse = maple_get_drvdata(mdev);
input_unregister_device(mse->dev);
- maple_set_drvdata(mdev, NULL);
kfree(mse);
return 0;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 09/26] Input: maple_keyb - remove redundant drvdata resetting
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
The driver core automatically resets driver data to NULL on probe
failures and device removal, so we can remove it from the driver.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index a245774acc55..0c92138bcc77 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -212,7 +212,6 @@ static int probe_maple_kbd(struct device *dev)
return error;
fail_register:
- maple_set_drvdata(mdev, NULL);
input_free_device(idev);
fail_idev_alloc:
kfree(kbd);
@@ -230,7 +229,6 @@ static int remove_maple_kbd(struct device *dev)
input_unregister_device(kbd->dev);
kfree(kbd);
- maple_set_drvdata(mdev, NULL);
return 0;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 07/26] Input: maple_keyb - implement open and close methods
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
Instead of polling the keyboard constantly from probe, implement open
and close methods for the input device to only start polling when the
device is actually opened by userspace, and stop polling when it is
closed.
This matches the behavior of maplemouse and maplecontrol drivers.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index 623d7951405b..a245774acc55 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -140,6 +140,24 @@ static void dc_kbd_callback(struct mapleq *mq)
}
}
+static int dc_kbd_open(struct input_dev *dev)
+{
+ struct maple_device *mdev = input_get_drvdata(dev);
+
+ /* Maple polling is locked to VBLANK - which may be just 50/s */
+ maple_getcond_callback(mdev, dc_kbd_callback, HZ / 50,
+ MAPLE_FUNC_KEYBOARD);
+
+ return 0;
+}
+
+static void dc_kbd_close(struct input_dev *dev)
+{
+ struct maple_device *mdev = input_get_drvdata(dev);
+
+ maple_getcond_callback(mdev, NULL, 0, MAPLE_FUNC_KEYBOARD);
+}
+
static int probe_maple_kbd(struct device *dev)
{
struct maple_device *mdev;
@@ -167,6 +185,7 @@ static int probe_maple_kbd(struct device *dev)
memcpy(kbd->keycode, dc_kbd_keycode, sizeof(kbd->keycode));
maple_set_drvdata(mdev, kbd);
+ input_set_drvdata(idev, mdev);
idev->name = mdev->product_name;
idev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP);
@@ -175,6 +194,8 @@ static int probe_maple_kbd(struct device *dev)
idev->keycodemax = ARRAY_SIZE(kbd->keycode);
idev->id.bustype = BUS_HOST;
idev->dev.parent = &mdev->dev;
+ idev->open = dc_kbd_open;
+ idev->close = dc_kbd_close;
for (i = 0; i < NR_SCANCODES; i++)
__set_bit(dc_kbd_keycode[i], idev->keybit);
@@ -186,10 +207,6 @@ static int probe_maple_kbd(struct device *dev)
if (error)
goto fail_register;
- /* Maple polling is locked to VBLANK - which may be just 50/s */
- maple_getcond_callback(mdev, dc_kbd_callback, HZ/50,
- MAPLE_FUNC_KEYBOARD);
-
mdev->driver = mdrv;
return error;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 06/26] Input: maplecontrol - simplify maple_device retrieval in open/close
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
Instead of passing the dc_pad structure via platform_data to the
input device to retrieve the maple_device in open/close, store the
maple_device pointer in the input device's private data (drvdata)
and use input_get_drvdata() to retrieve it.
This allows us to remove the platform_data assignment in probe.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index c66b2614e298..9d623c9e8f22 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -62,19 +62,19 @@ static void dc_pad_callback(struct mapleq *mq)
static int dc_pad_open(struct input_dev *dev)
{
- struct dc_pad *pad = dev_get_platdata(&dev->dev);
+ struct maple_device *mdev = input_get_drvdata(dev);
- maple_getcond_callback(pad->mdev, dc_pad_callback, HZ/20,
- MAPLE_FUNC_CONTROLLER);
+ maple_getcond_callback(mdev, dc_pad_callback, HZ / 20,
+ MAPLE_FUNC_CONTROLLER);
return 0;
}
static void dc_pad_close(struct input_dev *dev)
{
- struct dc_pad *pad = dev_get_platdata(&dev->dev);
+ struct maple_device *mdev = input_get_drvdata(dev);
- maple_getcond_callback(pad->mdev, NULL, 0, MAPLE_FUNC_CONTROLLER);
+ maple_getcond_callback(mdev, NULL, 0, MAPLE_FUNC_CONTROLLER);
}
/* allow the controller to be used */
@@ -112,6 +112,7 @@ static int probe_maple_controller(struct device *dev)
pad->mdev = mdev;
maple_set_drvdata(mdev, pad);
+ input_set_drvdata(idev, mdev);
idev->open = dc_pad_open;
idev->close = dc_pad_close;
@@ -130,7 +131,6 @@ static int probe_maple_controller(struct device *dev)
if (idev->keybit[BIT_WORD(BTN_JOYSTICK)])
idev->evbit[0] |= BIT_MASK(EV_KEY);
- idev->dev.platform_data = pad;
idev->dev.parent = &mdev->dev;
idev->name = mdev->product_name;
idev->id.bustype = BUS_HOST;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 04/26] Input: maplemouse - stop polling and clear callback on close
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
In dc_mouse_close(), pass NULL instead of dc_mouse_callback to
maple_getcond_callback() to both stop polling and clear the callback
pointer when the input device is closed.
This makes the manual clearing of mdev->callback in
remove_maple_mouse() redundant, as input_unregister_device()
automatically closes the device if it was open. Remove the redundant
assignment.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/maplemouse.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index 0c8f7d1b02aa..97d520e7d66d 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -60,8 +60,7 @@ static void dc_mouse_close(struct input_dev *dev)
{
struct dc_mouse *mse = input_get_drvdata(dev);
- maple_getcond_callback(mse->mdev, dc_mouse_callback, 0,
- MAPLE_FUNC_MOUSE);
+ maple_getcond_callback(mse->mdev, NULL, 0, MAPLE_FUNC_MOUSE);
}
/* allow the mouse to be used */
@@ -122,7 +121,6 @@ static int remove_maple_mouse(struct device *dev)
struct maple_device *mdev = to_maple_dev(dev);
struct dc_mouse *mse = maple_get_drvdata(mdev);
- mdev->callback = NULL;
input_unregister_device(mse->dev);
maple_set_drvdata(mdev, NULL);
kfree(mse);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 05/26] Input: maplecontrol - stop polling and clear callback on close
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
In dc_pad_close(), pass NULL instead of dc_pad_callback to
maple_getcond_callback() to both stop polling and clear the callback
pointer when the input device is closed.
This makes the manual clearing of mdev->callback in
remove_maple_controller() redundant, as input_unregister_device()
automatically closes the device if it was open. Remove the redundant
assignment.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index a498fc322c4d..c66b2614e298 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -74,8 +74,7 @@ static void dc_pad_close(struct input_dev *dev)
{
struct dc_pad *pad = dev_get_platdata(&dev->dev);
- maple_getcond_callback(pad->mdev, dc_pad_callback, 0,
- MAPLE_FUNC_CONTROLLER);
+ maple_getcond_callback(pad->mdev, NULL, 0, MAPLE_FUNC_CONTROLLER);
}
/* allow the controller to be used */
@@ -156,7 +155,6 @@ static int remove_maple_controller(struct device *dev)
struct maple_device *mdev = to_maple_dev(dev);
struct dc_pad *pad = maple_get_drvdata(mdev);
- mdev->callback = NULL;
input_unregister_device(pad->dev);
maple_set_drvdata(mdev, NULL);
kfree(pad);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 03/26] Input: maplecontrol - only enable present axes
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
The driver was unconditionally enabling all possible analog axes and
hats on the input device, even if the controller reported it did not
have them in its function data.
Move the input_set_abs_params() calls inside the capability check loop
so that only actually present axes are enabled on the input device.
Also, correct the D-pad (hat) axis limits. They were initialized with
inverted limits (min=1, max=-1). Correct them to min=-1, max=1, which
matches the values (-1, 0, 1) reported by the driver.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 6293b6e8148b..a498fc322c4d 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -118,26 +118,19 @@ static int probe_maple_controller(struct device *dev)
idev->close = dc_pad_close;
for (i = 0; i < 32; i++) {
- if (data & (1 << i)) {
+ if (data & BIT(i)) {
if (btn_bit[i] >= 0)
__set_bit(btn_bit[i], idev->keybit);
- else if (abs_bit[i] >= 0)
- __set_bit(abs_bit[i], idev->absbit);
+ else if (abs_bit[i] >= ABS_X && abs_bit[i] <= ABS_BRAKE)
+ input_set_abs_params(idev, abs_bit[i], 0, 255, 0, 0);
+ else if (abs_bit[i] >= ABS_HAT0X && abs_bit[i] <= ABS_HAT3Y)
+ input_set_abs_params(idev, abs_bit[i], -1, 1, 0, 0);
}
}
if (idev->keybit[BIT_WORD(BTN_JOYSTICK)])
idev->evbit[0] |= BIT_MASK(EV_KEY);
- if (idev->absbit[0])
- idev->evbit[0] |= BIT_MASK(EV_ABS);
-
- for (i = ABS_X; i <= ABS_BRAKE; i++)
- input_set_abs_params(idev, i, 0, 255, 0, 0);
-
- for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++)
- input_set_abs_params(idev, i, 1, -1, 0, 0);
-
idev->dev.platform_data = pad;
idev->dev.parent = &mdev->dev;
idev->name = mdev->product_name;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 02/26] Input: maple_keyb - fix key press detection
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
The key press detection logic was using ptr instead of !ptr (where ptr is
the result of memchr searching for the new key in the old keys).
If ptr is not NULL, it means the key was already pressed in the previous
report, so it is not a new press. If ptr is NULL, it means the key was
not pressed before, so it is a new press.
Using ptr instead of !ptr caused new presses to be ignored in the first
poll cycle (only reported in the second cycle if still held, because
then it was in 'old'), and caused redundant press events to be sent
on every subsequent poll while the key was held.
Fix this by using !ptr for press detection, matching the release
detection logic.
Fixes: b11d2127c489 ("Input: add support for SEGA Dreamcast keyboard")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index 3d5538dd4f23..623d7951405b 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -107,7 +107,7 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
}
ptr = memchr(kbd->old + 2, kbd->new[i], 6);
code = kbd->new[i];
- if (code > 3 && ptr) {
+ if (code > 3 && !ptr) {
keycode = kbd->keycode[code];
if (keycode) {
input_event(dev, EV_MSC, MSC_SCAN, code);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 01/26] sh: maple: include linux/device.h in linux/maple.h
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
In-Reply-To: <20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com>
struct maple_device embeds struct device and struct maple_driver
embeds struct device_driver. Therefore, linux/maple.h must include
linux/device.h to have their full definitions, rather than just
forward declaring struct device.
This fixes compilation of vmu-flash.c which includes linux/maple.h
without previously including linux/device.h (or headers that include
it).
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
include/linux/maple.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/maple.h b/include/linux/maple.h
index 3be4e567473c..22f2930251ed 100644
--- a/include/linux/maple.h
+++ b/include/linux/maple.h
@@ -2,10 +2,9 @@
#ifndef __LINUX_MAPLE_H
#define __LINUX_MAPLE_H
+#include <linux/device.h>
#include <mach/maple.h>
-struct device;
-
/* Maple Bus command and response codes */
enum maple_code {
MAPLE_RESPONSE_FILEERR = -5,
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 00/26] sh: maple: cleanup and modernize input drivers
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
This series aims to modernize the Maple bus core and its input drivers
(keyboard, mouse, joystick/controller), addressing build failures, race
conditions, and coding style issues:
- fixes a build failure in vmu-flash.c due to missing include
- fixes keyboard press detection logic (eliminating a 1-poll delay and
redundant press events)
- corrects D-pad axis limits and optimizes event reporting using
branchless calculations
- implements open() and close() in maple_keyb so all Maple input drivers
only poll when actively open
- introduces callback_mutex in the Maple bus core to avoid potential UAF
when stopping/unbinding the drivers
- removes the unused driver field from struct maple_device (write-only
since 2008) and eliminates the redundant maple_unsupported_device dummy
driver
- implements standard bus-level probe() and remove() methods for the
Maple bus
- converts all three Maple input drivers to use managed resources, and
fixes style issues reported by checkpatch.
This compiles but has not been tested on real hardware.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Dmitry Torokhov (26):
sh: maple: include linux/device.h in linux/maple.h
Input: maple_keyb - fix key press detection
Input: maplecontrol - only enable present axes
Input: maplemouse - stop polling and clear callback on close
Input: maplecontrol - stop polling and clear callback on close
Input: maplecontrol - simplify maple_device retrieval in open/close
Input: maple_keyb - implement open and close methods
Input: maplemouse - remove redundant drvdata resetting
Input: maple_keyb - remove redundant drvdata resetting
Input: maplecontrol - remove redundant drvdata resetting
Input: maplemouse - remove unused mdev->driver assignment
Input: maplecontrol - remove unused mdev->driver assignment
Input: maple_keyb - remove unused mdev->driver assignment
mtd: maps: vmu-flash: remove unused mdev->driver assignment
sh: maple: remove not needed maple_unsupported_device driver
sh: maple: remove unused driver field from struct maple_device
sh: maple: implement bus-level probe/remove
sh: maple: introduce callback_mutex in maple_device
Input: maple_keyb - remove redundant mutex and remove method
Input: maple_keyb - convert to devm
Input: maplemouse - convert to devm
Input: maplecontrol - convert to devm
Input: maple_keyb - fix style issues
Input: maplemouse - fix style issues
Input: maplecontrol - fix style issues
Input: maple_keyb - remove redundant 'new' buffer from struct dc_kbd
drivers/input/joystick/maplecontrol.c | 98 +++++++++------------------
drivers/input/keyboard/maple_keyb.c | 124 +++++++++++++---------------------
drivers/input/mouse/maplemouse.c | 55 ++++-----------
drivers/mtd/maps/vmu-flash.c | 15 ++--
drivers/sh/maple/maple.c | 61 ++++++++++-------
include/linux/maple.h | 8 ++-
6 files changed, 140 insertions(+), 221 deletions(-)
---
base-commit: 2b763db0c2763d6bf73d7d3e69665222d1f377cf
change-id: 20260628-b4-maple-cleanup-884682ae108b
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/6] iio: hid-sensors: align function parenthesis for readability
From: srinivas pandruvada @ 2026-07-04 1:09 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Sanjay Chitroda via B4 Relay, sanjayembeddedse, David Lechner,
Nuno Sá, Andy Shevchenko, Jiri Kosina, linux-iio,
linux-kernel, linux-input
In-Reply-To: <akewhE9wEpU6UW0u@ashevche-desk.local>
On Fri, 2026-07-03 at 15:52 +0300, Andy Shevchenko wrote:
> On Thu, Jul 02, 2026 at 06:20:15PM +0100, Jonathan Cameron wrote:
> > On Thu, 02 Jul 2026 21:47:59 +0530
> > Sanjay Chitroda via B4 Relay
> > <devnull+sanjayembeddedse.gmail.com@kernel.org> wrote:
> >
> > > Adjust alignment of parentheses across HID sensor IIO drivers to
> > > improve readability and maintain consistency with kernel coding
> > > style.
> > >
> > > While updating the formatting, group related arguments
> > > consistently in
> > > multi-line function signatures where appropriate.
> > >
> > > No functional change intended.
> >
> > Whilst I appreciate this code isn't quite in line with standards
> > and usually like that stuff to be fixed up, in this particular case
> > this is a massive amount of churn. That churn will make
> > backporting
> > fixes etc messier, so I'd like input on whether others consider
> > this
> > one worthwhile. Jiri, Srinivas, Andy etc. What do you think?
>
> I am fine as long as Srinivas is. I understand pros and cons of this,
> but from
> time to time we have patches à la this one that messes up with
> backporting but
> were accepted as a good part of some bigger series.
I am fine. I guess we will deal with backporting issues as they appear.
Thanks,
Srinivas
^ permalink raw reply
* [PATCH] HID: logitech-dj: Add support for G915 TKL receiver 0xc545
From: Colin Blower @ 2026-07-04 0:28 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Filipe Laíns, linux-input, linux-kernel
The Logitech G915 TKL has a lightspeed receiver with a product id of
0xc545. This receiver seems to behave like 0xc547 receiver.
Add a definition for this new receiver id and a mapping for the
recvr_type_gaming_hidpp_ls_1_3 type, the receiver now reports battery
status of the connected keyboard.
Signed-off-by: Colin Blower <colin@1101b.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1059922baaac..0089a5e88ec9 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -967,6 +967,7 @@
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_2 0xc543
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_3 0xc547
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_4 0xc54d
+#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_5 0xc545
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548
#define USB_DEVICE_ID_SPACETRAVELLER 0xc623
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 381e4dc5aba7..49b96ff2bc36 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -2102,6 +2102,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_4),
.driver_data = recvr_type_gaming_hidpp_ls_1_3},
+ { /* Logitech lightspeed receiver (0xc545) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_5),
+ .driver_data = recvr_type_gaming_hidpp_ls_1_3},
{ /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER),
--
2.55.0
^ permalink raw reply related
* [dtor-input:for-linus] BUILD SUCCESS 536394ec81419b67d9f4f0028812c4372397be1b
From: kernel test robot @ 2026-07-03 18:56 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 536394ec81419b67d9f4f0028812c4372397be1b Input: maple_keyb - set driver data before registering input device
elapsed time: 760m
configs tested: 324
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc axs103_defconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-16.1.0
arc randconfig-001-20260703 gcc-16.1.0
arc randconfig-001-20260703 gcc-8.5.0
arc randconfig-001-20260704 gcc-8.5.0
arc randconfig-002 gcc-16.1.0
arc randconfig-002-20260703 gcc-16.1.0
arc randconfig-002-20260703 gcc-8.5.0
arc randconfig-002-20260704 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm keystone_defconfig gcc-16.1.0
arm mvebu_v7_defconfig clang-23
arm randconfig-001 gcc-16.1.0
arm randconfig-001-20260703 gcc-16.1.0
arm randconfig-001-20260703 gcc-8.5.0
arm randconfig-001-20260704 gcc-8.5.0
arm randconfig-002 gcc-16.1.0
arm randconfig-002-20260703 gcc-16.1.0
arm randconfig-002-20260703 gcc-8.5.0
arm randconfig-002-20260704 gcc-8.5.0
arm randconfig-003 gcc-16.1.0
arm randconfig-003-20260703 gcc-16.1.0
arm randconfig-003-20260703 gcc-8.5.0
arm randconfig-003-20260704 gcc-8.5.0
arm randconfig-004 gcc-16.1.0
arm randconfig-004-20260703 gcc-16.1.0
arm randconfig-004-20260703 gcc-8.5.0
arm randconfig-004-20260704 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 gcc-10.5.0
arm64 randconfig-001-20260703 clang-23
arm64 randconfig-001-20260703 gcc-10.5.0
arm64 randconfig-001-20260704 gcc-16.1.0
arm64 randconfig-002 gcc-10.5.0
arm64 randconfig-002-20260703 gcc-10.5.0
arm64 randconfig-002-20260703 gcc-12.5.0
arm64 randconfig-002-20260704 gcc-16.1.0
arm64 randconfig-003 gcc-10.5.0
arm64 randconfig-003-20260703 gcc-10.5.0
arm64 randconfig-003-20260704 gcc-16.1.0
arm64 randconfig-004 gcc-10.5.0
arm64 randconfig-004-20260703 gcc-10.5.0
arm64 randconfig-004-20260703 gcc-8.5.0
arm64 randconfig-004-20260704 gcc-16.1.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 gcc-10.5.0
csky randconfig-001-20260703 gcc-10.5.0
csky randconfig-001-20260703 gcc-12.5.0
csky randconfig-001-20260704 gcc-16.1.0
csky randconfig-002 gcc-10.5.0
csky randconfig-002-20260703 gcc-10.5.0
csky randconfig-002-20260704 gcc-16.1.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260703 gcc-11.5.0
hexagon randconfig-001-20260703 gcc-16.1.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260703 gcc-11.5.0
hexagon randconfig-002-20260703 gcc-16.1.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260703 clang-22
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260703 clang-22
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260703 clang-22
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260703 clang-22
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260703 clang-22
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260703 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260703 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260703 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260703 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260703 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260703 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260703 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260703 clang-22
i386 randconfig-011 clang-22
i386 randconfig-011-20260703 clang-22
i386 randconfig-012 clang-22
i386 randconfig-012-20260703 clang-22
i386 randconfig-013 clang-22
i386 randconfig-013-20260703 clang-22
i386 randconfig-014 clang-22
i386 randconfig-014-20260703 clang-22
i386 randconfig-015 clang-22
i386 randconfig-015-20260703 clang-22
i386 randconfig-016 clang-22
i386 randconfig-016-20260703 clang-22
i386 randconfig-017 clang-22
i386 randconfig-017-20260703 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260703 gcc-11.5.0
loongarch randconfig-001-20260703 gcc-16.1.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260703 gcc-11.5.0
loongarch randconfig-002-20260703 gcc-16.1.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260703 gcc-11.5.0
nios2 randconfig-001-20260703 gcc-16.1.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260703 gcc-11.5.0
nios2 randconfig-002-20260703 gcc-16.1.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 clang-23
parisc randconfig-001-20260703 clang-23
parisc randconfig-001-20260704 clang-23
parisc randconfig-002 clang-23
parisc randconfig-002-20260703 clang-23
parisc randconfig-002-20260704 clang-23
parisc64 defconfig clang-23
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc chrp32_defconfig clang-23
powerpc ep8248e_defconfig gcc-16.1.0
powerpc randconfig-001 clang-23
powerpc randconfig-001-20260703 clang-23
powerpc randconfig-001-20260704 clang-23
powerpc randconfig-002 clang-23
powerpc randconfig-002-20260703 clang-23
powerpc randconfig-002-20260704 clang-23
powerpc64 randconfig-001 clang-23
powerpc64 randconfig-001-20260703 clang-23
powerpc64 randconfig-001-20260704 clang-23
powerpc64 randconfig-002 clang-23
powerpc64 randconfig-002-20260703 clang-23
powerpc64 randconfig-002-20260704 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260703 gcc-9.5.0
riscv randconfig-001-20260704 gcc-10.5.0
riscv randconfig-002-20260703 gcc-9.5.0
riscv randconfig-002-20260704 gcc-10.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260703 gcc-9.5.0
s390 randconfig-001-20260704 gcc-10.5.0
s390 randconfig-002-20260703 gcc-9.5.0
s390 randconfig-002-20260704 gcc-10.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh hp6xx_defconfig gcc-16.1.0
sh randconfig-001-20260703 gcc-9.5.0
sh randconfig-001-20260704 gcc-10.5.0
sh randconfig-002-20260703 gcc-9.5.0
sh randconfig-002-20260704 gcc-10.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260703 gcc-11.5.0
sparc randconfig-001-20260704 gcc-16.1.0
sparc randconfig-002-20260703 gcc-11.5.0
sparc randconfig-002-20260704 gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260703 gcc-11.5.0
sparc64 randconfig-001-20260704 gcc-16.1.0
sparc64 randconfig-002-20260703 gcc-11.5.0
sparc64 randconfig-002-20260704 gcc-16.1.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260703 gcc-11.5.0
um randconfig-001-20260704 gcc-16.1.0
um randconfig-002-20260703 gcc-11.5.0
um randconfig-002-20260704 gcc-16.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260703 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260703 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260703 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260703 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260703 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260703 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260703 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260703 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260703 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260703 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260703 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260703 clang-22
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260703 gcc-13
x86_64 randconfig-011-20260703 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260703 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260703 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260703 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260703 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260703 clang-22
x86_64 randconfig-016-20260703 gcc-14
x86_64 randconfig-071 clang-22
x86_64 randconfig-071-20260703 clang-22
x86_64 randconfig-072 clang-22
x86_64 randconfig-072-20260703 clang-22
x86_64 randconfig-073 clang-22
x86_64 randconfig-073-20260703 clang-22
x86_64 randconfig-074 clang-22
x86_64 randconfig-074-20260703 clang-22
x86_64 randconfig-075 clang-22
x86_64 randconfig-075-20260703 clang-22
x86_64 randconfig-076 clang-22
x86_64 randconfig-076-20260703 clang-22
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa common_defconfig gcc-16.1.0
xtensa randconfig-001-20260703 gcc-11.5.0
xtensa randconfig-001-20260704 gcc-16.1.0
xtensa randconfig-002-20260703 gcc-11.5.0
xtensa randconfig-002-20260704 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] HID: core: fix number/pointer type confusion on long items
From: Jann Horn @ 2026-07-03 18:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Henrik Rydberg, linux-input, linux-kernel, stable, Jann Horn
When fetch_item() is called by hid_scan_report() on an item with
HID_ITEM_TAG_LONG, it stores a pointer to the item data in
item->data.longdata instead of storing a value directly in
item->data.{u8/u16/u32}.
When item_udata() or item_sdata() encounters such an item, it incorrectly
assumes that the item is in short format, and therefore returns the lower
part of a kernel pointer reinterpreted as a number.
When a HID device is connected whose descriptor contains a
HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this
causes the lower half of a kernel pointer to be printed into dmesg as a
number, like this:
hid (null): invalid report_size 107953555
To fix it, let item_udata() and item_sdata() verify that the item is in
short format.
Note that this bug only affects hid_scan_report(), while the main parsing
pass hid_parse_collections() will always bail out when encountering a long
item.
Sidenote: There are currently no users of data.longdata; maybe we should
just remove any parsing of long-format descriptors as a follow-up.
Fixes: 3dc8fc083dbf ("HID: Use hid_parser for pre-scanning the report descriptors")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..d6676505e122 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -379,6 +379,9 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign
static u32 item_udata(struct hid_item *item)
{
+ if (item->format != HID_ITEM_FORMAT_SHORT)
+ return 0;
+
switch (item->size) {
case 1: return item->data.u8;
case 2: return item->data.u16;
@@ -389,6 +392,9 @@ static u32 item_udata(struct hid_item *item)
static s32 item_sdata(struct hid_item *item)
{
+ if (item->format != HID_ITEM_FORMAT_SHORT)
+ return 0;
+
switch (item->size) {
case 1: return item->data.s8;
case 2: return item->data.s16;
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-core-data-typeconfusion-95c660affffe
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* Re: [PATCH v2 3/3] HID: rapoo: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 16:02 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v2-3-c5ed7bc94772@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing hid_hw_stop() cleanup on error paths in rapoo_probe() causes hardware resource leaks and a Use-After-Free.
--
commit ed7992bab1a88e74142aa29aa65b4061257a86cb
Author: Jann Horn <jannh@google.com>
HID: rapoo: fix missing hid_is_usb() check
This commit adds a hid_is_usb() check before calling to_usb_interface() to
handle uhid devices reporting BUS_USB without an actual USB parent. It also
adds a USB_HID dependency for hid_is_usb().
[ ... ]
> diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
> index 4c81f3086de43..5c9c396fabf77 100644
> --- a/drivers/hid/hid-rapoo.c
> +++ b/drivers/hid/hid-rapoo.c
> @@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> - if (hdev->bus == BUS_USB) {
> + if (hid_is_usb(hdev)) {
> struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>
> if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
[Severity: High]
This is a pre-existing issue, but are we missing hid_hw_stop() calls on the
error paths later in rapoo_probe()?
If devm_input_allocate_device() fails, the code returns -ENOMEM directly:
input = devm_input_allocate_device(&hdev->dev);
if (!input)
return -ENOMEM;
Similarly, if input_register_device() fails, it returns the error:
ret = input_register_device(input);
if (ret)
return ret;
When returning these errors after hid_hw_start() has succeeded, the HID core
probe fails and sets hdev->driver to NULL, but hid_hw_stop() is never called
to stop the hardware and kill active URBs.
When the device is later unplugged, usbhid_disconnect() frees the usbhid
structure, but skips hid_hw_stop() because hdev->driver is NULL.
Because active USB URBs are not killed, when the USB core later flushes the
endpoints and cancels the URBs, the completion handler hid_irq_in() attempts
to clear state bits in the already-freed usbhid structure, like calling
clear_bit(HID_IN_RUNNING, &usbhid->iofl).
This results in a use-after-free write memory corruption. While this requires
local physical access to the USB port and specific conditions like memory
pressure to induce a probe failure, it guarantees memory corruption when
triggered.
Would it be better to add an error label that calls hid_hw_stop() when the
input device allocation or registration fails?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com?part=3
^ permalink raw reply
* Re: [PATCH v2 1/3] HID: asus: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:58 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v2-1-c5ed7bc94772@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Dangling pointer in `drvdata->kbd_backlight` leading to Use-After-Free when WMI listener registration fails.
--
commit 0bcf68d0cd670d6cc4fac38b7be14d0855140731
Author: Jann Horn <jannh@google.com>
HID: asus: fix missing hid_is_usb() check
This commit fixes a kernel splat caused by uhid devices that identify as
being on BUS_USB without actually having a USB parent. It adds a missing
hid_is_usb() check before calling to_usb_interface().
Cc: stable@vger.kernel.org
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..befa990b3210e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential
use-after-free later in this same function.
When asus_hid_register_listener() fails, the code frees the backlight
structure but leaves the pointer dangling:
drivers/hid/hid-asus.c:asus_kbd_register_leds() {
...
ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
}
return ret;
}
Since asus_probe() logs a warning but continues successfully when this
fails, could this cause a use-after-free during device removal or
suspend?
It looks like asus_remove() checks if the pointer is non-null before
dereferencing it:
drivers/hid/hid-asus.c:asus_remove() {
...
if (drvdata->kbd_backlight) {
asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
...
}
Should drvdata->kbd_backlight be set to NULL after being freed to prevent
this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com?part=1
^ permalink raw reply
* [PATCH v2 3/3] HID: rapoo: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
Add a dependency on USB_HID for hid_is_usb(), as other HID drivers do; the
alternative would be to provide a simple stub implementation on !USB_HID
builds.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/Kconfig | 1 +
drivers/hid/hid-rapoo.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f9bcaeb66385..48934c4f3c45 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1048,6 +1048,7 @@ config HID_PXRC
config HID_RAPOO
tristate "Rapoo non-fully HID-compliant devices"
+ depends on USB_HID
help
Support for Rapoo devices that are not fully compliant with the
HID standard.
diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
index 4c81f3086de4..5c9c396fabf7 100644
--- a/drivers/hid/hid-rapoo.c
+++ b/drivers/hid/hid-rapoo.c
@@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
- if (hdev->bus == BUS_USB) {
+ if (hid_is_usb(hdev)) {
struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 2/3] HID: huawei: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: e93faaca84b7 ("HID: huawei: fix CD30 keyboard report descriptor issue")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-huawei.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-huawei.c b/drivers/hid/hid-huawei.c
index 6a616bf21b38..ee3fc6f68475 100644
--- a/drivers/hid/hid-huawei.c
+++ b/drivers/hid/hid-huawei.c
@@ -44,11 +44,12 @@ static const __u8 huawei_cd30_kbd_rdesc_fixed[] = {
static const __u8 *huawei_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+ struct usb_interface *intf = hid_is_usb(hdev) ?
+ to_usb_interface(hdev->dev.parent) : NULL;
switch (hdev->product) {
case USB_DEVICE_ID_HUAWEI_CD30KBD:
- if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
+ if (!intf || intf->cur_altsetting->desc.bInterfaceNumber == 1) {
if (*rsize != sizeof(huawei_cd30_kbd_rdesc_fixed) ||
memcmp(huawei_cd30_kbd_rdesc_fixed, rdesc,
sizeof(huawei_cd30_kbd_rdesc_fixed)) != 0) {
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 1/3] HID: asus: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-asus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67..befa990b3210 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
return ret;
}
- if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
+ if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
intf = to_usb_interface(hdev->dev.parent);
udev = interface_to_usbdev(intf);
validate_mcu_fw_version(hdev,
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 0/3] hid: fix missing hid_is_usb() checks in three drivers
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
This fixes missing hid_is_usb() checks before to_usb_interface() in
three HID drivers.
I've split it into three patches so that they can have separate "Fixes"
tags, hopefully they are easier to stable-backport this way.
Signed-off-by: Jann Horn <jannh@google.com>
---
Changes in v2:
- patch 3/3: fix typo in "Fixes" line
- patch 3/3: add USB_HID dependency (alternative would be to implement a
stub for hid_is_usb())
- Link to v1: https://patch.msgid.link/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com
---
Jann Horn (3):
HID: asus: fix missing hid_is_usb() check
HID: huawei: fix missing hid_is_usb() check
HID: rapoo: fix missing hid_is_usb() check
drivers/hid/Kconfig | 1 +
drivers/hid/hid-asus.c | 2 +-
drivers/hid/hid-huawei.c | 5 +++--
drivers/hid/hid-rapoo.c | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-usbcheck-9163e6cf6015
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply
* Re: [PATCH] HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
From: sashiko-bot @ 2026-07-03 15:42 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-asus-uaf-v1-1-1a2af2534eb0@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition in asus_remove() due to incorrect teardown order for fn_lock_sync_work, leading to Use-After-Free.
--
commit 10088228c9fb50f752e52778b8014fc75f17200d
Author: Jann Horn <jannh@google.com>
HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
This commit fixes a Use-After-Free bug where drvdata->kbd_backlight was not
set to NULL after being freed in asus_kbd_register_leds(). By explicitly
clearing the pointer when asus_hid_register_listener() fails, it prevents
asus_remove() from following a freed pointer during teardown.
Cc: stable@vger.kernel.org
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..c2a5edebbd7a7 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> if (ret < 0) {
> /* No need to have this still around */
> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> + drvdata->kbd_backlight = NULL;
> }
>
> return ret;
[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition in
asus_remove() that might lead to a Use-After-Free.
When a device is removed, asus_remove() calls cancel_work_sync() for
fn_lock_sync_work before stopping the hardware:
drivers/hid/hid-asus.c:asus_remove() {
...
if (drvdata->quirks & QUIRK_HID_FN_LOCK)
cancel_work_sync(&drvdata->fn_lock_sync_work);
hid_hw_stop(hdev);
}
If a KEY_FN_ESC event arrives in the window between these two calls, won't
the HID core invoke asus_event() and blindly requeue the work?
drivers/hid/hid-asus.c:asus_event() {
...
case KEY_FN_ESC:
if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
drvdata->fn_lock = !drvdata->fn_lock;
schedule_work(&drvdata->fn_lock_sync_work);
}
break;
...
}
Since the driver data is freed after device removal, could this executed
work access freed memory if the teardown order isn't reversed so that
hid_hw_stop() runs before cancel_work_sync()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-asus-uaf-v1-1-1a2af2534eb0@google.com?part=1
^ permalink raw reply
* Re: [PATCH 1/3] HID: asus: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:32 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v1-1-e80259ff625d@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing pointer invalidation after `devm_kfree` causes a deterministic Use-After-Free on the failure path.
--
commit d3bce769a13470fb7e8717746a98294d5eb006c9
Author: Jann Horn <jannh@google.com>
HID: asus: fix missing hid_is_usb() check
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent. Fix the use of to_usb_interface() without a
hid_is_usb() check.
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..befa990b3210e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
[Severity: High]
This is a pre-existing issue, but does the failure path in this function leave
a dangling pointer that can cause a use-after-free?
If asus_hid_register_listener() fails later in asus_kbd_register_leds():
ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
}
The memory allocated for drvdata->kbd_backlight is freed, but the pointer is
not set to NULL.
Then asus_probe() catches the failure, emits a warning, but improperly allows
probe to succeed:
if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
(asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
(asus_kbd_register_leds(hdev)))
hid_warn(hdev, "Failed to initialize backlight.\n");
If this occurs, could a subsequent call to asus_remove() or asus_resume()
dereference the freed memory?
if (drvdata->kbd_backlight) {
asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
drvdata->kbd_backlight->removed = true;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com?part=1
^ permalink raw reply
* Re: [PATCH 3/3] HID: rapoo: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:29 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v1-3-e80259ff625d@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing Kconfig dependency `depends on USB_HID` for `CONFIG_HID_RAPOO` causes a linker error.
- [Low] Malformed `Fixes:` tags in the commit message.
--
commit ac5c5d7fc93db76e1ff4b587da9d47600a05ff83
Author: Jann Horn <jannh@google.com>
HID: rapoo: fix missing hid_is_usb() check
This commit fixes a potential splat by verifying a HID device is actually on
a USB bus before casting its parent to a usb_interface.
> I have verified that it is currently possible to trigger a kernel splat due
> to this bug in an ASAN build, and that this commit fixes the issue.
>
> Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
[Severity: Low]
This isn't a bug, but there are two Fixes tags concatenated on the same line.
Could this break automated patch parsing tools and stable backporting scripts
that expect each tag to be on a separate line?
> Cc: stable@vger.kernel.org
> Signed-off-by: Jann Horn <jannh@google.com>
>
> diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
> index 4c81f3086de43..5c9c396fabf77 100644
> --- a/drivers/hid/hid-rapoo.c
> +++ b/drivers/hid/hid-rapoo.c
[ ... ]
> @@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> - if (hdev->bus == BUS_USB) {
> + if (hid_is_usb(hdev)) {
[Severity: Low]
Does the introduction of hid_is_usb() in rapoo_probe() require an update to
the CONFIG_HID_RAPOO entry in drivers/hid/Kconfig?
Because hid_is_usb() is defined and exported exclusively by the usbhid module,
if a user configures the kernel with CONFIG_HID_RAPOO=y and CONFIG_USB_HID=n
(or m), will this cause a build failure during the linking stage due to an
undefined reference?
Should CONFIG_HID_RAPOO now explicitly depend on USB_HID?
> struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>
> if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com?part=3
^ permalink raw reply
* [PATCH] HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
From: Jann Horn @ 2026-07-03 15:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Carlo Caione, linux-input, linux-kernel, stable, Jann Horn
On kernels without !CONFIG_ASUS_WMI, asus_hid_register_listener() will
fail. asus_kbd_register_leds() reacts to this by freeing
drvdata->kbd_backlight, but doesn't NULL out the pointer, causing UAF when
asus_remove() follows this pointer.
I have tested that this bug causes an ASAN splat, and that this change
fixes the issue.
Cc: stable@vger.kernel.org
Fixes: af22a610bc38 ("HID: asus: support backlight on USB keyboards")
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-asus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67..c2a5edebbd7a 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
+ drvdata->kbd_backlight = NULL;
}
return ret;
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-asus-uaf-0b8e1325fc00
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* [PATCH 3/3] HID: rapoo: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v1-0-e80259ff625d@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-rapoo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
index 4c81f3086de4..5c9c396fabf7 100644
--- a/drivers/hid/hid-rapoo.c
+++ b/drivers/hid/hid-rapoo.c
@@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
- if (hdev->bus == BUS_USB) {
+ if (hid_is_usb(hdev)) {
struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox