From: sashiko-bot@kernel.org
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 5/6] Input: mms114 - replace BUG() and fix alignment
Date: Tue, 16 Jun 2026 05:27:26 +0000 [thread overview]
Message-ID: <20260616052726.640521F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260616050912.1531241-5-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition in `mms114_suspend` leading to stuck touch state.
--
commit a5a14734d553a190d315dfdcd845e9a868df4005
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: mms114 - replace BUG() and fix alignment
This commit avoids crashing the kernel by replacing a BUG() call with WARN_ON()
when userspace reads a write-only register. It also corrects parameter
alignment in several function calls to match kernel coding style.
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index c59aec8f2febe..bf01eee0560a1 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential race
condition in mms114_suspend() that could leave the touchscreen stuck in a
pressed state:
drivers/input/touchscreen/mms114.c:mms114_suspend() {
...
for (id = 0; id < MMS114_MAX_TOUCH; id++) {
input_mt_slot(input_dev, id);
input_mt_report_slot_inactive(input_dev);
}
input_mt_report_pointer_emulation(input_dev, true);
input_sync(input_dev);
guard(mutex)(&input_dev->mutex);
if (input_device_enabled(input_dev))
mms114_stop(data);
...
}
Can mms114_interrupt() execute concurrently after input_sync() but before
mms114_stop() disables the IRQ?
If a user touches the screen during this window, wouldn't the interrupt
handler report a new active touch state right after these synthetic release
events?
Because mms114_stop() then disables the IRQ, would this freeze the touch in a
pressed state throughout suspend?
When resuming, releasing the screen wouldn't generate a release interrupt,
which might leave the touchscreen stuck until reboot or until that exact
slot is touched again.
Could mms114_stop() be called before synthesizing the release events to
prevent this race?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616050912.1531241-1-dmitry.torokhov@gmail.com?part=5
next prev parent reply other threads:[~2026-06-16 5:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 5:09 [PATCH 1/6] Input: mms114 - fix touch indexing for MMS134S and MMS136 Dmitry Torokhov
2026-06-16 5:09 ` [PATCH 2/6] Input: mms114 - prefer GPL over GPL v2 for module license Dmitry Torokhov
2026-06-16 5:09 ` [PATCH 3/6] Input: mms114 - use appropriate register argument types Dmitry Torokhov
2026-06-16 5:20 ` sashiko-bot
2026-06-16 5:09 ` [PATCH 4/6] Input: mms114 - replace udelay with usleep_range Dmitry Torokhov
2026-06-16 5:20 ` sashiko-bot
2026-06-16 5:09 ` [PATCH 5/6] Input: mms114 - replace BUG() and fix alignment Dmitry Torokhov
2026-06-16 5:27 ` sashiko-bot [this message]
2026-06-16 7:21 ` Bryam Vargas
2026-06-16 5:09 ` [PATCH 6/6] Input: mms114 - refactor chip variant handling using descriptors Dmitry Torokhov
2026-06-16 5:20 ` sashiko-bot
2026-06-16 7:42 ` Bryam Vargas
2026-06-16 5:20 ` [PATCH 1/6] Input: mms114 - fix touch indexing for MMS134S and MMS136 sashiko-bot
2026-06-16 7:05 ` Bryam Vargas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260616052726.640521F00AC4@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.