[PATCH 00/26] sh: maple: cleanup and modernize input drivers

[PATCH 00/26] sh: maple: cleanup and modernize input drivers

[Dmitry Torokhov]

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

[PATCH 01/26] sh: maple: include linux/device.h in linux/maple.h

[Dmitry Torokhov]

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

Re: [PATCH 01/26] sh: maple: include linux/device.h in linux/maple.h

[sashiko-bot]

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

[PATCH 02/26] Input: maple_keyb - fix key press detection

[Dmitry Torokhov]

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

[PATCH 03/26] Input: maplecontrol - only enable present axes

[Dmitry Torokhov]

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

Re: [PATCH 03/26] Input: maplecontrol - only enable present axes

[sashiko-bot]

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

[PATCH 04/26] Input: maplemouse - stop polling and clear callback on close

[Dmitry Torokhov]

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

[PATCH 05/26] Input: maplecontrol - stop polling and clear callback on close

[Dmitry Torokhov]

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

Re: [PATCH 05/26] Input: maplecontrol - stop polling and clear callback on close

[sashiko-bot]

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

[PATCH 06/26] Input: maplecontrol - simplify maple_device retrieval in open/close

[Dmitry Torokhov]

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

Re: [PATCH 06/26] Input: maplecontrol - simplify maple_device retrieval in open/close

[sashiko-bot]

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

[PATCH 07/26] Input: maple_keyb - implement open and close methods

[Dmitry Torokhov]

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

[PATCH 08/26] Input: maplemouse - remove redundant drvdata resetting

[Dmitry Torokhov]

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

[PATCH 09/26] Input: maple_keyb - remove redundant drvdata resetting

[Dmitry Torokhov]

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

[PATCH 10/26] Input: maplecontrol - remove redundant drvdata resetting

[Dmitry Torokhov]

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/joystick/maplecontrol.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 9d623c9e8f22..79cec89ad52a 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -146,7 +146,6 @@ static int probe_maple_controller(struct device *dev)
 fail:
 	input_free_device(idev);
 	kfree(pad);
-	maple_set_drvdata(mdev, NULL);
 	return error;
 }
 
@@ -156,7 +155,6 @@ static int remove_maple_controller(struct device *dev)
 	struct dc_pad *pad = maple_get_drvdata(mdev);
 
 	input_unregister_device(pad->dev);
-	maple_set_drvdata(mdev, NULL);
 	kfree(pad);
 
 	return 0;

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 10/26] Input: maplecontrol - remove redundant drvdata resetting

[sashiko-bot]

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

[PATCH 11/26] Input: maplemouse - remove unused mdev->driver assignment

[Dmitry Torokhov]

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_mouse.

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, 4 deletions(-)

diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index 37f60bbd0ba4..f67e3eb5841b 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -67,7 +67,6 @@ static void dc_mouse_close(struct input_dev *dev)
 static int probe_maple_mouse(struct device *dev)
 {
 	struct maple_device *mdev = to_maple_dev(dev);
-	struct maple_driver *mdrv = to_maple_driver(dev->driver);
 	int error;
 	struct input_dev *input_dev;
 	struct dc_mouse *mse;
@@ -102,9 +101,6 @@ static int probe_maple_mouse(struct device *dev)
 	error =	input_register_device(input_dev);
 	if (error)
 		goto fail_register;
-
-	mdev->driver = mdrv;
-
 	return error;
 
 fail_register:

-- 
2.55.0.rc0.799.gd6f94ed593-goog

[PATCH 12/26] Input: maplecontrol - remove unused mdev->driver assignment

[Dmitry Torokhov]

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.

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, 4 deletions(-)

diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 79cec89ad52a..955e01bcfa0c 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:

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 12/26] Input: maplecontrol - remove unused mdev->driver assignment

[sashiko-bot]

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

[PATCH 13/26] Input: maple_keyb - remove unused mdev->driver assignment

