* Re: [PATCH 1/2] input: atkbd: add softleds quirk for broken EC PS/2 emulation
From: sashiko-bot @ 2026-06-28 2:09 UTC (permalink / raw)
To: Rodnei Cilto; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260628-ideapad-kbd-leds-v1-1-50b421d94927@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The `atkbd` driver mutates the parent `serio` port's `write` function pointer to `NULL`, which is a driver model violation and permanently corrupts the bus state.
- [Medium] The newly added early return `if (atkbd->softleds) return 0;` inside `atkbd_set_leds()` is completely unreachable dead code.
Pre-existing issues:
- [High] A pre-existing race condition in `atkbd_disconnect()` can lead to a Use-After-Free of the `input_dev` structure in `atkbd_event_work()`.
--
commit 449f71d6f3b7e8daf08e55bc0da16d0f59475df4
Author: Rodnei Cilto <rodnei.cilto@gmail.com>
input: atkbd: add softleds quirk for broken EC PS/2 emulation
This commit introduces the atkbd_softleds mode to handle broken EC PS/2
emulation on some Lenovo IdeaPad laptops. It combines dumbkbd behaviour with
EV_LED registration to keep LED states visible to userspace without sending
the SETLEDS command. DMI entries are added for the Lenovo IdeaPad 83RR and
83SR.
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 8cb4dc6fb1658..826a21dc016ab 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -600,6 +602,14 @@ static int atkbd_set_leds(struct atkbd *atkbd)
> struct input_dev *dev = atkbd->dev;
> u8 param[2];
>
> + /*
> + * softleds: EC PS/2 emulation does not support AT commands
> + * after initialization. Accept LED state from userspace but
> + * never send SETLEDS (0xED) to avoid scancode corruption.
> + */
> + if (atkbd->softleds)
> + return 0;
> +
[Severity: Medium]
Is this early return reachable? When atkbd_softleds is active, atkbd_connect()
sets atkbd->write = false.
When an EV_LED event occurs, atkbd_event() checks atkbd->write and immediately
returns -1, dropping the event before atkbd_schedule_event_work() is called.
Does this mean atkbd_set_leds() is never executed by the workqueue in this
mode, and this check will never be triggered?
[ ... ]
> @@ -1291,6 +1301,12 @@ static int atkbd_connect(struct serio *serio, struct serio_driver *drv)
> if (atkbd->softrepeat)
> atkbd->softraw = true;
>
> + if (atkbd_softleds) {
> + serio->write = NULL;
> + atkbd->write = false;
> + atkbd->softleds = true;
> + }
> +
[Severity: High]
Does this permanently modify the parent bus provider's function pointer
(serio->write)?
If atkbd is unbound and another driver (e.g., serio_raw) binds to the same
port, or if atkbd is rebound, would the port remain crippled and unable to
transmit due to serio->write still being NULL?
[Severity: High]
This is a pre-existing issue, but can this sequence lead to a use-after-free
if a privileged user unbinds the driver while LED or repeat rate events are
being processed?
In atkbd_disconnect(), input_unregister_device() is called before
cancel_delayed_work_sync():
drivers/input/keyboard/atkbd.c:atkbd_disconnect() {
...
input_unregister_device(atkbd->dev);
/*
* Make sure we don't have a command in flight.
...
*/
cancel_delayed_work_sync(&atkbd->event_work);
...
}
If atkbd_event_work() starts executing on another CPU, it acquires
atkbd->mutex and checks atkbd->enabled. If preempted immediately after this
check, atkbd_disconnect() can proceed to set atkbd->enabled = false,
unregister and free the input device, and then block on
cancel_delayed_work_sync().
When the worker thread resumes, it calls atkbd_set_leds():
drivers/input/keyboard/atkbd.c:atkbd_event_work() {
...
if (!atkbd->enabled) {
...
} else {
if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
atkbd_set_leds(atkbd);
...
}
Would atkbd_set_leds() then dereference the now-freed atkbd->dev?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260628-ideapad-kbd-leds-v1-0-50b421d94927@gmail.com?part=1
^ permalink raw reply
* [git pull] Input updates for v7.2-rc0 (part 2)
From: Dmitry Torokhov @ 2026-06-28 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v7.2-rc0-2
to receive updates for the input subsystem. You will get:
- Updates to Synaptics RMI4 driver to fix potential OOB accesses in
F30 and F3A keymap handling
- A workaround in Synaptics RMI4 to tolerate buggy firmware on some
touchpads (e.g. ThinkPad T14 Gen 1) that report incomplete register
descriptor structures, preventing probe failures
- A revert of an incorrect register descriptor address calculation in
Synaptics RMI4 driver
- A fix for a regression in HP GSC PS/2 (gscps2) driver where the
receive buffer write index was not advanced, leaving keyboard and
mouse unusable.
Changelog:
---------
Bryam Vargas (2):
Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
Dmitry Torokhov (2):
Revert "Input: rmi4 - fix register descriptor address calculation"
Input: rmi4 - tolerate short register descriptor structure
Xu Rao (1):
Input: gscps2 - advance receive buffer write index
Diffstat:
--------
drivers/input/rmi4/rmi_driver.c | 39 ++++++++++++++++++++++++++-------------
drivers/input/rmi4/rmi_f30.c | 2 +-
drivers/input/rmi4/rmi_f3a.c | 2 +-
drivers/input/serio/gscps2.c | 1 +
4 files changed, 29 insertions(+), 15 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: atkbd: add softleds quirk for broken EC PS/2 emulation
From: Dmitry Torokhov @ 2026-06-28 5:20 UTC (permalink / raw)
To: Rodnei Cilto
Cc: Ike Panhc, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, linux-input, linux-kernel,
platform-driver-x86
In-Reply-To: <20260628-ideapad-kbd-leds-v1-1-50b421d94927@gmail.com>
Hi Rodnei,
On Sun, Jun 28, 2026 at 10:57:03PM -0300, Rodnei Cilto wrote:
> Some Lenovo IdeaPad laptops (e.g. 83RR/83SR, Wildcat Lake) implement
> PS/2 keyboard emulation via the Embedded Controller (EC) but do not
> fully support the AT protocol. Specifically, sending the SETLEDS
> command (0xED) after initialization causes the EC to return corrupted
> scancodes (reported as '**' in i8042.debug), rendering the keyboard
> non-functional.
"**" do not represent corrupted scancodes, they are safety measure to
not disclose your password on accident.
Use i8042.debug=1 i8042.unmask_kbd_data=1 to unveil real data.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [regression] synaptics-rmi4: Failed to read the Control Register Descriptor: EIO
From: Dmitry Torokhov @ 2026-06-28 5:43 UTC (permalink / raw)
To: David Heidelberg; +Cc: linux-input, Linux Next Mailing List
In-Reply-To: <916192e4-7d2c-4463-8576-3cfe9e36faa2@ixit.cz>
On Sat, Jun 27, 2026 at 12:06:29PM +0200, David Heidelberg wrote:
> On 26/06/2026 23:18, Dmitry Torokhov wrote:
> > Hi David,
> >
> > On Fri, Jun 26, 2026 at 11:09:54PM +0200, David Heidelberg wrote:
> > > With next-20260626 without any additional patches, the synaptics fails on
> > > OnePlus 6T with:
> > >
> > > ```
> > > [ 16.620292] rmi4_i2c 12-0020: registering I2C-connected sensor
> > > [ 16.857617] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer:
> > > Synaptics, product: S3706B, fw id: 2852315
> > > [ 16.867324] rmi4_f12 rmi4-00.fn12: Failed to read the Control Register
> > > Descriptor: -5
> > > [ 16.867338] rmi4_f12 rmi4-00.fn12: probe with driver rmi4_f12 failed with
> > > error -5
> > > ```
> >
> > Yes, at least a98518e72439 "Input: rmi4 - fix register descriptor address
> > calculation" is wrong and needs to be reverted.
>
> That did it for me, now the TS works again.
Thank you for letting me know.
--
Dmitry
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox