* [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device
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 Maple bus core invokes client callbacks asynchronously from a
workqueue (maple_dma_handler). If a device is removed (or closed) while
a callback is in flight, it can lead to UAF bugs if the driver's private
data is freed.
Introduce callback_mutex in struct maple_device to synchronize
callback registration/modification and callback invocation.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/sh/maple/maple.c | 9 +++++++--
include/linux/maple.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index c0715e3ace6f..7c82b7a8a280 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -121,6 +121,7 @@ void maple_getcond_callback(struct maple_device *dev,
void (*callback) (struct mapleq *mq),
unsigned long interval, unsigned long function)
{
+ guard(mutex)(&dev->callback_mutex);
dev->callback = callback;
dev->interval = interval;
dev->function = cpu_to_be32(function);
@@ -230,11 +231,13 @@ static struct maple_device *maple_alloc_dev(int port, int unit)
mdev->dev.bus = &maple_bus_type;
mdev->dev.parent = &maple_bus;
init_waitqueue_head(&mdev->maple_wait);
+ mutex_init(&mdev->callback_mutex);
return mdev;
}
static void maple_free_dev(struct maple_device *mdev)
{
+ mutex_destroy(&mdev->callback_mutex);
kmem_cache_free(maple_queue_cache, mdev->mq->recvbuf);
kfree(mdev->mq);
kfree(mdev);
@@ -655,8 +658,10 @@ static void maple_dma_handler(struct work_struct *work)
break;
case MAPLE_RESPONSE_DATATRF:
- if (mdev->callback)
- mdev->callback(mq);
+ scoped_guard(mutex, &mdev->callback_mutex) {
+ if (mdev->callback)
+ mdev->callback(mq);
+ }
atomic_set(&mdev->busy, 0);
wake_up(&mdev->maple_wait);
break;
diff --git a/include/linux/maple.h b/include/linux/maple.h
index 641cf3330409..48ed7558b8ab 100644
--- a/include/linux/maple.h
+++ b/include/linux/maple.h
@@ -3,6 +3,7 @@
#define __LINUX_MAPLE_H
#include <linux/device.h>
+#include <linux/mutex.h>
#include <mach/maple.h>
/* Maple Bus command and response codes */
@@ -75,6 +76,7 @@ struct maple_device {
char product_licence[64];
atomic_t busy;
wait_queue_head_t maple_wait;
+ struct mutex callback_mutex;
struct device dev;
};
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 19/26] Input: maple_keyb - remove redundant mutex and remove method
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>
Now that the Maple bus core handles callback synchronization via
callback_mutex, the keyboard-driver-specific maple_keyb_mutex
is redundant.
Remove the mutex and its usage. Since the mutex was the only reason
we kept the remove method (to synchronize during detach), we can
now remove remove_maple_kbd entirely. The devm-managed resource
cleanup is sufficient.
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, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index ab9257db7e03..aa9a4a80e26f 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -14,9 +14,6 @@
#include <linux/timer.h>
#include <linux/maple.h>
-/* Very simple mutex to ensure proper cleanup */
-static DEFINE_MUTEX(maple_keyb_mutex);
-
#define NR_SCANCODES 256
MODULE_AUTHOR("Adrian McMenamin <adrian@mcmen.demon.co.uk");
@@ -128,15 +125,9 @@ static void dc_kbd_callback(struct mapleq *mq)
struct dc_kbd *kbd = maple_get_drvdata(mapledev);
unsigned long *buf = (unsigned long *)(mq->recvbuf->buf);
- /*
- * We should always get the lock because the only
- * time it may be locked is if the driver is in the cleanup phase.
- */
- scoped_guard(mutex_try, &maple_keyb_mutex) {
- if (buf[1] == mapledev->function) {
- memcpy(kbd->new, buf + 2, 8);
- dc_scan_kbd(kbd);
- }
+ if (buf[1] == mapledev->function) {
+ memcpy(kbd->new, buf + 2, 8);
+ dc_scan_kbd(kbd);
}
}
@@ -211,22 +202,12 @@ static int probe_maple_kbd(struct maple_device *mdev)
return error;
}
-static void remove_maple_kbd(struct maple_device *mdev)
-{
- struct dc_kbd *kbd = maple_get_drvdata(mdev);
- guard(mutex)(&maple_keyb_mutex);
- input_unregister_device(kbd->dev);
- kfree(kbd);
-
-
-}
static struct maple_driver dc_kbd_driver = {
.function = MAPLE_FUNC_KEYBOARD,
.probe = probe_maple_kbd,
- .remove = remove_maple_kbd,
.drv = {
.name = "Dreamcast_keyboard",
},
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 20/26] Input: maple_keyb - convert to devm
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>
Convert the driver to use managed resources to simplify resource
lifecycle management.
This eliminates manual error handling in probe() and removes manual
input device unregistration and memory freeing from remove().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index aa9a4a80e26f..bd4ce803a13e 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -155,17 +155,13 @@ static int probe_maple_kbd(struct maple_device *mdev)
struct dc_kbd *kbd;
struct input_dev *idev;
- kbd = kzalloc_obj(*kbd);
- if (!kbd) {
- error = -ENOMEM;
- goto fail;
- }
+ kbd = devm_kzalloc(&mdev->dev, sizeof(*kbd), GFP_KERNEL);
+ if (!kbd)
+ return -ENOMEM;
- idev = input_allocate_device();
- if (!idev) {
- error = -ENOMEM;
- goto fail_idev_alloc;
- }
+ idev = devm_input_allocate_device(&mdev->dev);
+ if (!idev)
+ return -ENOMEM;
kbd->dev = idev;
memcpy(kbd->keycode, dc_kbd_keycode, sizeof(kbd->keycode));
@@ -179,7 +175,6 @@ static int probe_maple_kbd(struct maple_device *mdev)
idev->keycodesize = sizeof(unsigned short);
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;
@@ -191,15 +186,9 @@ static int probe_maple_kbd(struct maple_device *mdev)
error = input_register_device(idev);
if (error)
- goto fail_register;
- return error;
-
-fail_register:
- input_free_device(idev);
-fail_idev_alloc:
- kfree(kbd);
-fail:
- return error;
+ return error;
+
+ return 0;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 21/26] Input: maplemouse - convert to devm
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>
Convert the driver to use managed resources to simplify resource
lifecycle management.
This eliminates manual error handling in probe() and allows removing
the remove() callback entirely, as all cleanup is handled automatically.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/maplemouse.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index 03cb666d278d..7842bd46c9a1 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -70,17 +70,13 @@ static int probe_maple_mouse(struct maple_device *mdev)
struct input_dev *input_dev;
struct dc_mouse *mse;
- mse = kzalloc_obj(*mse);
- if (!mse) {
- error = -ENOMEM;
- goto fail;
- }
-
- input_dev = input_allocate_device();
- if (!input_dev) {
- error = -ENOMEM;
- goto fail_nomem;
- }
+ mse = devm_kzalloc(&mdev->dev, sizeof(*mse), GFP_KERNEL);
+ if (!mse)
+ return -ENOMEM;
+
+ input_dev = devm_input_allocate_device(&mdev->dev);
+ if (!input_dev)
+ return -ENOMEM;
mse->dev = input_dev;
mse->mdev = mdev;
@@ -99,29 +95,14 @@ static int probe_maple_mouse(struct maple_device *mdev)
input_dev->id.bustype = BUS_HOST;
error = input_register_device(input_dev);
if (error)
- goto fail_register;
- return error;
-
-fail_register:
- input_free_device(input_dev);
-fail_nomem:
- kfree(mse);
-fail:
- return error;
-}
+ return error;
-static void remove_maple_mouse(struct maple_device *mdev)
-{
- struct dc_mouse *mse = maple_get_drvdata(mdev);
-
- input_unregister_device(mse->dev);
- kfree(mse);
+ return 0;
}
static struct maple_driver dc_mouse_driver = {
.function = MAPLE_FUNC_MOUSE,
.probe = probe_maple_mouse,
- .remove = remove_maple_mouse,
.drv = {
.name = "Dreamcast_mouse",
},
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 22/26] Input: maplecontrol - convert to devm
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>
Convert the driver to use managed resources to simplify resource
lifecycle management.
This eliminates manual error handling in probe() and allows removing
the remove() callback entirely, as all cleanup is handled automatically.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 30 +++++++++---------------------
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 6864243b0b4a..3ef6652d40cb 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -99,12 +99,13 @@ static int probe_maple_controller(struct maple_device *mdev)
struct input_dev *idev;
unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
- pad = kzalloc_obj(*pad);
- idev = input_allocate_device();
- if (!pad || !idev) {
- error = -ENOMEM;
- goto fail;
- }
+ pad = devm_kzalloc(&mdev->dev, sizeof(*pad), GFP_KERNEL);
+ if (!pad)
+ return -ENOMEM;
+
+ idev = devm_input_allocate_device(&mdev->dev);
+ if (!idev)
+ return -ENOMEM;
pad->dev = idev;
pad->mdev = mdev;
@@ -129,33 +130,20 @@ static int probe_maple_controller(struct maple_device *mdev)
if (idev->keybit[BIT_WORD(BTN_JOYSTICK)])
idev->evbit[0] |= BIT_MASK(EV_KEY);
- idev->dev.parent = &mdev->dev;
idev->name = mdev->product_name;
idev->id.bustype = BUS_HOST;
error = input_register_device(idev);
if (error)
- goto fail;
- return 0;
+ return error;
-fail:
- input_free_device(idev);
- kfree(pad);
- return error;
-}
-
-static void remove_maple_controller(struct maple_device *mdev)
-{
- struct dc_pad *pad = maple_get_drvdata(mdev);
+ return 0;
- input_unregister_device(pad->dev);
- kfree(pad);
}
static struct maple_driver dc_pad_driver = {
.function = MAPLE_FUNC_CONTROLLER,
.probe = probe_maple_controller,
- .remove = remove_maple_controller,
.drv = {
.name = "Dreamcast_controller",
},
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 23/26] Input: maple_keyb - fix style issues
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>
Fix coding style and formatting issues reported by checkpatch.pl.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index bd4ce803a13e..1d99ed5bad1e 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -48,7 +48,7 @@ static const unsigned short dc_kbd_keycode[NR_SCANCODES] = {
KEY_F23, KEY_F24, KEY_OPEN, KEY_HELP, KEY_PROPS, KEY_FRONT, KEY_STOP,
KEY_AGAIN, KEY_UNDO, KEY_CUT, KEY_COPY, KEY_PASTE, KEY_FIND, KEY_MUTE,
KEY_VOLUMEUP, KEY_VOLUMEDOWN, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
- KEY_KPCOMMA, KEY_RESERVED, KEY_RO, KEY_KATAKANAHIRAGANA , KEY_YEN,
+ KEY_KPCOMMA, KEY_RESERVED, KEY_RO, KEY_KATAKANAHIRAGANA, KEY_YEN,
KEY_HENKAN, KEY_MUHENKAN, KEY_KPJPCOMMA, KEY_RESERVED, KEY_RESERVED,
KEY_RESERVED, KEY_HANGEUL, KEY_HANJA, KEY_KATAKANA, KEY_HIRAGANA,
KEY_ZENKAKUHANKAKU, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
@@ -92,15 +92,16 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
for (i = 2; i < 8; i++) {
ptr = memchr(kbd->new + 2, kbd->old[i], 6);
code = kbd->old[i];
- if (code > 3 && ptr == NULL) {
+ if (code > 3 && !ptr) {
keycode = kbd->keycode[code];
if (keycode) {
input_event(dev, EV_MSC, MSC_SCAN, code);
input_report_key(dev, keycode, 0);
- } else
+ } else {
dev_dbg(&dev->dev,
"Unknown key (scancode %#x) released.",
code);
+ }
}
ptr = memchr(kbd->old + 2, kbd->new[i], 6);
code = kbd->new[i];
@@ -109,10 +110,11 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
if (keycode) {
input_event(dev, EV_MSC, MSC_SCAN, code);
input_report_key(dev, keycode, 1);
- } else
+ } else {
dev_dbg(&dev->dev,
"Unknown key (scancode %#x) pressed.",
code);
+ }
}
}
input_sync(dev);
@@ -191,9 +193,6 @@ static int probe_maple_kbd(struct maple_device *mdev)
return 0;
}
-
-
-
static struct maple_driver dc_kbd_driver = {
.function = MAPLE_FUNC_KEYBOARD,
.probe = probe_maple_kbd,
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 24/26] Input: maplemouse - fix style issues
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>
Fix coding style and formatting issues reported by checkpatch.pl.
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, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index 7842bd46c9a1..691cf334ae9c 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -50,8 +50,8 @@ static int dc_mouse_open(struct input_dev *dev)
{
struct dc_mouse *mse = input_get_drvdata(dev);
- maple_getcond_callback(mse->mdev, dc_mouse_callback, HZ/50,
- MAPLE_FUNC_MOUSE);
+ maple_getcond_callback(mse->mdev, dc_mouse_callback, HZ / 50,
+ MAPLE_FUNC_MOUSE);
return 0;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 25/26] Input: maplecontrol - fix style issues
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>
Fix coding style and formatting issues reported by checkpatch.pl and
switch to using BIT(). When reporting D-PAD events avoid conditionals.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 3ef6652d40cb..457a73d91239 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -35,22 +35,22 @@ static void dc_pad_callback(struct mapleq *mq)
buttons = ~le16_to_cpup((__le16 *)(res + 8));
input_report_abs(dev, ABS_HAT0Y,
- (buttons & 0x0010 ? -1 : 0) + (buttons & 0x0020 ? 1 : 0));
+ !!(buttons & BIT(5)) - !!(buttons & BIT(4)));
input_report_abs(dev, ABS_HAT0X,
- (buttons & 0x0040 ? -1 : 0) + (buttons & 0x0080 ? 1 : 0));
+ !!(buttons & BIT(7)) - !!(buttons & BIT(6)));
input_report_abs(dev, ABS_HAT1Y,
- (buttons & 0x1000 ? -1 : 0) + (buttons & 0x2000 ? 1 : 0));
+ !!(buttons & BIT(13)) - !!(buttons & BIT(12)));
input_report_abs(dev, ABS_HAT1X,
- (buttons & 0x4000 ? -1 : 0) + (buttons & 0x8000 ? 1 : 0));
+ !!(buttons & BIT(15)) - !!(buttons & BIT(14)));
- input_report_key(dev, BTN_C, buttons & 0x0001);
- input_report_key(dev, BTN_B, buttons & 0x0002);
- input_report_key(dev, BTN_A, buttons & 0x0004);
- input_report_key(dev, BTN_START, buttons & 0x0008);
- input_report_key(dev, BTN_Z, buttons & 0x0100);
- input_report_key(dev, BTN_Y, buttons & 0x0200);
- input_report_key(dev, BTN_X, buttons & 0x0400);
- input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+ input_report_key(dev, BTN_C, buttons & BIT(0));
+ input_report_key(dev, BTN_B, buttons & BIT(1));
+ input_report_key(dev, BTN_A, buttons & BIT(2));
+ input_report_key(dev, BTN_START, buttons & BIT(3));
+ input_report_key(dev, BTN_Z, buttons & BIT(8));
+ input_report_key(dev, BTN_Y, buttons & BIT(9));
+ input_report_key(dev, BTN_X, buttons & BIT(10));
+ input_report_key(dev, BTN_SELECT, buttons & BIT(11));
input_report_abs(dev, ABS_GAS, res[10]);
input_report_abs(dev, ABS_BRAKE, res[11]);
@@ -138,7 +138,6 @@ static int probe_maple_controller(struct maple_device *mdev)
return error;
return 0;
-
}
static struct maple_driver dc_pad_driver = {
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 26/26] Input: maple_keyb - remove redundant 'new' buffer from struct dc_kbd
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 'new' buffer in struct dc_kbd is only ever used as a temporary
staging area during dc_kbd_callback() to pass the received hardware
packet to dc_scan_kbd().
Remove 'new' from struct dc_kbd entirely and pass the received buffer
pointer directly to dc_scan_kbd(). This saves 8 bytes in struct dc_kbd
and avoids an unnecessary 8-byte memcpy on every keyboard poll cycle.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/maple_keyb.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index 1d99ed5bad1e..5b10c6ba7bd5 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -23,8 +23,7 @@ MODULE_LICENSE("GPL");
struct dc_kbd {
struct input_dev *dev;
unsigned short keycode[NR_SCANCODES];
- unsigned char new[8];
- unsigned char old[8];
+ u8 old[8];
};
static const unsigned short dc_kbd_keycode[NR_SCANCODES] = {
@@ -75,7 +74,7 @@ static const unsigned short dc_kbd_keycode[NR_SCANCODES] = {
KEY_CALC, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED
};
-static void dc_scan_kbd(struct dc_kbd *kbd)
+static void dc_scan_kbd(struct dc_kbd *kbd, const u8 *new)
{
struct input_dev *dev = kbd->dev;
void *ptr;
@@ -86,11 +85,11 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
code = i + 224;
keycode = kbd->keycode[code];
input_event(dev, EV_MSC, MSC_SCAN, code);
- input_report_key(dev, keycode, (kbd->new[0] >> i) & 1);
+ input_report_key(dev, keycode, (new[0] >> i) & 1);
}
for (i = 2; i < 8; i++) {
- ptr = memchr(kbd->new + 2, kbd->old[i], 6);
+ ptr = memchr(new + 2, kbd->old[i], 6);
code = kbd->old[i];
if (code > 3 && !ptr) {
keycode = kbd->keycode[code];
@@ -103,8 +102,8 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
code);
}
}
- ptr = memchr(kbd->old + 2, kbd->new[i], 6);
- code = kbd->new[i];
+ ptr = memchr(kbd->old + 2, new[i], 6);
+ code = new[i];
if (code > 3 && !ptr) {
keycode = kbd->keycode[code];
if (keycode) {
@@ -118,19 +117,17 @@ static void dc_scan_kbd(struct dc_kbd *kbd)
}
}
input_sync(dev);
- memcpy(kbd->old, kbd->new, 8);
+ memcpy(kbd->old, new, 8);
}
static void dc_kbd_callback(struct mapleq *mq)
{
struct maple_device *mapledev = mq->dev;
struct dc_kbd *kbd = maple_get_drvdata(mapledev);
- unsigned long *buf = (unsigned long *)(mq->recvbuf->buf);
+ unsigned long *buf = mq->recvbuf->buf;
- if (buf[1] == mapledev->function) {
- memcpy(kbd->new, buf + 2, 8);
- dc_scan_kbd(kbd);
- }
+ if (buf[1] == mapledev->function)
+ dc_scan_kbd(kbd, mq->recvbuf->buf + 8);
}
static int dc_kbd_open(struct input_dev *dev)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 1/3] Input: mms114 - fix multi-touch slot corruption
From: Dmitry Torokhov @ 2026-07-04 6:01 UTC (permalink / raw)
To: linux-input
Cc: Bryam Vargas, Linus Walleij, linux-kernel, stable, sashiko-bot
If the touchscreen controller reports a touch ID of 0, the driver
calculates the slot ID as touch->id - 1, which underflows to UINT_MAX.
This is passed to input_mt_slot() as -1.
Since the input core ignores negative slot values, the active slot remains
unchanged. The driver then reports the touch coordinates for the previously
active slot, corrupting its state.
Fix this by rejecting touch reports with ID 0.
Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver")
Cc: stable@vger.kernel.org
Reported-by: sashiko-bot@kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/touchscreen/mms114.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 006dded17eb8..23e0283bc6b8 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -248,7 +248,7 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
unsigned int x;
unsigned int y;
- if (touch->id > MMS114_MAX_TOUCH) {
+ if (touch->id == 0 || touch->id > MMS114_MAX_TOUCH) {
dev_err(&client->dev, "Wrong touch id (%d)\n", touch->id);
return;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 2/3] Input: mms114 - fix endianness portability in I2C packet layout
From: Dmitry Torokhov @ 2026-07-04 6:01 UTC (permalink / raw)
To: linux-input; +Cc: Bryam Vargas, Linus Walleij, linux-kernel, sashiko-bot
In-Reply-To: <20260704060115.353049-1-dmitry.torokhov@gmail.com>
The driver defines the I2C packet layout using C bitfields in struct
mms114_touch. This is not portable as the layout of bitfields within a
byte is compiler-dependent and varies with endianness. On Big Endian
systems, the fields will be parsed incorrectly.
Fix this by redefining struct mms114_touch with plain u8 fields and
introducing bitwise macros to extract the values portably.
Reported-by: sashiko-bot@kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/touchscreen/mms114.c | 52 +++++++++++++++++++-----------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 23e0283bc6b8..84afdadb3bcc 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -4,6 +4,8 @@
// Copyright (c) 2012 Samsung Electronics Co., Ltd.
// Author: Joonyoung Shim <jy0922.shim@samsung.com>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/of.h>
@@ -76,9 +78,16 @@ struct mms_chip {
int (*get_version)(struct mms114_data *data);
};
+#define MMS114_FLAGS_ID_MASK GENMASK(3, 0)
+#define MMS114_FLAGS_TYPE_MASK GENMASK(6, 5)
+#define MMS114_FLAGS_PRESSED_MASK BIT(7)
+
+#define MMS114_XY_HI_X_MASK GENMASK(3, 0)
+#define MMS114_XY_HI_Y_MASK GENMASK(7, 4)
+
struct mms114_touch {
- u8 id:4, reserved_bit4:1, type:2, pressed:1;
- u8 x_hi:4, y_hi:4;
+ u8 flags;
+ u8 xy_hi;
u8 x_lo;
u8 y_lo;
u8 width;
@@ -244,28 +253,30 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
{
struct i2c_client *client = data->client;
struct input_dev *input_dev = data->input_dev;
- unsigned int id;
+ unsigned int id = FIELD_GET(MMS114_FLAGS_ID_MASK, touch->flags);
+ unsigned int type = FIELD_GET(MMS114_FLAGS_TYPE_MASK, touch->flags);
+ bool pressed = FIELD_GET(MMS114_FLAGS_PRESSED_MASK, touch->flags);
unsigned int x;
unsigned int y;
- if (touch->id == 0 || touch->id > MMS114_MAX_TOUCH) {
- dev_err(&client->dev, "Wrong touch id (%d)\n", touch->id);
+ if (id == 0 || id > MMS114_MAX_TOUCH) {
+ dev_err(&client->dev, "Wrong touch id (%d)\n", id);
return;
}
- id = touch->id - 1;
- x = touch->x_lo | touch->x_hi << 8;
- y = touch->y_lo | touch->y_hi << 8;
+ id--;
+ x = touch->x_lo | FIELD_GET(MMS114_XY_HI_X_MASK, touch->xy_hi) << 8;
+ y = touch->y_lo | FIELD_GET(MMS114_XY_HI_Y_MASK, touch->xy_hi) << 8;
dev_dbg(&client->dev,
"id: %d, type: %d, pressed: %d, x: %d, y: %d, width: %d, strength: %d\n",
- id, touch->type, touch->pressed,
+ id, type, pressed,
x, y, touch->width, touch->strength);
input_mt_slot(input_dev, id);
- input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, touch->pressed);
+ input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, pressed);
- if (touch->pressed) {
+ if (pressed) {
touchscreen_report_pos(input_dev, &data->props, x, y, true);
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, touch->width);
input_report_abs(input_dev, ABS_MT_PRESSURE, touch->strength);
@@ -278,21 +289,23 @@ static void mms114_process_touchkey(struct mms114_data *data,
struct i2c_client *client = data->client;
struct input_dev *input_dev = data->input_dev;
unsigned int keycode_id;
+ unsigned int id = FIELD_GET(MMS114_FLAGS_ID_MASK, touch->flags);
+ bool pressed = FIELD_GET(MMS114_FLAGS_PRESSED_MASK, touch->flags);
- if (touch->id == 0)
+ if (id == 0)
return;
- if (touch->id > data->num_keycodes) {
+ if (id > data->num_keycodes) {
dev_err(&client->dev, "Wrong touch id for touchkey (%d)\n",
- touch->id);
+ id);
return;
}
- keycode_id = touch->id - 1;
+ keycode_id = id - 1;
dev_dbg(&client->dev, "keycode id: %d, pressed: %d\n", keycode_id,
- touch->pressed);
+ pressed);
- input_report_key(input_dev, data->keycodes[keycode_id], touch->pressed);
+ input_report_key(input_dev, data->keycodes[keycode_id], pressed);
}
static irqreturn_t mms114_interrupt(int irq, void *dev_id)
@@ -325,8 +338,9 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
for (index = 0; index < touch_size; index++) {
t = (struct mms114_touch *)((u8 *)touch + index * event_size);
+ unsigned int type = FIELD_GET(MMS114_FLAGS_TYPE_MASK, t->flags);
- switch (t->type) {
+ switch (type) {
case MMS114_TYPE_TOUCHSCREEN:
mms114_process_mt(data, t);
break;
@@ -337,7 +351,7 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
default:
dev_err(&client->dev, "Wrong touch type (%d)\n",
- t->type);
+ type);
break;
}
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 3/3] Input: mms114 - fix Y-resolution configuration
From: Dmitry Torokhov @ 2026-07-04 6:01 UTC (permalink / raw)
To: linux-input; +Cc: Bryam Vargas, Linus Walleij, linux-kernel
In-Reply-To: <20260704060115.353049-1-dmitry.torokhov@gmail.com>
In mms114_setup_regs(), the driver mistakenly uses props->max_x instead
of props->max_y when configuring the low bits of the Y resolution
(MMS114_Y_RESOLUTION).
Fix this by using the correct property.
Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/touchscreen/mms114.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 84afdadb3bcc..27911a9f4e9e 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -408,7 +408,7 @@ static int mms114_setup_regs(struct mms114_data *data)
if (error < 0)
return error;
- val = props->max_x & 0xff;
+ val = props->max_y & 0xff;
error = mms114_write_reg(data, MMS114_Y_RESOLUTION, val);
if (error < 0)
return error;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH 01/26] sh: maple: include linux/device.h in linux/maple.h
From: sashiko-bot @ 2026-07-04 6:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260703-b4-maple-cleanup-v1-1-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] The error path in `vmu_queryblocks` frees the `priv` field of previously registered MTD partitions without unregistering them, leaving dangling MTD devices that crash the kernel if accessed.
- [High] `vmu_disconnect` assumes all partitions have a fully initialized `priv` structure and unconditionally dereferences it, which causes a NULL pointer dereference if initialization failed or was incomplete.
- [High] `vmu_disconnect` fails to free multiple dynamically allocated structures, causing a severe memory leak on device removal.
- [High] `vmu_flash_read_char` truncates negative error codes into an `unsigned char`, causing the caller to silently misinterpret errors as valid data.
--
commit 3694a7f48be1fa76db703e9eae953d9ee9757f9f
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
sh: maple: include linux/device.h in linux/maple.h
This commit includes linux/device.h in linux/maple.h to ensure full
definitions of struct device and struct device_driver are available.
This fixes a compilation error in drivers/mtd/maps/vmu-flash.c.
> diff --git a/include/linux/maple.h b/include/linux/maple.h
> index 3be4e567473c8..22f2930251edc 100644
> --- a/include/linux/maple.h
> +++ b/include/linux/maple.h
[ ... ]
While this patch fixes the build, looking at drivers/mtd/maps/vmu-flash.c
revealed a few pre-existing issues:
drivers/mtd/maps/vmu-flash.c:vmu_flash_read_char() {
...
unsigned char *buf, ret;
...
error = maple_vmu_read_block(vblock->num, buf, mtd);
if (error) {
ret = error;
*retval = 2;
goto out_vblock;
}
...
return ret;
}
[Severity: High]
This is a pre-existing issue, but does assigning a negative error code
like -ENOMEM or -EIO to the unsigned char ret truncate it? This could
cause the caller to misinterpret errors as valid data instead of properly
propagating the negative error code back to the MTD subsystem.
drivers/mtd/maps/vmu-flash.c:vmu_queryblocks() {
...
error = mtd_device_register(mtd_cur, NULL, 0);
if (error)
goto fail_mtd_register;
...
fail_mpart:
for (error = 0; error <= card->partition; error++) {
kfree(((card->mtd)[error]).priv);
((card->mtd)[error]).priv = NULL;
}
...
}
[Severity: High]
This isn't a bug introduced by this patch, but could this cleanup loop
fail to unregister the previously successfully registered MTD devices?
If a recursive call fails, freeing the priv field without calling
mtd_device_unregister() might leave dangling MTD devices that could
crash the kernel if accessed later.
drivers/mtd/maps/vmu-flash.c:vmu_disconnect() {
...
for (x = 0; x < card->partitions; x++) {
mpart = ((card->mtd)[x]).priv;
mpart->mdev = NULL;
mtd_device_unregister(&((card->mtd)[x]));
kfree(((card->parts)[x]).name);
}
...
}
[Severity: High]
This is a pre-existing issue, but does this assume all partitions have a
fully initialized priv structure? If the device is disconnected before
vmu_queryblocks() finishes initialization or if initialization fails,
can mpart be NULL here, leading to a NULL pointer dereference when
assigning mpart->mdev = NULL?
[Severity: High]
This is also a pre-existing issue, but does this disconnect routine leak
resources? It appears to omit freeing the mpart, pcache, and pcache->buffer
resources that were allocated during initialization.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 12/26] Input: maplecontrol - remove unused mdev->driver assignment
From: sashiko-bot @ 2026-07-04 6:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-12-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing `input_sync()` after reporting events in the maple controller callback.
--
commit 0fbd521bb62afe1470ddde2cd989f82804cfb127
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - remove unused mdev->driver assignment
The driver field in struct maple_device is no longer used since commit
1795cf48b322 ("sh/maple: clean maple bus code") which removed the reading
of this field. Remove the unused assignment to mdev->driver and the now
unused mdrv variable in probe_maple_controller.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 79cec89ad52a9..955e01bcfa0c1 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -95,7 +95,6 @@ static int probe_maple_controller(struct device *dev)
> };
>
> struct maple_device *mdev = to_maple_dev(dev);
> - struct maple_driver *mdrv = to_maple_driver(dev->driver);
> int i, error;
> struct dc_pad *pad;
> struct input_dev *idev;
> @@ -138,9 +137,6 @@ static int probe_maple_controller(struct device *dev)
> error = input_register_device(idev);
> if (error)
> goto fail;
> -
> - mdev->driver = mdrv;
> -
> return 0;
>
> fail:
[Severity: High]
This isn't a bug introduced by this patch, but I noticed an issue in this
file while reviewing the driver.
Does the hardware callback need to emit a synchronization event after
reporting the controller state?
Looking at drivers/input/joystick/maplecontrol.c:dc_pad_callback():
...
input_report_abs(dev, ABS_X, res[12]);
input_report_abs(dev, ABS_Y, res[13]);
input_report_abs(dev, ABS_RX, res[14]);
input_report_abs(dev, ABS_RY, res[15]);
}
Without calling input_sync() at the end of this logical group of events,
userspace clients will not receive SYN_REPORT. Won't this cause them to
buffer events indefinitely and prevent the gamepad from functioning?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=12
^ permalink raw reply
* Re: [PATCH 05/26] Input: maplecontrol - stop polling and clear callback on close
From: sashiko-bot @ 2026-07-04 6:07 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260703-b4-maple-cleanup-v1-5-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The event reporting loop in `dc_pad_callback()` does not call `input_sync()` after reporting a group of input events.
--
commit 5b43e607496d623e78583ef58f7527944fe7a924
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - stop polling and clear callback on close
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.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index a498fc322c4d5..c66b2614e2982 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);
> }
[Severity: High]
This isn't a bug introduced by this patch, but since dc_pad_callback() is
involved here, is there a missing call to input_sync()?
Looking at dc_pad_callback(), it reports several events without ever flushing
them:
drivers/input/joystick/maplecontrol.c:dc_pad_callback() {
...
input_report_abs(dev, ABS_RX, res[14]);
input_report_abs(dev, ABS_RY, res[15]);
}
Without input_sync(), EV_SYN/SYN_REPORT events are never generated.
Will this prevent the input core from waking up userspace readers (like
evdev), causing reported events to be indefinitely buffered until the buffer
overflows?
Since maple_dma_handler calls dc_pad_callback() on every data transfer to
report new joystick states, does this omission break event propagation and
make the joystick unresponsive for applications relying on poll() or blocking
read()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 3/3] Input: mms114 - fix Y-resolution configuration
From: sashiko-bot @ 2026-07-04 6:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260704060115.353049-3-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unsafe DMA buffer allocation on the stack for I2C transfers.
--
commit b2ece0d05aab20ebd4014035e04b87c4d9127c9f
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Input: mms114 - fix Y-resolution configuration
This commit fixes a copy-paste error in mms114_setup_regs() where
props->max_x was being used instead of props->max_y to configure the
lower bits of the Y resolution.
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index 84afdadb3bccc..27911a9f4e9eb 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -408,7 +408,7 @@ static int mms114_setup_regs(struct mms114_data *data)
> if (error < 0)
> return error;
>
> - val = props->max_x & 0xff;
> + val = props->max_y & 0xff;
> error = mms114_write_reg(data, MMS114_Y_RESOLUTION, val);
[Severity: High]
This is a pre-existing issue, but since mms114_write_reg() is called here,
is it safe for the driver to use stack-allocated buffers for I2C transfers?
Looking at mms114_write_reg():
static int mms114_write_reg(struct mms114_data *data, u8 reg, u8 val)
{
struct i2c_client *client = data->client;
u8 buf[2];
...
buf[0] = reg;
buf[1] = val;
error = i2c_master_send(client, buf, 2);
If the underlying I2C adapter uses DMA for transfers and CONFIG_VMAP_STACK is
enabled, passing a stack-allocated buffer to i2c_master_send() can cause memory
corruption or kernel panics because stack memory is not DMA-safe.
A similar pattern appears in __mms114_read_reg() and mms114_interrupt():
static int __mms114_read_reg(struct mms114_data *data, unsigned int reg, ...)
{
...
u8 buf = reg;
...
xfer[0].buf = &buf;
...
error = i2c_transfer(client->adapter, xfer, 2);
and in mms114_interrupt(), a large array is allocated on the stack and passed
down through __mms114_read_reg():
struct mms114_touch touch[MMS114_MAX_TOUCH];
...
error = __mms114_read_reg(data, MMS114_INFORMATION,
MMS114_MAX_TOUCH * sizeof(struct mms114_touch),
(u8 *)touch);
Could these stack-allocated buffers lead to instability on DMA-capable I2C
controllers? Should these buffers be moved to the mms114_data struct so they
are dynamically allocated on the heap?
> if (error < 0)
> return error;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260704060115.353049-1-dmitry.torokhov@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 14/26] mtd: maps: vmu-flash: remove unused mdev->driver assignment
From: sashiko-bot @ 2026-07-04 6:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260703-b4-maple-cleanup-v1-14-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Dangling pointers for `fileerr_handler` and `can_unload` left on `maple_device` if `probe` fails.
- [Critical] Use-after-free of `card` structure due to dangling `mdev->callback` on probe error path.
- [High] Out-of-bounds read in `vmu_connect` when parsing device `function_data`.
- [High] NULL pointer dereference in `vmu_disconnect` if `vmu_queryblocks` fails.
--
commit aec7eca58a1d1d49c7c51af4d1d0fb848ff3245c
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
mtd: maps: vmu-flash: remove unused mdev->driver assignment
This commit removes the unused assignment to mdev->driver and the now unused
mdrv variable in probe_maple_vmu. The driver field in struct maple_device is
no longer used since earlier cleanups.
> diff --git a/drivers/mtd/maps/vmu-flash.c b/drivers/mtd/maps/vmu-flash.c
> index 10244e6731d07..8f7028ac1b56a 100644
> --- a/drivers/mtd/maps/vmu-flash.c
> +++ b/drivers/mtd/maps/vmu-flash.c
> @@ -772,11 +772,9 @@ static void vmu_file_error(struct maple_device *mdev, void *recvbuf)
> static int probe_maple_vmu(struct device *dev)
> {
> struct maple_device *mdev = to_maple_dev(dev);
> - struct maple_driver *mdrv = to_maple_driver(dev->driver);
>
> mdev->can_unload = vmu_can_unload;
> mdev->fileerr_handler = vmu_file_error;
> - mdev->driver = mdrv;
>
> return vmu_connect(mdev);
[Severity: Critical]
This is a pre-existing issue, but if vmu_connect() fails below, are these
pointers properly cleared?
If vmu_connect() fails, the probe aborts and the device is left unbound, but
the function pointers to vmu_can_unload() and vmu_file_error() remain
assigned to the persistent maple_device structure.
If the vmu-flash module is subsequently unloaded, could a later
MAPLE_RESPONSE_FILEERR event cause the maple bus core to dereference the
now-dangling mdev->fileerr_handler pointer?
> }
While reviewing the context of this patch, I noticed a few other pre-existing
issues in the surrounding code:
> static int vmu_connect(struct maple_device *mdev)
> {
> unsigned long test_flash_data, basic_flash_data;
> int c, error;
> struct memcard *card;
> u32 partnum = 0;
>
> test_flash_data = be32_to_cpu(mdev->devinfo.function);
> /* Need to count how many bits are set - to find out which
> * function_data element has details of the memory card
> */
> c = hweight_long(test_flash_data);
>
> basic_flash_data = be32_to_cpu(mdev->devinfo.function_data[c - 1]);
[Severity: High]
This is a pre-existing issue, but does this array access risk an out-of-bounds
read?
Since test_flash_data is derived directly from the hardware packet, it could
have up to 32 bits set. If a malfunctioning device reports 0 bits or more than
3 bits set, does using c - 1 read past the bounds of the 3-element
function_data array?
[ ... ]
> /*
> * We want to trap meminfo not get cond
> * so set interval to zero, but rely on maple bus
> * driver to pass back the results of the meminfo
> */
> maple_getcond_callback(mdev, vmu_queryblocks, 0,
> MAPLE_FUNC_MEMCARD);
[ ... ]
> error = maple_add_packet(mdev, MAPLE_FUNC_MEMCARD,
> MAPLE_COMMAND_GETMINFO, 2, &partnum);
> if (error) {
> dev_err(&mdev->dev, "Could not lock VMU at (%d, %d)"
> " error is 0x%X\n", mdev->port, mdev->unit, error);
> goto fail_mtd_info;
> }
> return 0;
>
> fail_device_busy:
> kfree(card->mtd);
> fail_mtd_info:
> kfree(card->parts);
> fail_partitions:
> kfree(card);
> fail_nomem:
> return error;
> }
[Severity: Critical]
This is a pre-existing issue, but if maple_add_packet() fails, is the card
structure freed while the callback is still active?
In vmu_connect(), an asynchronous callback is registered via
maple_getcond_callback(). If a subsequent operation like maple_add_packet()
fails, the error path frees the card structure but does not clear
mdev->callback.
If a delayed or stray MAPLE_RESPONSE_DATATRF packet arrives later, could
maple_dma_handler() invoke the lingering mdev->callback, writing hardware
response data to the already freed card memory?
Regarding vmu_disconnect():
If vmu_queryblocks() fails, it branches to an error path that frees the
priv pointer and sets it to NULL:
> for (error = 0; error <= card->partition; error++) {
> kfree(((card->mtd)[error]).priv);
> ((card->mtd)[error]).priv = NULL;
> }
Because the initial probe returned success, the device remains bound. When
it is eventually disconnected, vmu_disconnect() executes:
> for (x = 0; x < card->partitions; x++) {
> mpart = ((card->mtd)[x]).priv;
> mpart->mdev = NULL;
[Severity: High]
This is a pre-existing issue, but if vmu_queryblocks() encountered an
asynchronous failure earlier, will vmu_disconnect() blindly dereference a
NULL pointer here?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=14
^ permalink raw reply
* Re: [PATCH 10/26] Input: maplecontrol - remove redundant drvdata resetting
From: sashiko-bot @ 2026-07-04 6:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260703-b4-maple-cleanup-v1-10-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] Missing `input_sync()` in the event reporting callback, causing events to not be flushed to userspace.
--
commit 049ef41ae581c4ec81e962190335026e0500fa08
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - remove redundant drvdata resetting
This patch removes redundant maple_set_drvdata(mdev, NULL) calls from the probe
error paths and device removal functions. The driver core automatically resets
driver data to NULL on probe failures and device removal, making these manual
resets unnecessary.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 6293b6e8148b3..79cec89ad52a9 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -62,20 +62,19 @@ static void dc_pad_callback(struct mapleq *mq)
>
> static int dc_pad_open(struct input_dev *dev)
> {
[Severity: Medium]
This is a pre-existing issue, but I noticed something while looking at the
code nearby.
In drivers/input/joystick/maplecontrol.c:dc_pad_callback():
input_report_abs(dev, ABS_RX, res[14]);
input_report_abs(dev, ABS_RY, res[15]);
}
Should this callback include a call to input_sync(dev) before returning?
Without input_sync(), won't the reported events (buttons and axes) be queued
in the input core but not immediately delivered to userspace?
This could lead to delayed or dropped inputs since they would only be delivered
if another event forces a sync.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=10
^ permalink raw reply
* Re: [PATCH 16/26] sh: maple: remove unused driver field from struct maple_device
From: sashiko-bot @ 2026-07-04 6:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-16-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] vmu_can_unload() crashes on hot-unplug if the driver fails to probe or is unbound.
--
commit 03c570da1dc6a7b4d15fe87da8cdddba6169830d
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
sh: maple: remove unused driver field from struct maple_device
The commit removes the unused driver field from struct maple_device since all
readers and writers of this field have been eliminated from the maple bus code.
> diff --git a/include/linux/maple.h b/include/linux/maple.h
> index 22f2930251edc..90c26c86e3ede 100644
> --- a/include/linux/maple.h
> +++ b/include/linux/maple.h
> @@ -64,7 +64,6 @@ struct maple_devinfo {
> };
>
> struct maple_device {
> - struct maple_driver *driver;
> struct mapleq *mq;
> void (*callback) (struct mapleq * mq);
> void (*fileerr_handler)(struct maple_device *mdev, void *recvbuf);
[Severity: High]
This is a pre-existing issue, but while reviewing changes to struct
maple_device, I noticed a potential null pointer dereference in the vmu-flash
driver.
In drivers/mtd/maps/vmu-flash.c:probe_maple_vmu(), the can_unload callback is
set:
probe_maple_vmu() {
...
mdev->can_unload = vmu_can_unload;
...
}
If probe fails during device connection or if the driver is unbound via sysfs,
the driver core clears the device's driver data to NULL. However,
mdev->can_unload remains pointing to vmu_can_unload.
If the device is subsequently hot-unplugged, the maple bus core calls
maple_response_none() -> mdev->can_unload(mdev), which dereferences the
driver data without checking if it is NULL:
vmu_can_unload() {
...
card = maple_get_drvdata(mdev);
for (x = 0; x < card->partitions; x++) {
...
}
Could this cause a system crash on hot-unplug? Should mdev->can_unload be
cleared on the probe error path and during unbind?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=16
^ permalink raw reply
* Re: [PATCH 06/26] Input: maplecontrol - simplify maple_device retrieval in open/close
From: sashiko-bot @ 2026-07-04 6:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-6-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The commit leaves behind an unused `mdev` field in `struct dc_pad` and a corresponding dead store in `probe_maple_controller`, leading to unnecessary code complexity and memory allocation.
Pre-existing issues:
- [High] The event reporting callback `dc_pad_callback` fails to call `input_sync()` after reporting a full frame of input events.
--
commit ef26388745a1577b8ffbd7d6511bdea113150cf1
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - simplify maple_device retrieval in open/close
This commit simplifies how the maple_device is retrieved in the open and close
callbacks. It stores the maple_device directly in the input device's drvdata,
removing the need to access it via the platform_data's dc_pad structure.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index c66b2614e2982..9d623c9e8f22c 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)
[Severity: High]
This is a pre-existing issue, but does dc_pad_callback() need a call to
input_sync() after reporting its frame of input events?
The input subsystem requires all logical groups of events to be synchronized.
Without input_sync(), userspace applications may not see the events until a
SYN_REPORT is forced by a buffer overflow or another event.
[ ... ]
> @@ -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);
[Severity: Low]
Does this commit leave the mdev field in struct dc_pad unused?
Now that the input device retrieves mdev from drvdata, the only remaining
used field in struct dc_pad appears to be dev.
Could struct dc_pad be completely eliminated by storing the idev pointer
directly as the Maple device's private data, avoiding the devm_kzalloc()
overhead entirely?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 03/26] Input: maplecontrol - only enable present axes
From: sashiko-bot @ 2026-07-04 6:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-3-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The event reporting callback fails to emit an EV_SYN/SYN_REPORT event, preventing userspace from receiving state updates.
--
commit d051181458cb7495a31496a5fdf31e5e286b6656
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - only enable present axes
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. This patch moves the input_set_abs_params() calls inside
the capability check loop and corrects the D-pad (hat) axis limits.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 6293b6e8148b3..a498fc322c4d5 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but the event reporting callback
fails to emit an EV_SYN/SYN_REPORT event.
Looking at dc_pad_callback() in drivers/input/joystick/maplecontrol.c:
...
input_report_abs(dev, ABS_GAS, res[10]);
input_report_abs(dev, ABS_BRAKE, res[11]);
input_report_abs(dev, ABS_X, res[12]);
input_report_abs(dev, ABS_Y, res[13]);
input_report_abs(dev, ABS_RX, res[14]);
input_report_abs(dev, ABS_RY, res[15]);
}
Without calling input_sync(dev) at the end of the callback, won't the evdev
input driver queue these events indefinitely without waking up userspace
readers? Does this prevent userspace from receiving state updates?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] Input: mms114 - fix multi-touch slot corruption
From: sashiko-bot @ 2026-07-04 6:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260704060115.353049-1-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] If `mms114_start()` fails during system resume, subsequent device close or suspend causes unbalanced `disable_irq()` and `regulator_disable()` calls, leaving the touchscreen permanently broken.
- [High] The suspend callback releases all touches before disabling the device interrupt, creating a race window where touches can get permanently stuck.
- [High] Stack-allocated buffers are passed directly to I2C transfer functions, which can cause DMA mapping failures or memory corruption.
--
commit 6a55987ddd51d1330fd1636cd3e72b4d910ea42b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: mms114 - fix multi-touch slot corruption
This commit fixes a multi-touch slot corruption bug in the mms114 driver.
When the touchscreen controller reports a touch ID of 0, the driver
calculates the slot ID as touch->id - 1, which underflows to UINT_MAX. The
driver fixes this by rejecting touch reports with ID 0.
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index 006dded17eb80..23e0283bc6b8b 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -248,7 +248,7 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
> unsigned int x;
> unsigned int y;
>
> - if (touch->id > MMS114_MAX_TOUCH) {
> + if (touch->id == 0 || touch->id > MMS114_MAX_TOUCH) {
> dev_err(&client->dev, "Wrong touch id (%d)\n", touch->id);
> return;
> }
[Severity: High]
This isn't a bug introduced by this patch, but I have a question about the
error handling in mms114_resume().
If mms114_start() fails (e.g. mms114_setup_regs() returns an error) it cleans
up the regulators but doesn't call enable_irq():
static int mms114_start(struct mms114_data *data)
{
...
error = mms114_setup_regs(data);
if (error < 0) {
regulator_disable(data->io_reg);
regulator_disable(data->core_reg);
return error;
}
enable_irq(client->irq);
return 0;
}
In mms114_resume(), the error is passed back up but the input device remains
logically open:
static int mms114_resume(struct device *dev)
{
...
if (input_device_enabled(input_dev)) {
error = mms114_start(data);
if (error)
return error;
}
...
}
Because the input device is still logically enabled, won't a subsequent
suspend or input_close call mms114_stop(), which unconditionally calls
disable_irq() and regulator_disable()? Does this cause an unbalanced IRQ
disable depth that permanently masks the interrupt?
[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition in
mms114_suspend().
The suspend callback releases all active touch slots before stopping the
device and disabling the interrupt:
static int mms114_suspend(struct device *dev)
{
...
/* Release all touch */
for (id = 0; id < MMS114_MAX_TOUCH; id++) {
input_mt_slot(input_dev, id);
input_mt_report_slot_inactive(input_dev);
}
input_mt_report_pointer_emulation(input_dev, true);
input_sync(input_dev);
guard(mutex)(&input_dev->mutex);
if (input_device_enabled(input_dev))
mms114_stop(data);
...
}
If a touch interrupt fires between the synthetic slot release and the call to
mms114_stop() (which disables the IRQ), could the physical touches be reported
as active again just as the device is suspended, leaving the touches
permanently stuck on resume?
[Severity: High]
This isn't a bug introduced by this patch, but there seem to be multiple
places where stack-allocated buffers are used for I2C transfers.
For example, in __mms114_read_reg(), a single byte stack variable is passed:
static int __mms114_read_reg(struct mms114_data *data, u8 reg,
unsigned int len, void *val)
{
...
u8 buf = reg;
...
xfer[0].buf = &buf;
...
error = i2c_transfer(client->adapter, xfer, 2);
...
}
Similarly in mms114_write_reg():
static int mms114_write_reg(struct mms114_data *data, u8 reg, u8 val)
{
...
u8 buf[2];
buf[0] = reg;
buf[1] = val;
error = i2c_master_send(client, buf, 2);
...
}
And in mms114_interrupt():
struct mms114_touch touch[MMS114_MAX_TOUCH];
...
error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size, touch);
...
Since many I2C controllers use DMA, doesn't passing stack memory to
i2c_transfer() risk DMA mapping failures or memory corruption when
CONFIG_VMAP_STACK is enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260704060115.353049-1-dmitry.torokhov@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 15/26] sh: maple: remove not needed maple_unsupported_device driver
From: sashiko-bot @ 2026-07-04 6:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-15-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] Asynchronous work items are not canceled on the `maple_bus_init` error path.
- [High] Error path in `maple_bus_init` frees devices that are still linked on the global `maple_waitq`.
- [High] Directly calling `kfree` via `maple_free_dev` on `device_register` failure in `maple_attach_driver` leaks kobject state.
- [High] Re-queuing a maple packet without setting the busy flag causes list corruption.
--
commit 8ed68bea570556010f84062b91e5bd48da1f0c8d
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
sh: maple: remove not needed maple_unsupported_device driver
This commit removes the maple_unsupported_device fallback driver since
the driver core handles devices without drivers. It also updates the
shared interrupt registrations to use &maple_bus instead of the removed
driver.
> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
> --- a/drivers/sh/maple/maple.c
> +++ b/drivers/sh/maple/maple.c
[ ... ]
> @@ -378,7 +376,6 @@ static void maple_attach_driver(struct maple_device *mdev)
> if (matched == 0) {
> /* Driver does not exist yet */
> dev_info(&mdev->dev, "no driver found\n");
> - mdev->driver = &maple_unsupported_device;
> }
> dev_set_name(&mdev->dev, "%d:0%d.%lX", mdev->port,
> mdev->unit, function);
[Severity: High]
This isn't a regression introduced by this patch, but does the error path in
maple_attach_driver() leak kobject state?
If device_register(&mdev->dev) fails:
error = device_register(&mdev->dev);
if (error) {
dev_warn(&mdev->dev, "could not register device at"
" (%d, %d), with error 0x%X\n", mdev->unit,
mdev->port, error);
maple_free_dev(mdev);
mdev = NULL;
return;
}
maple_free_dev() directly calls kfree(). Since device_register() was
called, shouldn't failures be handled by calling put_device() to safely
invoke the release callback instead of bypassing it?
[ ... ]
> @@ -863,17 +851,14 @@ static int __init maple_bus_init(void)
> kmem_cache_destroy(maple_queue_cache);
>
> cleanup_bothirqs:
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, &maple_bus);
>
> cleanup_irq:
> - free_irq(HW_EVENT_MAPLE_DMA, 0);
> + free_irq(HW_EVENT_MAPLE_DMA, &maple_bus);
>
> cleanup_dma:
> free_pages((unsigned long) maple_sendbuf, MAPLE_DMA_PAGES);
[Severity: High]
This is a pre-existing issue, but can this error path lead to a
use-after-free crash?
In maple_bus_init(), if initialization fails after setting the DMA
interrupt handler (for example, if KMEM_CACHE allocation fails), the error
path calls free_irq() and frees the maple_sendbuf memory.
However, it does not appear to call cancel_work_sync() for
maple_dma_process and maple_vblank_process. If an interrupt fired before
free_irq(), could the scheduled work items execute asynchronously after the
buffers are freed, dereferencing the freed memory?
[Severity: High]
This is another pre-existing issue in maple_bus_init(), but does the port
initialization loop leave dangling pointers on the global maple_waitq?
During the loop, each allocated device is immediately queued onto the
global maple_waitq via maple_add_packet():
for (i = 0; i < MAPLE_PORTS; i++) {
checked[i] = false;
empty[i] = false;
mdev[i] = maple_alloc_dev(i, 0);
if (!mdev[i]) {
while (i-- > 0)
maple_free_dev(mdev[i]);
If a subsequent allocation fails, the error handler loops backwards and
calls maple_free_dev(). However, maple_free_dev() frees mdev and mdev->mq
directly via kfree() without executing list_del() to remove them from
maple_waitq. Could this corrupt the linked list?
[Severity: High]
This is a pre-existing issue not touched by this patch, but can re-queuing
a maple packet without setting the busy flag cause list corruption?
Looking at setup_maple_commands() in drivers/sh/maple/maple.c, a
MAPLE_COMMAND_GETCOND packet is queued if mdev->busy is 0:
if (mdev->interval > 0 && atomic_read(&mdev->busy) == 0 &&
time_after(jiffies, mdev->when)) {
/* bounce if we cannot add */
add = maple_add_packet(mdev,
be32_to_cpu(mdev->devinfo.function),
MAPLE_COMMAND_GETCOND, 1, NULL);
if (!add)
mdev->when = jiffies + mdev->interval;
}
It successfully calls maple_add_packet(), which links mdev->mq->list into
maple_waitq. However, unlike other packet types, it fails to set
mdev->busy = 1.
If a concurrent userspace action (such as a read via /dev/mtdX in vmu-flash
leading to maple_vmu_read_block()) executes, would it read mdev->busy as 0,
assume the queue is free, and call maple_add_packet() again? This would
reuse the exact same mdev->mq object, executing list_add_tail() on an
already-linked node, which corrupts the list.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=15
^ permalink raw reply
* Re: [PATCH 2/3] Input: mms114 - fix endianness portability in I2C packet layout
From: sashiko-bot @ 2026-07-04 6:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260704060115.353049-2-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition in suspend causes stuck touches.
- [High] Unsafe DMA buffer allocation (stack-allocated memory passed to I2C transfers).
--
commit 2e96699ad380d6d47c8e998bc41268e9b77bac90
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: mms114 - fix endianness portability in I2C packet layout
The driver defines the I2C packet layout using C bitfields in struct
mms114_touch. This is not portable as the layout of bitfields within a
byte is compiler-dependent and varies with endianness. On Big Endian
systems, the fields will be parsed incorrectly.
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index 23e0283bc6b8b..84afdadb3bccc 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
[ ... ]
> @@ -325,8 +338,9 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
>
> for (index = 0; index < touch_size; index++) {
> t = (struct mms114_touch *)((u8 *)touch + index * event_size);
[Severity: High]
This isn't a bug introduced by this patch, but does passing stack-allocated
buffers to I2C transfer functions risk memory corruption if the I2C adapter
uses DMA?
Since kernel stacks are often allocated in vmalloc space (when
CONFIG_VMAP_STACK is enabled), they cannot be safely mapped for DMA.
In mms114_interrupt(), the touch array is stack-allocated and used as a
receive buffer:
struct mms114_touch touch[MMS114_MAX_TOUCH];
// ...
error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size, touch);
Similarly, __mms114_read_reg() and mms114_write_reg() pass local stack
variables (u8 buf and u8 buf[2]) to I2C transfers.
> + unsigned int type = FIELD_GET(MMS114_FLAGS_TYPE_MASK, t->flags);
>
> - switch (t->type) {
> + switch (type) {
> case MMS114_TYPE_TOUCHSCREEN:
> mms114_process_mt(data, t);
> break;
[ ... ]
[Severity: High]
This is a pre-existing issue, but could the sequence in mms114_suspend()
have a race condition that results in stuck touches?
In mms114_suspend(), the driver injects artificial release events before
disabling the IRQ:
/* Release all touch */
for (id = 0; id < MMS114_MAX_TOUCH; id++) {
input_mt_slot(input_dev, id);
input_mt_report_slot_inactive(input_dev);
}
// ...
input_sync(input_dev);
guard(mutex)(&input_dev->mutex);
if (input_device_enabled(input_dev))
mms114_stop(data);
If a touch interrupt fires and its threaded handler (mms114_interrupt)
executes after these release events are injected but before mms114_stop()
disables the IRQ, might it report the touch as active again and leave it
stuck indefinitely after suspend?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260704060115.353049-1-dmitry.torokhov@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 25/26] Input: maplecontrol - fix style issues
From: sashiko-bot @ 2026-07-04 6:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-b4-maple-cleanup-v1-25-41e424964da5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing `input_sync()` in the event reporting callback, preventing event delivery to standard userspace clients.
--
commit 85e64697864750aa3ae1b20ac7b36084615ece73
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - fix style issues
This commit fixes coding style and formatting issues reported by
checkpatch.pl. It switches to using BIT() macros and removes
conditionals when reporting D-PAD events.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -35,22 +35,22 @@ static void dc_pad_callback(struct mapleq *mq)
[ ... ]
> - input_report_key(dev, BTN_SELECT, buttons & 0x0800);
> + input_report_key(dev, BTN_C, buttons & BIT(0));
> + input_report_key(dev, BTN_B, buttons & BIT(1));
> + input_report_key(dev, BTN_A, buttons & BIT(2));
> + input_report_key(dev, BTN_START, buttons & BIT(3));
> + input_report_key(dev, BTN_Z, buttons & BIT(8));
> + input_report_key(dev, BTN_Y, buttons & BIT(9));
> + input_report_key(dev, BTN_X, buttons & BIT(10));
> + input_report_key(dev, BTN_SELECT, buttons & BIT(11));
>
> input_report_abs(dev, ABS_GAS, res[10]);
> input_report_abs(dev, ABS_BRAKE, res[11]);
[Severity: High]
This is a pre-existing issue, but does dc_pad_callback() need a call to
input_sync() at the end of the event reporting block?
When the maple bus periodically invokes this callback to parse the hardware
state, all axis and key updates are pushed to the input core, but the
function returns without finalizing the packet. Modern input stacks like evdev
buffer events and wait for an EV_SYN sync event to wake up userspace.
Without a sync event after these inputs are reported, do the events remain
buffered indefinitely and fail to reach applications?
Could an input_sync(dev) call be added before the callback returns to ensure
the state updates are successfully flushed to userspace?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=25
^ 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