[Dmitry Torokhov]

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_kbd.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/keyboard/maple_keyb.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index 0c92138bcc77..e277b929a375 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -161,13 +161,11 @@ static void dc_kbd_close(struct input_dev *dev)
 static int probe_maple_kbd(struct device *dev)
 {
 	struct maple_device *mdev;
-	struct maple_driver *mdrv;
 	int i, error;
 	struct dc_kbd *kbd;
 	struct input_dev *idev;
 
 	mdev = to_maple_dev(dev);
-	mdrv = to_maple_driver(dev->driver);
 
 	kbd = kzalloc_obj(*kbd);
 	if (!kbd) {
@@ -206,9 +204,6 @@ static int probe_maple_kbd(struct device *dev)
 	error = input_register_device(idev);
 	if (error)
 		goto fail_register;
-
-	mdev->driver = mdrv;
-
 	return error;
 
 fail_register:

-- 
2.55.0.rc0.799.gd6f94ed593-goog

[PATCH 14/26] mtd: maps: vmu-flash: remove unused mdev->driver assignment

[Dmitry Torokhov]

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_vmu.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/mtd/maps/vmu-flash.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mtd/maps/vmu-flash.c b/drivers/mtd/maps/vmu-flash.c
index 10244e6731d0..8f7028ac1b56 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);
 }

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 14/26] mtd: maps: vmu-flash: remove unused mdev->driver assignment

[sashiko-bot]

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

[PATCH 15/26] sh: maple: remove not needed maple_unsupported_device driver

[Dmitry Torokhov]

The maple_unsupported_device driver was used as a fallback driver
when no matching driver was found for a device, or for ports with no
devices. However, this is not needed as the driver core handles
devices without drivers.

Remove the no longer needed maple_unsupported_device driver and its
registration and update the shared interrupts (HW_EVENT_MAPLE_DMA and
HW_EVENT_VSYNC) to use &maple_bus as their dev_id instead of
&maple_unsupported_device.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/sh/maple/maple.c | 25 +++++--------------------
 1 file changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 5585f220e495..35aff2e57d2c 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -43,7 +43,6 @@ static LIST_HEAD(maple_sentq);
 /* mutex to protect queue of waiting packets */
 static DEFINE_MUTEX(maple_wlist_lock);
 
-static struct maple_driver maple_unsupported_device;
 static struct device maple_bus;
 static int subdevice_map[MAPLE_PORTS];
 static unsigned long *maple_sendbuf, *maple_sendptr, *maple_lastptr;
@@ -368,7 +367,6 @@ static void maple_attach_driver(struct maple_device *mdev)
 	if (function > 0x200) {
 		/* Do this silently - as not a real device */
 		function = 0;
-		mdev->driver = &maple_unsupported_device;
 		dev_set_name(&mdev->dev, "%d:0.port", mdev->port);
 	} else {
 		matched =
@@ -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);
@@ -727,13 +724,13 @@ static irqreturn_t maple_vblank_interrupt(int irq, void *dev_id)
 static int maple_set_dma_interrupt_handler(void)
 {
 	return request_irq(HW_EVENT_MAPLE_DMA, maple_dma_interrupt,
-		IRQF_SHARED, "maple bus DMA", &maple_unsupported_device);
+		IRQF_SHARED, "maple bus DMA", &maple_bus);
 }
 
 static int maple_set_vblank_interrupt_handler(void)
 {
 	return request_irq(HW_EVENT_VSYNC, maple_vblank_interrupt,
-		IRQF_SHARED, "maple bus VBLANK", &maple_unsupported_device);
+		IRQF_SHARED, "maple bus VBLANK", &maple_bus);
 }
 
 static int maple_get_dma_buffer(void)
@@ -765,12 +762,6 @@ static void maple_bus_release(struct device *dev)
 {
 }
 
-static struct maple_driver maple_unsupported_device = {
-	.drv = {
-		.name = "maple_unsupported_device",
-		.bus = &maple_bus_type,
-	},
-};
 /*
  * maple_bus_type - core maple bus structure
  */
@@ -799,15 +790,12 @@ static int __init maple_bus_init(void)
 	if (retval)
 		goto cleanup_device;
 
-	retval = driver_register(&maple_unsupported_device.drv);
-	if (retval)
-		goto cleanup_bus;
 
 	/* allocate memory for maple bus dma */
 	retval = maple_get_dma_buffer();
 	if (retval) {
 		dev_err(&maple_bus, "failed to allocate DMA buffers\n");
-		goto cleanup_basic;
+		goto cleanup_bus;
 	}
 
 	/* set up DMA interrupt handler */
@@ -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);
 
-cleanup_basic:
-	driver_unregister(&maple_unsupported_device.drv);
-
 cleanup_bus:
 	bus_unregister(&maple_bus_type);
 

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 15/26] sh: maple: remove not needed maple_unsupported_device driver

