Re: [PATCH 06/26] Input: maplecontrol - simplify maple_device retrieval in open/close
From: sashiko-bot@kernel.org
Date: 2026-07-04 06:10:29
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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. [ ... ]
quoted hunk ↗ jump to hunk
@@ -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