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

[sashiko-bot@kernel.org]

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