[sashiko-bot]

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

[PATCH 16/26] sh: maple: remove unused driver field from struct maple_device

[Dmitry Torokhov]

The driver field in struct maple_device was not really used since
commit 1795cf48b322 ("sh/maple: clean maple bus code") which removed
the reading of this field.

Now that all the writers are gone as well, remove the field from struct
maple_device.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 include/linux/maple.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/maple.h b/include/linux/maple.h
index 22f2930251ed..90c26c86e3ed 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);

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 16/26] sh: maple: remove unused driver field from struct maple_device

[sashiko-bot]

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

[PATCH 17/26] sh: maple: implement bus-level probe/remove

[Dmitry Torokhov]

Implement probe() and remove() methods for the maple bus, and update
struct maple_driver to have its own probe() and remove() members that
take struct maple_device * directly.

Adjust all maple drivers (keyboard, mouse, joystick, vmu-flash) to
use these new bus-level methods, simplifying their probe and remove
functions by removing the need to cast from struct device * using
to_maple_dev().

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/joystick/maplecontrol.c | 12 ++++--------
 drivers/input/keyboard/maple_keyb.c   | 14 +++++---------
 drivers/input/mouse/maplemouse.c      | 12 ++++--------
 drivers/mtd/maps/vmu-flash.c          | 13 ++++---------
 drivers/sh/maple/maple.c              | 27 ++++++++++++++++++++++++++-
 include/linux/maple.h                 |  2 ++
 6 files changed, 45 insertions(+), 35 deletions(-)

diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 955e01bcfa0c..6864243b0b4a 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -78,7 +78,7 @@ static void dc_pad_close(struct input_dev *dev)
 }
 
 /* allow the controller to be used */
-static int probe_maple_controller(struct device *dev)
+static int probe_maple_controller(struct maple_device *mdev)
 {
 	static const short btn_bit[32] = {
 		BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
@@ -94,7 +94,6 @@ static int probe_maple_controller(struct device *dev)
 		-1, -1, -1, -1, -1, -1, -1, -1,
 	};
 
-	struct maple_device *mdev = to_maple_dev(dev);
 	int i, error;
 	struct dc_pad *pad;
 	struct input_dev *idev;
@@ -145,23 +144,20 @@ static int probe_maple_controller(struct device *dev)
 	return error;
 }
 
-static int remove_maple_controller(struct device *dev)
+static void remove_maple_controller(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
 	struct dc_pad *pad = maple_get_drvdata(mdev);
 
 	input_unregister_device(pad->dev);
 	kfree(pad);
-
-	return 0;
 }
 
 static struct maple_driver dc_pad_driver = {
 	.function =	MAPLE_FUNC_CONTROLLER,
+	.probe =	probe_maple_controller,
+	.remove =	remove_maple_controller,
 	.drv = {
 		.name	= "Dreamcast_controller",
-		.probe	= probe_maple_controller,
-		.remove	= remove_maple_controller,
 	},
 };
 
diff --git a/drivers/input/keyboard/maple_keyb.c b/drivers/input/keyboard/maple_keyb.c
index e277b929a375..ab9257db7e03 100644
--- a/drivers/input/keyboard/maple_keyb.c
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -158,15 +158,12 @@ static void dc_kbd_close(struct input_dev *dev)
 	maple_getcond_callback(mdev, NULL, 0, MAPLE_FUNC_KEYBOARD);
 }
 
-static int probe_maple_kbd(struct device *dev)
+static int probe_maple_kbd(struct maple_device *mdev)
 {
-	struct maple_device *mdev;
 	int i, error;
 	struct dc_kbd *kbd;
 	struct input_dev *idev;
 
-	mdev = to_maple_dev(dev);
-
 	kbd = kzalloc_obj(*kbd);
 	if (!kbd) {
 		error = -ENOMEM;
@@ -214,9 +211,8 @@ static int probe_maple_kbd(struct device *dev)
 	return error;
 }
 
-static int remove_maple_kbd(struct device *dev)
+static void remove_maple_kbd(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
 	struct dc_kbd *kbd = maple_get_drvdata(mdev);
 
 	guard(mutex)(&maple_keyb_mutex);
@@ -224,15 +220,15 @@ static int remove_maple_kbd(struct device *dev)
 	input_unregister_device(kbd->dev);
 	kfree(kbd);
 
-	return 0;
+
 }
 
 static struct maple_driver dc_kbd_driver = {
 	.function = MAPLE_FUNC_KEYBOARD,
+	.probe =	probe_maple_kbd,
+	.remove =	remove_maple_kbd,
 	.drv = {
 		.name = "Dreamcast_keyboard",
-		.probe = probe_maple_kbd,
-		.remove = remove_maple_kbd,
 	},
 };
 
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index f67e3eb5841b..03cb666d278d 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -64,9 +64,8 @@ static void dc_mouse_close(struct input_dev *dev)
 }
 
 /* allow the mouse to be used */
