Re: [PATCH] Input: mms114 - fix touch slot corruption in suspend

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

Pre-existing issues:
- [High] Active touchkeys are not released during suspend, potentially caus=
ing them to be stuck upon resume.
--

--- Patch [1]: [PATCH] Input: mms114 - fix touch slot corruption in suspend=
 ---
commit 1d29053929170cae6a2ebfa311bed7d55133b74a
Author: Dmitry Torokhov <[email protected]>

Input: mms114 - fix touch slot corruption in suspend

This commit fixes a race condition during suspend by disabling the IRQ and
synchronizing with the interrupt handler before synthesizing touch release
events. It also ensures touch release events are only synthesized if the
input device is enabled, protecting the sequence with the input device mute=
x.

> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscre=
en/mms114.c
> index 27911a9f4e9eb..734c37579f5a4 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -679,6 +679,13 @@ static int mms114_suspend(struct device *dev)
[ ... ]
> +	mms114_stop(data);
> +
>  	/* Release all touch */
>  	for (id =3D 0; id < MMS114_MAX_TOUCH; id++) {
>  		input_mt_slot(input_dev, id);
>  		input_mt_report_slot_inactive(input_dev);
>  	}
> =20
>  	input_mt_report_pointer_emulation(input_dev, true);
>  	input_sync(input_dev);

[Severity: High]
This is a pre-existing issue, but does this sequence also need to synthesize
release events for active touchkeys?

If a touchkey (such as Back or Menu) is pressed when the device suspends,
mms114_stop() powers down the hardware without sending a hardware release
interrupt. Since this loop only releases multitouch slots, it seems the
touchkey could remain logically stuck in the active state in the input core
upon resume.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/anKxGkyRRu5A92Q_@go=
ogle.com?part=3D1