-static int probe_maple_mouse(struct device *dev)
+static int probe_maple_mouse(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
 	int error;
 	struct input_dev *input_dev;
 	struct dc_mouse *mse;
@@ -111,23 +110,20 @@ static int probe_maple_mouse(struct device *dev)
 	return error;
 }
 
-static int remove_maple_mouse(struct device *dev)
+static void remove_maple_mouse(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
 	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",
-		.probe = probe_maple_mouse,
-		.remove = remove_maple_mouse,
 	},
 };
 
diff --git a/drivers/mtd/maps/vmu-flash.c b/drivers/mtd/maps/vmu-flash.c
index 8f7028ac1b56..c34c768dfb87 100644
--- a/drivers/mtd/maps/vmu-flash.c
+++ b/drivers/mtd/maps/vmu-flash.c
@@ -769,30 +769,25 @@ static void vmu_file_error(struct maple_device *mdev, void *recvbuf)
 }
 
 
-static int probe_maple_vmu(struct device *dev)
+static int probe_maple_vmu(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
-
 	mdev->can_unload = vmu_can_unload;
 	mdev->fileerr_handler = vmu_file_error;
 
 	return vmu_connect(mdev);
 }
 
-static int remove_maple_vmu(struct device *dev)
+static void remove_maple_vmu(struct maple_device *mdev)
 {
-	struct maple_device *mdev = to_maple_dev(dev);
-
 	vmu_disconnect(mdev);
-	return 0;
 }
 
 static struct maple_driver vmu_flash_driver = {
 	.function =	MAPLE_FUNC_MEMCARD,
+	.probe =	probe_maple_vmu,
+	.remove =	remove_maple_vmu,
 	.drv = {
 		.name =		"Dreamcast_visual_memory",
-		.probe =	probe_maple_vmu,
-		.remove =	remove_maple_vmu,
 	},
 };
 
diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 35aff2e57d2c..c0715e3ace6f 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -721,6 +721,11 @@ static irqreturn_t maple_vblank_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+/*
+ * We pass &maple_bus as dev_id for the shared interrupts because
+ * the kernel requires a unique non-NULL token for shared IRQs,
+ * even though the handlers themselves ignore it.
+ */
 static int maple_set_dma_interrupt_handler(void)
 {
 	return request_irq(HW_EVENT_MAPLE_DMA, maple_dma_interrupt,
@@ -765,9 +770,30 @@ static void maple_bus_release(struct device *dev)
 /*
  * maple_bus_type - core maple bus structure
  */
+static int maple_bus_probe(struct device *dev)
+{
+	struct maple_driver *maple_drv = to_maple_driver(dev->driver);
+	struct maple_device *maple_dev = to_maple_dev(dev);
+
+	if (maple_drv->probe)
+		return maple_drv->probe(maple_dev);
+	return -ENODEV;
+}
+
+static void maple_bus_remove(struct device *dev)
+{
+	struct maple_driver *maple_drv = to_maple_driver(dev->driver);
+	struct maple_device *maple_dev = to_maple_dev(dev);
+
+	if (maple_drv->remove)
+		maple_drv->remove(maple_dev);
+}
+
 static const struct bus_type maple_bus_type = {
 	.name = "maple",
 	.match = maple_match_bus_driver,
+	.probe = maple_bus_probe,
+	.remove = maple_bus_remove,
 };
 
 static struct device maple_bus = {
@@ -790,7 +816,6 @@ static int __init maple_bus_init(void)
 	if (retval)
 		goto cleanup_device;
 
-
 	/* allocate memory for maple bus dma */
 	retval = maple_get_dma_buffer();
 	if (retval) {
diff --git a/include/linux/maple.h b/include/linux/maple.h
index 90c26c86e3ed..641cf3330409 100644
--- a/include/linux/maple.h
+++ b/include/linux/maple.h
@@ -80,6 +80,8 @@ struct maple_device {
 
 struct maple_driver {
 	unsigned long function;
+	int (*probe)(struct maple_device *dev);
+	void (*remove)(struct maple_device *dev);
 	struct device_driver drv;
 };
 

-- 
2.55.0.rc0.799.gd6f94ed593-goog

Re: [PATCH 17/26] sh: maple: implement bus-level probe/remove

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

Pre-existing issues:
- [High] Dangling function pointers in maple_device leading to execution of unloaded module code on hot-unplug.
- [High] Missing `cancel_work_sync()` in `maple_bus_init` error path leads to Use-After-Free.
- [High] Dangling hardware callback in `vmu_connect` error path leads to Use-After-Free.
- [High] NULL pointer dereference and multiple memory leaks in `vmu_disconnect`.
- [High] The driver reports input events but fails to call `input_sync()` at the end of the packet handling.
- [Medium] Memory leak of `card->mtd` array on failure path in `vmu_connect`.
--

commit 8d15bc5545d93a9d1f9f85e0e543bc57384c73cb
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

sh: maple: implement bus-level probe/remove
    
Implement probe() and remove() methods for the maple bus, and update
struct maple_driver to have its own probe() and remove() members that
take struct maple_device * directly. Adjust all maple drivers to
use these new bus-level methods.

> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 955e01bcfa0c1..6864243b0b4a2 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -78,7 +78,7 @@ static void dc_pad_close(struct input_dev *dev)
>  }
>  
>  /* allow the controller to be used */
> -static int probe_maple_controller(struct device *dev)
> +static int probe_maple_controller(struct maple_device *mdev)
>  {

[Severity: High]
This is a pre-existing issue, but does dc_pad_callback() fail to call
input_sync() after reporting events?

drivers/input/joystick/maplecontrol.c:dc_pad_callback() {
    ...
    input_report_abs(dev, ABS_RY,     res[15]);
}

The driver reports input events but never calls input_sync() at the end of the
packet handling. As dictated by the Input Subsystem guidelines, every logical
group of events must be followed by a call to input_sync(), otherwise events
may not be properly synchronized and delivered to userspace.

[ ... ]
> diff --git a/drivers/mtd/maps/vmu-flash.c b/drivers/mtd/maps/vmu-flash.c
> index 8f7028ac1b56a..c34c768dfb876 100644
> --- a/drivers/mtd/maps/vmu-flash.c
> +++ b/drivers/mtd/maps/vmu-flash.c
> @@ -769,30 +769,25 @@ static void vmu_file_error(struct maple_device *mdev, void *recvbuf)
>  }
>  
>  
> -static int probe_maple_vmu(struct device *dev)
> +static int probe_maple_vmu(struct maple_device *mdev)
>  {
> -	struct maple_device *mdev = to_maple_dev(dev);
> -
>  	mdev->can_unload = vmu_can_unload;
>  	mdev->fileerr_handler = vmu_file_error;
>  

[Severity: High]
This is a pre-existing issue, but does this leave dangling function pointers
during device hot-unplug?

mdev->can_unload and mdev->fileerr_handler are set here, but remove_maple_vmu()
never clears them. If the module is unbound and unloaded, and the device is
subsequently physically unplugged, maple_response_none() will call the dangling
mdev->can_unload(mdev). This would jump to unmapped memory and cause a kernel
panic.

>  	return vmu_connect(mdev);
>  }

[Severity: Medium]
This is a pre-existing issue, but does vmu_connect() leak the card->mtd array
on the packet addition failure path?

When maple_add_packet() fails, the code jumps to fail_mtd_info:

drivers/mtd/maps/vmu-flash.c:vmu_connect() {
    ...
fail_device_busy:
    kfree(card->mtd);
fail_mtd_info:
    kfree(card->parts);
    ...
}

This bypasses the kfree(card->mtd) cleanup block, causing a memory leak.

[Severity: High]
This is a pre-existing issue, but does vmu_connect() leave a dangling callback
if it fails?

drivers/mtd/maps/vmu-flash.c:vmu_connect() {
    ...
    maple_getcond_callback(mdev, vmu_queryblocks, 0, MAPLE_FUNC_MEMCARD);
    ...
}

If vmu_connect() returns an error (like device busy or maple_add_packet failure),
it frees the 'card' structure but doesn't clear mdev->callback. If the maple
bus receives a MAPLE_RESPONSE_DATATRF, will the core unconditionally execute the
callback and attempt to use the freed 'card' structure?

> -static int remove_maple_vmu(struct device *dev)
> +static void remove_maple_vmu(struct maple_device *mdev)
>  {
> -	struct maple_device *mdev = to_maple_dev(dev);
> -
>  	vmu_disconnect(mdev);
> -	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but can vmu_disconnect() trigger a NULL pointer
dereference?

drivers/mtd/maps/vmu-flash.c:vmu_disconnect() {
    ...
    for (x = 0; x < card->partitions; x++) {
        mpart = ((card->mtd)[x]).priv;
        mpart->mdev = NULL;
    ...
}

Since vmu_connect() creates card->mtd as a zeroed array, card->mtd[x].priv is
NULL until vmu_queryblocks() asynchronously allocates and assigns it. If the
device is disconnected before the callback completes for all partitions, will
this blindly dereference mpart? Additionally, does this fail to free mpart,
pcache, and pcache->buffer completely, causing memory leaks on every successful
bind/unbind?

[ ... ]
> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
> index 35aff2e57d2c8..c0715e3ace6f1 100644
> --- a/drivers/sh/maple/maple.c
> +++ b/drivers/sh/maple/maple.c
> @@ -790,7 +816,6 @@ static int __init maple_bus_init(void)
>  	if (retval)
>  		goto cleanup_device;
>  
> -
>  	/* allocate memory for maple bus dma */
>  	retval = maple_get_dma_buffer();

[Severity: High]
This is a pre-existing issue, but does the error path in maple_bus_init()
fail to cancel asynchronous work, leading to a use-after-free?

drivers/sh/maple/maple.c:maple_bus_init() {
    ...
cleanup_irq:
    free_irq(HW_EVENT_MAPLE_DMA, &maple_bus);

cleanup_dma:
    free_pages((unsigned long) maple_sendbuf, MAPLE_DMA_PAGES);
    ...
}

If initialization fails after the DMA or VBLANK IRQs are registered, the error
path frees the IRQs and the maple_sendbuf memory. However, it fails to cancel
the asynchronous work (maple_dma_process and maple_vblank_process). If an IRQ
fires before free_irq(), the scheduled work will execute maple_dma_handler() or
maple_vblank_handler(), which dereferences the freed maple_sendbuf memory via
maple_send().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=17

[PATCH 18/26] sh: maple: introduce callback_mutex in maple_device

[Dmitry Torokhov]

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

Re: [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Critical] The newly introduced callback_mutex causes a guaranteed self-deadlock when enumerating vmu-flash devices.
- [Medium] The newly introduced callback_mutex is initialized dynamically but is not destroyed during the standard device release lifecycle.

Pre-existing issues:
- [High] The patch fails to prevent the Use-After-Free race condition in the vmu-flash driver because vmu_disconnect bypasses the new callback_mutex.
--

commit 29c05632bf3bdcdb9087fb8230fb421ba8176ce5
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

sh: maple: introduce callback_mutex in maple_device

This commit introduces callback_mutex in struct maple_device to synchronize
callback registration and invocation. It is intended to prevent 
use-after-free bugs if a device is removed while a callback is in flight.

> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
> index c0715e3ace6f1..7c82b7a8a2809 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);

[Severity: Critical]
Does this introduce a self-deadlock when a callback registers a new callback?

When enumerating a vmu-flash device, maple_dma_handler() acquires 
mdev->callback_mutex and executes the callback vmu_queryblocks(). 
Inside vmu_queryblocks(), the driver calls maple_getcond_callback() to
configure the next phase. 

Since maple_getcond_callback() unconditionally attempts to acquire the
same non-recursive mdev->callback_mutex here, won't this immediately
deadlock the maple bus workqueue?

>  	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);

[Severity: Medium]
Is a corresponding mutex_destroy() needed in the standard device release 
path?

While mutex_destroy() is added to maple_free_dev() here, if a maple device's 
reference count drops to zero after device_unregister(), the release 
path maple_release_device() is executed. 

Will this leave stale lockdep/RT-mutex structures behind if debugging 
configs are enabled, since maple_release_device() does not destroy the 
mutex before calling kfree(mdev)?

>  	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);
> +				}

[Severity: High]
This is a pre-existing issue, but does this actually prevent the 
use-after-free race condition for all drivers?

If a user unbinds a vmu-flash device while a maple data transfer is 
in-flight, vmu_disconnect() bypasses this new mutex entirely:

drivers/mtd/maps/vmu-flash.c:vmu_disconnect() {
    ...
    mdev->callback = NULL;
    card = maple_get_drvdata(mdev);
    ...
    kfree(card);
}

Since vmu_disconnect() modifies the callback and frees the private data 
without acquiring callback_mutex, can maple_dma_handler() still 
concurrently dereference the freed card data here?

>  				atomic_set(&mdev->busy, 0);
>  				wake_up(&mdev->maple_wait);
>  				break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=18

Re: [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device

[Florian Fuchs]

Hi Dmitry,

On 03 Jul 22:57, Dmitry Torokhov wrote:
> 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
> 

Thank you so much for your efforts. I can confirm sashikos finding in my
test (that I saw later), that this patch hangs the bus if a VMU memcard
is inserted. So that the peripherals don't work anymore after insertion
of the memcard. With a last log like:
Dreamcast_visual_memory 3:01.E: VMU at (3, 1) is busy

Regards
Florian

Re: [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device

[Dmitry Torokhov]

Hi Florian,

On Sat, Jul 04, 2026 at 05:48:16PM +0200, Florian Fuchs wrote:
> Hi Dmitry,
> 
> On 03 Jul 22:57, Dmitry Torokhov wrote:
> > 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.

...

> 
> Thank you so much for your efforts. I can confirm sashikos finding in my
> test (that I saw later),

Thank you for giving the series a spin!

> that this patch hangs the bus if a VMU memcard
> is inserted. So that the peripherals don't work anymore after insertion
> of the memcard. With a last log like:
> Dreamcast_visual_memory 3:01.E: VMU at (3, 1) is busy

Yes, indeed, I overlooked the vmu-flash use case. I will introduce a
lockless way of setting up the callback and a wrapper that takes the
lock and that should solve the deadlock in vmu-flash driver.

I wonder if you had a chance top try out the preceding patches and if
they worked for you? If they do and you can add your tested-by I should
be able to pick up at least the input patches that do not need maple
core changes...

Thanks.

-- 
Dmitry

[PATCH 19/26] Input: maple_keyb - remove redundant mutex and remove method

[Dmitry Torokhov]

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

[PATCH 20/26] Input: maple_keyb - convert to devm

[Dmitry Torokhov]

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

[PATCH 21/26] Input: maplemouse - convert to devm

[Dmitry Torokhov]

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

[PATCH 22/26] Input: maplecontrol - convert to devm

[Dmitry Torokhov]

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

Re: [PATCH 22/26] Input: maplecontrol - convert to devm

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the event reporting callback `dc_pad_callback` fails to call `input_sync()` after reporting key and absolute axis events, preventing state updates from reaching userspace promptly.
--

commit bb1e0ba07531193e46d25e174ec864860b0026be
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: maplecontrol - convert to devm
    
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.

> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 6864243b0b4a2..3ef6652d40cb6 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c

[ ... ]

> @@ -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;
> -}

[Severity: High]
This isn't a bug introduced by this patch, but I noticed the event reporting
callback dc_pad_callback() fails to call input_sync() after reporting key and
absolute axis events:

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 a final input_sync(dev), will state updates be prevented from
reaching userspace promptly, causing events to get stuck until the internal
buffers fill up?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-b4-maple-cleanup-v1-0-41e424964da5@gmail.com?part=22

[PATCH 23/26] Input: maple_keyb - fix style issues

[Dmitry Torokhov]

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

[PATCH 24/26] Input: maplemouse - fix style issues

[Dmitry Torokhov]

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

[PATCH 25/26] Input: maplecontrol - fix style issues

[Dmitry Torokhov]

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

Re: [PATCH 25/26] Input: maplecontrol - fix style issues

[sashiko-bot]

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

[PATCH 26/26] Input: maple_keyb - remove redundant 'new' buffer from struct dc_kbd

[Dmitry Torokhov]

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