* Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16
From: Armin Wolf @ 2025-07-27 22:24 UTC (permalink / raw)
To: Nikita Krasnov, linux-acpi, linux-input, platform-driver-x86,
linux, fengwk94
In-Reply-To: <8f3d1015-3bef-4e7f-abea-c6665163af16@gmail.com>
Am 27.07.25 um 13:23 schrieb Nikita Krasnov:
> Hello again!
>
> Sorry for taking so long. Real life stuff gets in the way :(
>
> On Tue, Jul 22, 2025 at 07:09:37PM +0300 Armin Wolf wrote:
>> Take a look at https://docs.kernel.org/wmi/driver-development-guide.html.
> Thanks! Coupled with articles [1] and [2] this was a very good
> introduction to WMI and ACPI.
Please note that the LWN article regarding WMI drivers is quite outdated. Please follow the
WMI driver development guide from the kernel documentation instead.
>> Sure, but you have to develop a new WMI driver for your device because after looking at the
>> ACPI tables (SSDT20 in particular) i came to the conclusion that the xiaomi-wmi driver cannot
>> be used in this case.
> Why is that? Is it because xiaomi-wmi is using deprecated GUID-based WMI
> interface?
No, it is because your device is using a different WMI interface for delivering events. Device manufacturers
are not exactly known for using the same WMI interfaces for a long time :(.
> Btw, it's so weird for me that there are many laptop models, but only
> one *-wmi.c file per manufacturer (be it Xiaomi, ThinkPad, MSI or Asus).
> Is it because most of the time we write a driver for a specific piece of
> hardware that may be reused in different laptop models?
Usually a given WMI interface is used on a wide range of models so that the device manufacturers
do not have to develop a giant number of backends for their control center applications under Windows.
That is why many WMI driver work on a wide range of devices from a given manufacturer.
>> I suggest that you write a skeleton driver first that basically prints
>> the content of this buffer to the kernel log using print_hex_dump_bytes().
> About that... Would you be okay with me implementing this driver in
> Rust? I assume it's you, an ACPI WMI DRIVER maintainer, whose permission
> needs to be granted to green-light this?
Personally i have no problem with you writing a WMI driver in Rust, but currently we have
no suitable bindings for the WMI driver API. Additionally i am currently designing a new
WMI driver API that will make it easier to implement the necessary Rust bindings, so the
whole thing might take some time.
Would it be possible for you to implement the WMI driver in C?
Thanks,
Armin Wolf
> [1]: https://lwn.net/Articles/391230/
> [2]: https://lwn.net/Articles/367630/
>
> --
> Nikita Krasnov
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 1c44b818b81bf6a111a702536a560f5bc830c6d5
From: kernel test robot @ 2025-07-27 21:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 1c44b818b81bf6a111a702536a560f5bc830c6d5 Input: st1232 - add touch-overlay handling
elapsed time: 727m
configs tested: 142
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20250727 gcc-15.1.0
arc randconfig-002-20250727 gcc-8.5.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm defconfig clang-22
arm pxa_defconfig gcc-15.1.0
arm randconfig-001-20250727 gcc-11.5.0
arm randconfig-002-20250727 gcc-14.3.0
arm randconfig-003-20250727 clang-22
arm randconfig-004-20250727 gcc-10.5.0
arm socfpga_defconfig gcc-15.1.0
arm vexpress_defconfig gcc-15.1.0
arm wpcm450_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20250727 gcc-11.5.0
arm64 randconfig-002-20250727 clang-18
arm64 randconfig-003-20250727 clang-17
arm64 randconfig-004-20250727 gcc-5.5.0
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20250727 gcc-15.1.0
csky randconfig-002-20250727 gcc-12.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon defconfig clang-22
hexagon randconfig-001-20250727 clang-22
hexagon randconfig-002-20250727 clang-22
i386 allmodconfig gcc-12
i386 allnoconfig gcc-12
i386 allyesconfig gcc-12
i386 buildonly-randconfig-001-20250727 gcc-12
i386 buildonly-randconfig-002-20250727 gcc-12
i386 buildonly-randconfig-003-20250727 clang-20
i386 buildonly-randconfig-004-20250727 clang-20
i386 buildonly-randconfig-005-20250727 clang-20
i386 buildonly-randconfig-006-20250727 clang-20
i386 defconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch randconfig-001-20250727 clang-22
loongarch randconfig-002-20250727 clang-22
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k defconfig gcc-15.1.0
m68k m5307c3_defconfig gcc-15.1.0
microblaze allmodconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips db1xxx_defconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250727 gcc-8.5.0
nios2 randconfig-002-20250727 gcc-11.5.0
openrisc allnoconfig gcc-15.1.0
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
openrisc simple_smp_defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250727 gcc-11.5.0
parisc randconfig-002-20250727 gcc-12.5.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc iss476-smp_defconfig gcc-15.1.0
powerpc randconfig-001-20250727 gcc-13.4.0
powerpc randconfig-002-20250727 clang-22
powerpc randconfig-003-20250727 clang-22
powerpc64 randconfig-001-20250727 gcc-12.5.0
powerpc64 randconfig-002-20250727 clang-22
powerpc64 randconfig-003-20250727 clang-22
riscv allmodconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv randconfig-001-20250727 clang-22
riscv randconfig-002-20250727 clang-20
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 randconfig-001-20250727 clang-22
s390 randconfig-002-20250727 clang-22
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh ecovec24_defconfig gcc-15.1.0
sh edosk7760_defconfig gcc-15.1.0
sh polaris_defconfig gcc-15.1.0
sh r7785rp_defconfig gcc-15.1.0
sh randconfig-001-20250727 gcc-6.5.0
sh randconfig-002-20250727 gcc-11.5.0
sh se7780_defconfig gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250727 gcc-6.5.0
sparc randconfig-002-20250727 gcc-8.5.0
sparc64 alldefconfig gcc-15.1.0
sparc64 defconfig clang-20
sparc64 randconfig-001-20250727 gcc-7.5.0
sparc64 randconfig-002-20250727 gcc-6.5.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-12
um defconfig clang-22
um i386_defconfig gcc-12
um randconfig-001-20250727 clang-22
um randconfig-002-20250727 clang-22
um x86_64_defconfig clang-22
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250727 gcc-12
x86_64 buildonly-randconfig-002-20250727 clang-20
x86_64 buildonly-randconfig-003-20250727 clang-20
x86_64 buildonly-randconfig-004-20250727 clang-20
x86_64 buildonly-randconfig-005-20250727 clang-20
x86_64 buildonly-randconfig-006-20250727 clang-20
x86_64 defconfig gcc-11
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250727 gcc-6.5.0
xtensa randconfig-002-20250727 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16
From: Nikita Krasnov @ 2025-07-27 11:23 UTC (permalink / raw)
To: Armin Wolf, linux-acpi, linux-input, platform-driver-x86, linux,
fengwk94
In-Reply-To: <616bdb32-0d57-476b-8ad0-f2be3c5c9fbe@gmx.de>
[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]
Hello again!
Sorry for taking so long. Real life stuff gets in the way :(
On Tue, Jul 22, 2025 at 07:09:37PM +0300 Armin Wolf wrote:
> Take a look at https://docs.kernel.org/wmi/driver-development-guide.html.
Thanks! Coupled with articles [1] and [2] this was a very good
introduction to WMI and ACPI.
> Sure, but you have to develop a new WMI driver for your device because after looking at the
> ACPI tables (SSDT20 in particular) i came to the conclusion that the xiaomi-wmi driver cannot
> be used in this case.
Why is that? Is it because xiaomi-wmi is using deprecated GUID-based WMI
interface?
Btw, it's so weird for me that there are many laptop models, but only
one *-wmi.c file per manufacturer (be it Xiaomi, ThinkPad, MSI or Asus).
Is it because most of the time we write a driver for a specific piece of
hardware that may be reused in different laptop models?
> I suggest that you write a skeleton driver first that basically prints
> the content of this buffer to the kernel log using print_hex_dump_bytes().
About that... Would you be okay with me implementing this driver in
Rust? I assume it's you, an ACPI WMI DRIVER maintainer, whose permission
needs to be granted to green-light this?
[1]: https://lwn.net/Articles/391230/
[2]: https://lwn.net/Articles/367630/
--
Nikita Krasnov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH v11 0/4] Input: support overlay objects on touchscreens
From: Dmitry Torokhov @ 2025-07-27 8:43 UTC (permalink / raw)
To: Javier Carrasco
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastian Hecht,
Michael Riesch, linux-input, devicetree, linux-kernel,
Jeff LaBundy
In-Reply-To: <e2ed48bf-386b-4c14-bc9e-0519da415c73@wolfvision.net>
Hi Javier,
On Thu, Jan 16, 2025 at 11:41:14AM +0100, Javier Carrasco wrote:
>
> Hi,
>
> as a couple of months have passed since the last submission, I would
> like to send a short reminder that this series is still relevant. It is
> of course not urgent, an Ack to confirm that is on the queue would be fine.
>
> Some commercial products are using this feature since its last
> submission without finding new issues, and it would be ready for a new
> review in its current form. I just verified that it applies cleanly to
> v6.13-rc7, but if for some reason a resend is desired, I will do it
> promptly.
Sorry for sitting on this for so long. The series has been applied.
Thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: atkbd - Correctly map F13 - F24
From: Dmitry Torokhov @ 2025-07-27 8:28 UTC (permalink / raw)
To: Werner Sembach; +Cc: hansg, linux-input, linux-kernel
In-Reply-To: <20250722120438.28011-1-wse@tuxedocomputers.com>
On Tue, Jul 22, 2025 at 02:04:35PM +0200, Werner Sembach wrote:
> Currently only F23 is correctly mapped for PS/2 keyboards.
>
> According to this table:
> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf
>
> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world
> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the
> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is
> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway.
>
> * Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for
> some reason and it is actually used in a touchpad toggle shortcut, but this is
> currently being fixed in both KDE and xkeyboard-config to make this less weird,
> so it could directly be fixed to correctly handle the F24 keypress instead.
>
> - The scancodes for F13-F22 are currently unmapped so there will probably be no
> harm in mapping them. This would also fix the issue that some of these keys
> can't be mapped as the target from userspace using the `setkeycodes` command.
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] Input - xpad: Use new BTN_GRIP* buttons
From: Dmitry Torokhov @ 2025-07-27 8:23 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20250717000143.1902875-3-vi@endrift.com>
On Wed, Jul 16, 2025 at 05:01:39PM -0700, Vicki Pfau wrote:
> Signed-off-by: Vicki Pfau <vi@endrift.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] Input: Add and document BTN_GRIP*
From: Dmitry Torokhov @ 2025-07-27 8:22 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20250702040102.125432-2-vi@endrift.com>
On Tue, Jul 01, 2025 at 09:01:00PM -0700, Vicki Pfau wrote:
> Many controllers these days have started including grip buttons. As there has
> been no particular assigned BTN_* constants for these, they've been
> hapharzardly assigned to BTN_TRIGGER_HAPPY*. Unfortunately, the assignemnt of
> these has varied significantly between drivers. This patch adds and documents
> new constants for these grip buttons.
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xpad - Change buttons the D-Pad gets mapped as to BTN_DPAD_*
From: Dmitry Torokhov @ 2025-07-27 8:22 UTC (permalink / raw)
To: Vicki Pfau; +Cc: linux-input
In-Reply-To: <20250702034740.124817-1-vi@endrift.com>
On Tue, Jul 01, 2025 at 08:47:40PM -0700, Vicki Pfau wrote:
> Since dance pads can have both up/down or left/right pressed at the same time,
> by design, they are not suitable for mapping the buttons to axes. Historically,
> this driver mapped the D-pad to BTN_TRIGGER_HAPPY1-4 in these cases, and before
> that as mouse buttons. However, BTN_DPAD_* exists for this and makes far more
> sense than the arbitrary mapping it was before.
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
This unfortunately changes existing mappings, but I guess new events are
better than old ones...
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Documentation: Fix capitalization of XBox -> Xbox
From: Dmitry Torokhov @ 2025-07-27 8:22 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Jonathan Corbet, linux-input, linux-doc
In-Reply-To: <20250702034500.124741-1-vi@endrift.com>
On Tue, Jul 01, 2025 at 08:45:00PM -0700, Vicki Pfau wrote:
> This also improves the phrasing of "an example" listing two examples.
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH] hid: fix I2C read buffer overflow in raw_event() for mcp2221
From: Arnaud Lecomte @ 2025-07-26 22:09 UTC (permalink / raw)
To: Rishi Gupta
Cc: Jiri Kosina, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel, syzbot+52c1a7d3e5b361ccd346, Arnaud Lecomte
As reported by syzbot, mcp2221_raw_event lacked
validation of incoming I2C read data sizes, risking buffer
overflows in mcp->rxbuf during multi-part transfers.
As highlighted in the DS20005565B spec, p44, we have:
"The number of read-back data bytes to follow in this packet:
from 0 to a maximum of 60 bytes of read-back bytes."
This patch enforces we don't exceed this limit.
Reported-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346
Tested-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com>
---
drivers/hid/hid-mcp2221.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 0f93c22a479f..83941b916cd6 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -814,6 +814,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
}
if (data[2] == MCP2221_I2C_READ_COMPL ||
data[2] == MCP2221_I2C_READ_PARTIAL) {
+ if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
+ mcp->status = -EINVAL;
+ break;
+ }
buf = mcp->rxbuf;
memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] [usb?] [input?] KASAN: slab-out-of-bounds Read in mcp2221_raw_event
From: syzbot @ 2025-07-26 22:03 UTC (permalink / raw)
To: contact, linux-input, linux-kernel, linux-usb, syzkaller-bugs
In-Reply-To: <20250726204144.107432-1-contact@arnaud-lcm.com>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Tested-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Tested on:
commit: 51d4b0a4 usb: musb: omap2430: clean up probe error han..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=103028a2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=b3af2d4b01cd6138
dashboard link: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=16574034580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* syztest
From: Arnaud Lecomte @ 2025-07-26 20:41 UTC (permalink / raw)
To: syzbot+52c1a7d3e5b361ccd346
Cc: linux-input, linux-kernel, linux-usb, syzkaller-bugs
In-Reply-To: <67535904.050a0220.2477f.0008.GAE@google.com>
#syz test
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -814,6 +814,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
}
if (data[2] == MCP2221_I2C_READ_COMPL ||
data[2] == MCP2221_I2C_READ_PARTIAL) {
+ if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
+ mcp->status = -EINVAL;
+ break;
+ }
buf = mcp->rxbuf;
memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
--
^ permalink raw reply
* Re: [syzbot] [input?] possible deadlock in input_ff_flush
From: syzbot @ 2025-07-26 18:46 UTC (permalink / raw)
To: boqun.feng, dmitry.torokhov, hdanton, linux-input, linux-kernel,
penguin-kernel, syzkaller-bugs
In-Reply-To: <677a7db3.050a0220.380ff0.0012.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 5f33ebd2018c Merge tag 'drm-fixes-2025-07-26' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130d4034580000
kernel config: https://syzkaller.appspot.com/x/.config?x=9f175a9275d2cdd7
dashboard link: https://syzkaller.appspot.com/bug?extid=ed7c6209f62eba1565aa
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=108d4034580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=148d4034580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/744f4180f939/disk-5f33ebd2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/473dde4ed605/vmlinux-5f33ebd2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8a27e8b2b834/bzImage-5f33ebd2.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ed7c6209f62eba1565aa@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc7-syzkaller-00120-g5f33ebd2018c #0 Not tainted
------------------------------------------------------
udevd/5831 is trying to acquire lock:
ffff8880259b80b0 (&ff->mutex){+.+.}-{4:4}, at: class_mutex_constructor include/linux/mutex.h:225 [inline]
ffff8880259b80b0 (&ff->mutex){+.+.}-{4:4}, at: input_ff_flush+0x63/0x180 drivers/input/ff-core.c:231
but task is already holding lock:
ffff8880268022c0 (&dev->mutex#2){+.+.}-{4:4}, at: class_mutex_intr_constructor include/linux/mutex.h:227 [inline]
ffff8880268022c0 (&dev->mutex#2){+.+.}-{4:4}, at: input_flush_device+0x55/0x110 drivers/input/input.c:625
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&dev->mutex#2){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x199/0xb90 kernel/locking/mutex.c:747
class_mutex_intr_constructor include/linux/mutex.h:227 [inline]
input_register_handle+0xdc/0x620 drivers/input/input.c:2653
kbd_connect+0xca/0x160 drivers/tty/vt/keyboard.c:1580
input_attach_handler.isra.0+0x184/0x260 drivers/input/input.c:993
input_register_device+0xa84/0x1130 drivers/input/input.c:2412
acpi_button_add+0x582/0xb70 drivers/acpi/button.c:621
acpi_device_probe+0xc6/0x330 drivers/acpi/bus.c:1076
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__driver_attach+0x283/0x580 drivers/base/dd.c:1215
bus_for_each_dev+0x13e/0x1d0 drivers/base/bus.c:370
bus_add_driver+0x2e9/0x690 drivers/base/bus.c:678
driver_register+0x15c/0x4b0 drivers/base/driver.c:249
__acpi_bus_register_driver+0xdf/0x130 drivers/acpi/bus.c:1027
acpi_button_register_driver drivers/acpi/button.c:751 [inline]
acpi_button_driver_init+0x82/0x110 drivers/acpi/button.c:760
do_one_initcall+0x120/0x6e0 init/main.c:1274
do_initcall_level init/main.c:1336 [inline]
do_initcalls init/main.c:1352 [inline]
do_basic_setup init/main.c:1371 [inline]
kernel_init_freeable+0x5c2/0x900 init/main.c:1584
kernel_init+0x1c/0x2b0 init/main.c:1474
ret_from_fork+0x5d4/0x6f0 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #2 (input_mutex){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x199/0xb90 kernel/locking/mutex.c:747
class_mutex_intr_constructor include/linux/mutex.h:227 [inline]
input_register_device+0x98a/0x1130 drivers/input/input.c:2408
uinput_create_device drivers/input/misc/uinput.c:365 [inline]
uinput_ioctl_handler.isra.0+0x1357/0x1df0 drivers/input/misc/uinput.c:918
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (&newdev->mutex){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x199/0xb90 kernel/locking/mutex.c:747
uinput_request_send drivers/input/misc/uinput.c:151 [inline]
uinput_request_submit.part.0+0x25/0x2e0 drivers/input/misc/uinput.c:182
uinput_request_submit drivers/input/misc/uinput.c:179 [inline]
uinput_dev_upload_effect+0x174/0x1f0 drivers/input/misc/uinput.c:257
input_ff_upload+0x568/0xc10 drivers/input/ff-core.c:148
evdev_do_ioctl+0xf40/0x1b30 drivers/input/evdev.c:1181
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x16f/0x1a0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&ff->mutex){+.+.}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3168 [inline]
check_prevs_add kernel/locking/lockdep.c:3287 [inline]
validate_chain kernel/locking/lockdep.c:3911 [inline]
__lock_acquire+0x126f/0x1c90 kernel/locking/lockdep.c:5240
lock_acquire kernel/locking/lockdep.c:5871 [inline]
lock_acquire+0x179/0x350 kernel/locking/lockdep.c:5828
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x199/0xb90 kernel/locking/mutex.c:747
class_mutex_constructor include/linux/mutex.h:225 [inline]
input_ff_flush+0x63/0x180 drivers/input/ff-core.c:231
uinput_dev_flush+0x2a/0x40 drivers/input/misc/uinput.c:283
input_flush_device+0xa1/0x110 drivers/input/input.c:627
evdev_release+0x344/0x420 drivers/input/evdev.c:435
__fput+0x3ff/0xb70 fs/file_table.c:465
fput_close_sync+0x118/0x260 fs/file_table.c:570
__do_sys_close fs/open.c:1589 [inline]
__se_sys_close fs/open.c:1574 [inline]
__x64_sys_close+0x8b/0x120 fs/open.c:1574
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Chain exists of:
&ff->mutex --> input_mutex --> &dev->mutex#2
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev->mutex#2);
lock(input_mutex);
lock(&dev->mutex#2);
lock(&ff->mutex);
*** DEADLOCK ***
2 locks held by udevd/5831:
#0: ffff888026803118 (&evdev->mutex){+.+.}-{4:4}, at: evdev_release+0x79/0x420 drivers/input/evdev.c:432
#1: ffff8880268022c0 (&dev->mutex#2){+.+.}-{4:4}, at: class_mutex_intr_constructor include/linux/mutex.h:227 [inline]
#1: ffff8880268022c0 (&dev->mutex#2){+.+.}-{4:4}, at: input_flush_device+0x55/0x110 drivers/input/input.c:625
stack backtrace:
CPU: 0 UID: 0 PID: 5831 Comm: udevd Not tainted 6.16.0-rc7-syzkaller-00120-g5f33ebd2018c #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_circular_bug+0x275/0x350 kernel/locking/lockdep.c:2046
check_noncircular+0x14c/0x170 kernel/locking/lockdep.c:2178
check_prev_add kernel/locking/lockdep.c:3168 [inline]
check_prevs_add kernel/locking/lockdep.c:3287 [inline]
validate_chain kernel/locking/lockdep.c:3911 [inline]
__lock_acquire+0x126f/0x1c90 kernel/locking/lockdep.c:5240
lock_acquire kernel/locking/lockdep.c:5871 [inline]
lock_acquire+0x179/0x350 kernel/locking/lockdep.c:5828
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x199/0xb90 kernel/locking/mutex.c:747
class_mutex_constructor include/linux/mutex.h:225 [inline]
input_ff_flush+0x63/0x180 drivers/input/ff-core.c:231
uinput_dev_flush+0x2a/0x40 drivers/input/misc/uinput.c:283
input_flush_device+0xa1/0x110 drivers/input/input.c:627
evdev_release+0x344/0x420 drivers/input/evdev.c:435
__fput+0x3ff/0xb70 fs/file_table.c:465
fput_close_sync+0x118/0x260 fs/file_table.c:570
__do_sys_close fs/open.c:1589 [inline]
__se_sys_close fs/open.c:1574 [inline]
__x64_sys_close+0x8b/0x120 fs/open.c:1574
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7c2f2a7407
Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007fff6a7623b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 00007f7c2fa12880 RCX: 00007f7c2f2a7407
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000008
RBP: 00007f7c2fa126e8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000016
R13: 00007fff6a7624c0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* Re: [PATCH] dt-bindings: touchscreen: drop any reference to touchscreen.txt
From: Rob Herring @ 2025-07-25 23:03 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Broadcom internal kernel review list,
Conor Dooley, Dmitry Torokhov, Florian Fainelli,
Krzysztof Kozlowski, devicetree, linux-arm-kernel, linux-input,
linux-rpi-kernel
In-Reply-To: <20250723071442.3456665-1-dario.binacchi@amarulasolutions.com>
On Wed, Jul 23, 2025 at 09:14:20AM +0200, Dario Binacchi wrote:
> With commit 1d6204e2f51f ("dt-bindings: touchscreen: Add touchscreen
> schema") touchscreen.txt is no longer needed. Remove the file and
> replace every reference to it with the corresponding YAML schema.
The point of what touchscreen.txt says is to not do this. I'd rather see
time spent on conversions. But you've already done it, so:
Acked-by: Rob Herring (Arm) <robh@kernel.org>
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
> .../devicetree/bindings/input/touchscreen/bu21013.txt | 2 +-
> .../devicetree/bindings/input/touchscreen/eeti.txt | 2 +-
> .../input/touchscreen/raspberrypi,firmware-ts.txt | 10 +++++-----
> .../bindings/input/touchscreen/touchscreen.txt | 1 -
> .../devicetree/bindings/input/touchscreen/zet6223.txt | 10 +++++-----
> 5 files changed, 12 insertions(+), 13 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
^ permalink raw reply
* Re: (subset) [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
From: Benjamin Tissoires @ 2025-07-25 11:46 UTC (permalink / raw)
To: syzbot, Alan Stern
Cc: jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs
In-Reply-To: <8bec1698-5008-428f-8e71-ec002def0c54@rowland.harvard.edu>
On Tue, 15 Jul 2025 15:29:25 -0400, Alan Stern wrote:
> On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> > git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15a830f0580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> > compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> >
> > usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> > usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> > usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > usb 4-1: config 0 descriptor??
> > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > ------------[ cut here ]------------
> > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > shift exponent 4294967295 is too large for 32-bit type 'int'
> > CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > <TASK>
> > __dump_stack lib/dump_stack.c:94 [inline]
> > dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> > ubsan_epilogue lib/ubsan.c:233 [inline]
> > __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> > s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> > hid_output_field drivers/hid/hid-core.c:1841 [inline]
> > hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> > __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> > hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> > hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
>
> [...]
Applied to hid/hid.git (for-6.17/core), thanks!
[1/1] HID: core: Harden s32ton() against conversion to 0 bits
https://git.kernel.org/hid/hid/c/a6b87bfc2ab5
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH v2 2/2] platform/x86: thinkpad_acpi: Use trackpoint doubletap interface via sysfs
From: Vishnu Sankar @ 2025-07-24 20:23 UTC (permalink / raw)
To: dmitry.torokhov, hmh, hansg, ilpo.jarvinen
Cc: mpearson-lenovo, linux-input, linux-kernel, ibm-acpi-devel,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20250724202349.11200-1-vishnuocv@gmail.com>
TrackPoint devices supporting doubletap expose a sysfs attribute under
/sys/devices/.../trackpoint/doubletap_enabled. This patch enables
thinkpad_acpi to detect if the system has a TrackPoint device with
doubletap capability, and allows toggling the feature via sysfs.
This avoids direct linking between subsystems and relies on sysfs
as the interface for coordination between input and platform drivers.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Changes in v2:
- Updated commit message to clarify dependency on trackpoint driver
- Now handling sysfs read/write of trackpoint driver using file read/write
- Removed sysfs attribute creation of trackpoint double tap here.
- Reversed the logic and return false right away
- Dropped unnecessary debug messages
- Using dev_dbg() instead of pr_xxxx()
---
drivers/platform/x86/thinkpad_acpi.c | 155 +++++++++++++++++++++++++--
1 file changed, 147 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index b59b4d90b0c7..cb981de9bbb2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -72,6 +72,13 @@
#include <linux/units.h>
#include <linux/workqueue.h>
+#include <linux/fs.h>
+#include <linux/file.h>
+#include <linux/err.h>
+#include <linux/fcntl.h>
+#include <linux/namei.h>
+#include <linux/kernel_read_file.h>
+
#include <acpi/battery.h>
#include <acpi/video.h>
@@ -373,7 +380,8 @@ static struct {
u32 hotkey_poll_active:1;
u32 has_adaptive_kbd:1;
u32 kbd_lang:1;
- u32 trackpoint_doubletap:1;
+ u32 trackpoint_doubletap_state:1;
+ u32 trackpoint_doubletap_capable:1;
struct quirk_entry *quirks;
} tp_features;
@@ -2879,6 +2887,107 @@ static DEVICE_ATTR_RW(hotkey_poll_freq);
#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+/*
+ * Trackpoint doubletap handlers
+ * These set of functions will communicate with the sysfs attributes of TrackPoint driver
+ * Attribute : /sys/bus/serio/devices/seriox/doubletap_enabled
+ */
+
+/* Global buffer to reuse path */
+static char trackpoint_doubletap_path[128];
+
+/* Function to find the correct serio path with TrackPoint attribute "doubletap_enabled" */
+static int thinkpad_find_trackpoint_path(void)
+{
+ struct path serio_path;
+ char path_buf[128];
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ snprintf(path_buf, sizeof(path_buf),
+ "/sys/bus/serio/devices/serio%d/doubletap_enabled", i);
+
+ if (!kern_path(path_buf, LOOKUP_FOLLOW, &serio_path)) {
+ path_put(&serio_path);
+ snprintf(trackpoint_doubletap_path, sizeof(trackpoint_doubletap_path),
+ "%s", path_buf);
+ pr_info("ThinkPad ACPI: TrackPoint doubletap found at %s\n",
+ trackpoint_doubletap_path);
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+/* Writing to the sysfs attribute of Trackpoint "doubletap_enabled" */
+static int write_doubletap_sysfs_value(const void *buf, size_t count, loff_t *pos)
+{
+ struct file *filp;
+ ssize_t written;
+
+ if (!buf)
+ return -EINVAL;
+
+ filp = filp_open(trackpoint_doubletap_path, O_WRONLY | O_CREAT, 0644);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
+
+ /* Required to avoid EINVAL from vfs checks in some cases */
+ if (!(filp->f_mode & FMODE_CAN_WRITE)) {
+ filp_close(filp, NULL);
+ return -EINVAL;
+ }
+
+ /* Write using kernel_write */
+ written = kernel_write(filp, buf, count, pos);
+ filp_close(filp, NULL);
+
+ return written < 0 ? written : 0;
+}
+
+/* Function to read the TrackPoint doubletap status */
+static int trackpoint_read_doubletap_status(bool *enabled)
+{
+ struct file *filp;
+ loff_t pos = 0;
+ char buf[8];
+ ssize_t ret;
+
+ if (!enabled)
+ return -EINVAL;
+
+ if (!trackpoint_doubletap_path[0])
+ return -ENODEV;
+
+ filp = filp_open(trackpoint_doubletap_path, O_RDONLY, 0);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
+
+ ret = kernel_read(filp, buf, sizeof(buf) - 1, &pos);
+ filp_close(filp, NULL);
+
+ if (ret < 0)
+ return ret;
+
+ buf[ret] = '\0'; // Safe: ret < sizeof(buf)
+
+ *enabled = (buf[0] == '1');
+
+ return 0;
+}
+
+/* Function to check the TrackPoint doubletap status */
+static int thinkpad_set_doubletap_status(bool enable)
+{
+ const char *val = enable ? "1" : "0";
+ loff_t pos = 0;
+
+ if (!trackpoint_doubletap_path[0])
+ return -ENODEV;
+
+ return write_doubletap_sysfs_value(val, strlen(val), &pos);
+}
+
/* sysfs hotkey radio_sw (pollable) ------------------------------------ */
static ssize_t hotkey_radio_sw_show(struct device *dev,
struct device_attribute *attr,
@@ -3326,6 +3435,8 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
bool radiosw_state = false;
bool tabletsw_state = false;
int hkeyv, res, status, camera_shutter_state;
+ bool dt_state;
+ int rc;
vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_HKEY,
"initializing hotkey subdriver\n");
@@ -3557,9 +3668,22 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
hotkey_poll_setup_safe(true);
- /* Enable doubletap by default */
- tp_features.trackpoint_doubletap = 1;
+ /* Checking doubletap status by default */
+ rc = thinkpad_find_trackpoint_path();
+ if (rc) {
+ dev_dbg(&tpacpi_pdev->dev, "Could not find TrackPoint doubletap sysfs path\n");
+ tp_features.trackpoint_doubletap_capable = false;
+ return 0;
+ }
+ tp_features.trackpoint_doubletap_capable = true;
+ rc = trackpoint_read_doubletap_status(&dt_state);
+ if (rc) {
+ /* Disable if access to register fails */
+ dt_state = false;
+ dev_dbg(&tpacpi_pdev->dev, "Doubletap failed to check status\n");
+ }
+ tp_features.trackpoint_doubletap_state = dt_state;
return 0;
}
@@ -3863,9 +3987,7 @@ static bool hotkey_notify_8xxx(const u32 hkey, bool *send_acpi_ev)
{
switch (hkey) {
case TP_HKEY_EV_TRACK_DOUBLETAP:
- if (tp_features.trackpoint_doubletap)
- tpacpi_input_send_key(hkey, send_acpi_ev);
-
+ *send_acpi_ev = true;
return true;
default:
return false;
@@ -11194,6 +11316,7 @@ static struct platform_driver tpacpi_hwmon_pdriver = {
static bool tpacpi_driver_event(const unsigned int hkey_event)
{
int camera_shutter_state;
+ int rc;
switch (hkey_event) {
case TP_HKEY_EV_BRGHT_UP:
@@ -11285,8 +11408,24 @@ static bool tpacpi_driver_event(const unsigned int hkey_event)
mutex_unlock(&tpacpi_inputdev_send_mutex);
return true;
case TP_HKEY_EV_DOUBLETAP_TOGGLE:
- tp_features.trackpoint_doubletap = !tp_features.trackpoint_doubletap;
- return true;
+ if (tp_features.trackpoint_doubletap_capable) {
+ rc = thinkpad_set_doubletap_status(!tp_features.trackpoint_doubletap_state);
+
+ if (rc) {
+ dev_dbg(&tpacpi_pdev->dev, "Trackpoint doubletap toggle failed\n");
+ } else {
+ tp_features.trackpoint_doubletap_state =
+ !tp_features.trackpoint_doubletap_state;
+ dev_dbg(&tpacpi_pdev->dev, "Trackpoint doubletap is %s\n",
+ tp_features.trackpoint_doubletap_state ? "enabled" : "disabled");
+ return true;
+ }
+ }
+ /*
+ * Suppress the event if Doubletap is not supported
+ * or if the trackpoint_set_doubletap_status() is failing
+ */
+ return false;
case TP_HKEY_EV_PROFILE_TOGGLE:
case TP_HKEY_EV_PROFILE_TOGGLE2:
platform_profile_cycle();
--
2.48.1
^ permalink raw reply related
* [PATCH v2 1/2] input: mouse: trackpoint: Add doubletap enable/disable support
From: Vishnu Sankar @ 2025-07-24 20:23 UTC (permalink / raw)
To: dmitry.torokhov, hmh, hansg, ilpo.jarvinen
Cc: mpearson-lenovo, linux-input, linux-kernel, ibm-acpi-devel,
platform-driver-x86, vsankar, Vishnu Sankar
Add support for enabling and disabling doubletap on TrackPoint devices
that support this functionality. The feature is detected using firmware
ID and exposed via sysfs as `doubletap_enabled`.
The feature is only available on newer ThinkPads (2023 and later).The driver
exposes this capability via a new sysfs attribute:
"/sys/bus/serio/devices/seriox/doubletap_enabled".
The attribute is only created if the device is detected to be capable of
doubletap via firmware and variant ID checks. This functionality will be
used by platform drivers such as thinkpad_acpi to expose and control doubletap
via user interfaces.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Changes in v2:
- Improve commit messages
- Sysfs attributes moved to trackpoint.c
- Removed unnecessary comments
- Removed unnecessary debug messages
- Using strstarts() instead of strcmp()
- is_trackpoint_dt_capable() modified
- Removed _BIT suffix and used BIT() define.
- Reverse the trackpoint_doubletap_status() logic to return error first.
- Removed export functions as a result of the design change
- Changed trackpoint_dev->psmouse to parent_psmouse
- The path of trackpoint.h is not changed.
---
drivers/input/mouse/trackpoint.c | 149 +++++++++++++++++++++++++++++++
drivers/input/mouse/trackpoint.h | 15 ++++
2 files changed, 164 insertions(+)
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index 5f6643b69a2c..c6f17b0dec3a 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -16,6 +16,8 @@
#include "psmouse.h"
#include "trackpoint.h"
+static struct trackpoint_data *trackpoint_dev;
+
static const char * const trackpoint_variants[] = {
[TP_VARIANT_IBM] = "IBM",
[TP_VARIANT_ALPS] = "ALPS",
@@ -63,6 +65,21 @@ static int trackpoint_write(struct ps2dev *ps2dev, u8 loc, u8 val)
return ps2_command(ps2dev, param, MAKE_PS2_CMD(3, 0, TP_COMMAND));
}
+/* Read function for TrackPoint extended registers */
+static int trackpoint_extended_read(struct ps2dev *ps2dev, u8 loc, u8 *val)
+{
+ u8 ext_param[2] = {TP_READ_MEM, loc};
+ int error;
+
+ error = ps2_command(ps2dev,
+ ext_param, MAKE_PS2_CMD(2, 1, TP_COMMAND));
+
+ if (!error)
+ *val = ext_param[0];
+
+ return error;
+}
+
static int trackpoint_toggle_bit(struct ps2dev *ps2dev, u8 loc, u8 mask)
{
u8 param[3] = { TP_TOGGLE, loc, mask };
@@ -393,6 +410,131 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
return 0;
}
+/* List of known incapable device PNP IDs */
+static const char * const dt_incompatible_devices[] = {
+ "LEN0304",
+ "LEN0306",
+ "LEN0317",
+ "LEN031A",
+ "LEN031B",
+ "LEN031C",
+ "LEN031D",
+};
+
+/*
+ * checks if it’s a doubletap capable device
+ * The PNP ID format eg: is "PNP: LEN030d PNP0f13".
+ */
+static bool is_trackpoint_dt_capable(const char *pnp_id)
+{
+ const char *id_start;
+ char id[8];
+
+ if (!strstarts(pnp_id, "PNP: LEN03"))
+ return false;
+
+ /* Points to "LEN03xxxx" */
+ id_start = pnp_id + 5;
+ if (sscanf(id_start, "%7s", id) != 1)
+ return false;
+
+ /* Check if it's blacklisted */
+ for (size_t i = 0; i < ARRAY_SIZE(dt_incompatible_devices); ++i) {
+ if (strcmp(id, dt_incompatible_devices[i]) == 0)
+ return false;
+ }
+ return true;
+}
+
+/* Trackpoint doubletap status function */
+static int trackpoint_doubletap_status(bool *status)
+{
+ struct trackpoint_data *tp = trackpoint_dev;
+ struct ps2dev *ps2dev = &tp->parent_psmouse->ps2dev;
+ u8 reg_val;
+ int rc;
+
+ /* Reading the Doubletap register using extended read */
+ rc = trackpoint_extended_read(ps2dev, TP_DOUBLETAP, ®_val);
+ if (rc)
+ return rc;
+
+ *status = reg_val & TP_DOUBLETAP_STATUS ? true : false;
+
+ return 0;
+}
+
+/* Trackpoint doubletap enable/disable function */
+static int trackpoint_set_doubletap(bool enable)
+{
+ struct trackpoint_data *tp = trackpoint_dev;
+ struct ps2dev *ps2dev = &tp->parent_psmouse->ps2dev;
+ static u8 doubletap_state;
+ u8 new_val;
+
+ if (!tp)
+ return -ENODEV;
+
+ new_val = enable ? TP_DOUBLETAP_ENABLE : TP_DOUBLETAP_DISABLE;
+
+ if (doubletap_state == new_val)
+ return 0;
+
+ doubletap_state = new_val;
+
+ return trackpoint_write(ps2dev, TP_DOUBLETAP, new_val);
+}
+
+/*
+ * Trackpoint Doubletap Interface
+ * Control/Monitoring of Trackpoint Doubletap from:
+ * /sys/bus/serio/devices/seriox/doubletap_enabled
+ */
+static ssize_t doubletap_enabled_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct serio *serio = to_serio_port(dev);
+ struct psmouse *psmouse = psmouse_from_serio(serio);
+ struct trackpoint_data *tp = psmouse->private;
+ bool status;
+ int rc;
+
+ if (!tp || !tp->doubletap_capable)
+ return -ENODEV;
+
+ rc = trackpoint_doubletap_status(&status);
+ if (rc)
+ return rc;
+
+ return sysfs_emit(buf, "%d\n", status ? 1 : 0);
+}
+
+static ssize_t doubletap_enabled_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct serio *serio = to_serio_port(dev);
+ struct psmouse *psmouse = psmouse_from_serio(serio);
+ struct trackpoint_data *tp = psmouse->private;
+ bool enable;
+ int err;
+
+ if (!tp || !tp->doubletap_capable)
+ return -ENODEV;
+
+ err = kstrtobool(buf, &enable);
+ if (err)
+ return err;
+
+ err = trackpoint_set_doubletap(enable);
+ if (err)
+ return err;
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(doubletap_enabled);
+
int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
{
struct ps2dev *ps2dev = &psmouse->ps2dev;
@@ -425,6 +567,9 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
psmouse->reconnect = trackpoint_reconnect;
psmouse->disconnect = trackpoint_disconnect;
+ trackpoint_dev = psmouse->private;
+ trackpoint_dev->parent_psmouse = psmouse;
+
if (variant_id != TP_VARIANT_IBM) {
/* Newer variants do not support extended button query. */
button_info = 0x33;
@@ -470,6 +615,10 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
psmouse->vendor, firmware_id,
(button_info & 0xf0) >> 4, button_info & 0x0f);
+ tp->doubletap_capable = is_trackpoint_dt_capable(ps2dev->serio->firmware_id);
+ if (tp->doubletap_capable)
+ device_create_file(&psmouse->ps2dev.serio->dev, &dev_attr_doubletap_enabled);
+
return 0;
}
diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
index eb5412904fe0..256e8cb35581 100644
--- a/drivers/input/mouse/trackpoint.h
+++ b/drivers/input/mouse/trackpoint.h
@@ -8,6 +8,8 @@
#ifndef _TRACKPOINT_H
#define _TRACKPOINT_H
+#include <linux/bitops.h>
+
/*
* These constants are from the TrackPoint System
* Engineering documentation Version 4 from IBM Watson
@@ -69,6 +71,8 @@
/* (how hard it is to drag */
/* with Z-axis pressed) */
+#define TP_DOUBLETAP 0x58 /* TrackPoint doubletap register */
+
#define TP_MINDRAG 0x59 /* Minimum amount of force needed */
/* to trigger dragging */
@@ -139,6 +143,14 @@
#define TP_DEF_TWOHAND 0x00
#define TP_DEF_SOURCE_TAG 0x00
+/* Doubletap register values */
+#define TP_DOUBLETAP_ENABLE 0xFF /* Enable value */
+#define TP_DOUBLETAP_DISABLE 0xFE /* Disable value */
+
+#define TP_DOUBLETAP_STATUS_BIT 0 /* 0th bit defines enable/disable */
+
+#define TP_DOUBLETAP_STATUS BIT(TP_DOUBLETAP_STATUS_BIT)
+
#define MAKE_PS2_CMD(params, results, cmd) ((params<<12) | (results<<8) | (cmd))
struct trackpoint_data {
@@ -150,11 +162,14 @@ struct trackpoint_data {
u8 thresh, upthresh;
u8 ztime, jenks;
u8 drift_time;
+ bool doubletap_capable;
/* toggles */
bool press_to_select;
bool skipback;
bool ext_dev;
+
+ struct psmouse *parent_psmouse;
};
int trackpoint_detect(struct psmouse *psmouse, bool set_properties);
--
2.48.1
^ permalink raw reply related
* Re: [PATCH] HID: multitouch: fix integer overflow in set_abs()
From: Qasim Ijaz @ 2025-07-24 15:56 UTC (permalink / raw)
To: Jiri Slaby; +Cc: jikos, bentiss, linux-input, linux-kernel, stable
In-Reply-To: <914ff45b-2260-42c0-9ccf-a3efd667d4f5@kernel.org>
On Thu, Jul 24, 2025 at 08:58:40AM +0200, Jiri Slaby wrote:
> On 23. 07. 25, 19:36, Qasim Ijaz wrote:
> > It is possible for a malicious HID device to trigger a signed integer
> > overflow (undefined behaviour) in set_abs() in the following expression
> > by supplying bogus logical maximum and minimum values:
> >
> > int fuzz = snratio ? (fmax - fmin) / snratio : 0;
> >
> > For example, if the logical_maximum is INT_MAX and logical_minimum is -1
> > then (fmax - fmin) resolves to INT_MAX + 1, which does not fit in a 32-bit
> > signed int, so the subtraction overflows.
>
> The question is if it matters with -fwrapv?
Ah yea thanks for bringing this up Jiri. I think you might be correct,
after doing some research it looks like the kernel enables -fno‑strict‑overflow
which implies -fwrapv which leads to wrap around instead of UB If I undestand
correctly. So with that in mind this patch probably doesn't do anything
useful, do you agree?
Thanks
qasim.
>
> > Fix this by computing the
> > difference in a 64 bit context.
> >
> > Fixes: 5519cab477b6 ("HID: hid-multitouch: support for PixCir-based panels")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
> > ---
> > drivers/hid/hid-multitouch.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 22c6314a8843..687638ed6d0f 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -540,7 +540,8 @@ static void set_abs(struct input_dev *input, unsigned int code,
> > {
> > int fmin = field->logical_minimum;
> > int fmax = field->logical_maximum;
> > - int fuzz = snratio ? (fmax - fmin) / snratio : 0;
> > + s64 diff = (s64)fmax - (s64)fmin;
> > + int fuzz = snratio ? (int)div_s64(diff, snratio) : 0;
> > input_set_abs_params(input, code, fmin, fmax, fuzz, 0);
> > input_abs_set_res(input, code, hidinput_calc_abs_res(field, code));
> > }
>
> --
> js
> suse labs
>
^ permalink raw reply
* [PATCH][next] HID: Kconfig: Fix spelling mistake "enthropy" -> "entropy"
From: Colin Ian King @ 2025-07-24 11:11 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: kernel-janitors, linux-kernel
There is a spelling mistake in the HID_U2FZERO description. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
---
drivers/hid/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..79997553d8f9 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1243,7 +1243,7 @@ config HID_U2FZERO
U2F Zero supports custom commands for blinking the LED
and getting data from the internal hardware RNG.
- The internal hardware can be used to feed the enthropy pool.
+ The internal hardware can be used to feed the entropy pool.
U2F Zero only supports blinking its LED, so this driver doesn't
allow setting the brightness to anything but 1, which will
--
2.50.0
^ permalink raw reply related
* Re: [PATCH v2] HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
From: Jiri Slaby @ 2025-07-24 7:01 UTC (permalink / raw)
To: Qasim Ijaz, jikos, bentiss
Cc: envelsavinds, linux-input, linux-kernel, stable
In-Reply-To: <20250723110036.24439-1-qasdev00@gmail.com>
On 23. 07. 25, 13:00, Qasim Ijaz wrote:
> A malicious HID device can trigger a slab out-of-bounds during
> mt_report_fixup() by passing in report descriptor smaller than
> 607 bytes. mt_report_fixup() attempts to patch byte offset 607
> of the descriptor with 0x25 by first checking if byte offset
> 607 is 0x15 however it lacks bounds checks to verify if the
> descriptor is big enough before conducting this check. Fix
> this bug by ensuring the descriptor size is at least 608
> bytes before accessing it.
>
> Below is the KASAN splat after the out of bounds access happens:
>
> [ 13.671954] ==================================================================
> [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110
...
> [...]
>
> Fixes: c8000deb6836 ("HID: multitouch: Add support for GT7868Q")
> Cc: stable@vger.kernel.org
> Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
LGTM
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1503,6 +1503,14 @@ static const __u8 *mt_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> if (hdev->vendor == I2C_VENDOR_ID_GOODIX &&
> (hdev->product == I2C_DEVICE_ID_GOODIX_01E8 ||
> hdev->product == I2C_DEVICE_ID_GOODIX_01E9)) {
> + if (*size < 608) {
> + dev_info(
Except I would not add \n to the line above.
> + &hdev->dev,
> + "GT7868Q fixup: report descriptor is only %u bytes, skipping\n",
> + *size);
> + return rdesc;
> + }
> +
> if (rdesc[607] == 0x15) {
> rdesc[607] = 0x25;
> dev_info(
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: fix integer overflow in set_abs()
From: Jiri Slaby @ 2025-07-24 6:58 UTC (permalink / raw)
To: Qasim Ijaz, jikos, bentiss; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <20250723173659.59327-1-qasdev00@gmail.com>
On 23. 07. 25, 19:36, Qasim Ijaz wrote:
> It is possible for a malicious HID device to trigger a signed integer
> overflow (undefined behaviour) in set_abs() in the following expression
> by supplying bogus logical maximum and minimum values:
>
> int fuzz = snratio ? (fmax - fmin) / snratio : 0;
>
> For example, if the logical_maximum is INT_MAX and logical_minimum is -1
> then (fmax - fmin) resolves to INT_MAX + 1, which does not fit in a 32-bit
> signed int, so the subtraction overflows.
The question is if it matters with -fwrapv?
> Fix this by computing the
> difference in a 64 bit context.
>
> Fixes: 5519cab477b6 ("HID: hid-multitouch: support for PixCir-based panels")
> Cc: stable@vger.kernel.org
> Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
> ---
> drivers/hid/hid-multitouch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 22c6314a8843..687638ed6d0f 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -540,7 +540,8 @@ static void set_abs(struct input_dev *input, unsigned int code,
> {
> int fmin = field->logical_minimum;
> int fmax = field->logical_maximum;
> - int fuzz = snratio ? (fmax - fmin) / snratio : 0;
> + s64 diff = (s64)fmax - (s64)fmin;
> + int fuzz = snratio ? (int)div_s64(diff, snratio) : 0;
> input_set_abs_params(input, code, fmin, fmax, fuzz, 0);
> input_abs_set_res(input, code, hidinput_calc_abs_res(field, code));
> }
--
js
suse labs
^ permalink raw reply
* RE: [PATCH V2] Input: synaptics-rmi4- Add a new feature for Forcepad.
From: Marge Yang @ 2025-07-24 3:38 UTC (permalink / raw)
To: Dmitry Torokhov, Marge Yang
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
David Chiu, Derek Cheng, Sam Tsai, Vincent Huang
In-Reply-To: <6sjnlz2zcstrsjgh5qxfmswlvwyjm5wiyz4wtlndprskw2aocr@icqoimso45wd>
Hi Dmitry,
Update the status.
Thanks
Marge Yang
-----Original Message-----
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Sent: Thursday, July 24, 2025 12:30 AM
To: Marge Yang <Marge.Yang@tw.synaptics.com>
Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; David Chiu <David.Chiu@tw.synaptics.com>; Derek Cheng <derek.cheng@tw.synaptics.com>; Sam Tsai <Sam.Tsai@synaptics.com>; Vincent Huang <Vincent.huang@tw.synaptics.com>
Subject: Re: [PATCH V2] Input: synaptics-rmi4- Add a new feature for Forcepad.
CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Marge,
On Wed, Jul 16, 2025 at 03:36:48AM +0000, Marge Yang wrote:
> + f21->sensor_count = fn->fd.query_base_addr & (BIT(0) | BIT(1) |
> + BIT(2) | BIT(3));
We could either use GENMASK or just 0x0f. BIT() is for individual bits.
[Marge 0724]
Thank you for the reminder. We will use this design going forward.
> +
> + if (fn->fd.query_base_addr & BIT(5)) {
> + if (fn->fd.query_base_addr & BIT(6))
> + f21->query15_offset = 2;
> + else
> + f21->query15_offset = 1;
> +
> + rmi_read_block(fn->rmi_dev, fn->fd.query_base_addr + f21->query15_offset,
> + f21->data_regs, 1);
> + f21->max_number_Of_finger = f21->data_regs[0] & 0x0F;
> + } else {
> + dev_info(&fn->dev, "f21_query15 doesn't support.\n");
> + f21->query15_offset = 0;
> + f21->max_number_Of_finger = 5;
> + }
> +
> + if (fn->fd.query_base_addr & BIT(6)) {
Just double-checking - should it be BIT(5) give that reading of number of fingers is gated by BIT(5) in the block above.
[Marge 0724]
Using BIT (6) is more appropriate.
BIT6: Indicates whether the force-calibration version is supported.
The old firmware does not support this feature.
The new firmware can use this BIT to determine whether it's the new or old version.
BIT5: Indicates whether reading the maximum number of finger-pressure levels is supported.
> + dev_info(&fn->dev, "Support new F21 feature.\n");
> + /*Each finger uses one byte, and the button state uses one byte.*/
> + f21->attn_data_size = f21->max_number_Of_finger + 1;
> + f21->attn_data_index_for_button = f21->attn_data_size - 1;
> + /*
> + * Each sensor uses two bytes, the button state uses one byte,
> + * and each finger uses two bytes.
> + */
> + f21->data_reg_size = f21->sensor_count * 2 + 1 +
> + f21->max_number_Of_finger * 2;
> + f21->data_reg_index_for_button = f21->sensor_count * 2;
> + } else {
> + dev_info(&fn->dev, "Support old F21 feature.\n");
> + /*Each finger uses two bytes, and the button state uses one byte.*/
> + f21->attn_data_size = f21->sensor_count * 2 + 1;
> + f21->attn_data_index_for_button = f21->attn_data_size - 1;
> + /*Each finger uses two bytes, and the button state uses one byte.*/
> + f21->data_reg_size = f21->sensor_count * 2 + 1;
> + f21->data_reg_index_for_button = f21->data_reg_size - 1;
The block is duplicated?
[Marge 0724]
Comparing the new and old firmware versions:
Based on BIT6, we can distinguish between the new and old firmware versions.
The definition of the attention data size differs.
The size of the F21 data block and the definition of its button index also differ.
Therefore, by definition, this block is not duplicated.
No need to resubmit the patch, please just provide the answer to the above questions.
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH] HID: Intel-thc-hid: Intel-thc: Use str_true_false() helper
From: Xu, Even @ 2025-07-24 3:07 UTC (permalink / raw)
To: liu.xuemei1@zte.com.cn, jikos@kernel.org, bentiss@kernel.org
Cc: Sun, Xinpeng, srinivas.pandruvada@linux.intel.com,
liu.song13@zte.com.cn, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20250724103626535JRNAc8OZvk4dXKn-b0CVZ@zte.com.cn>
> -----Original Message-----
> From: liu.xuemei1@zte.com.cn <liu.xuemei1@zte.com.cn>
> Sent: Thursday, July 24, 2025 10:36 AM
> To: jikos@kernel.org; bentiss@kernel.org
> Cc: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <xinpeng.sun@intel.com>;
> srinivas.pandruvada@linux.intel.com; liu.song13@zte.com.cn; linux-
> input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] HID: Intel-thc-hid: Intel-thc: Use str_true_false() helper
>
> From: Liu Song <liu.song13@zte.com.cn>
>
> Remove hard-coded strings by using the str_true_false() helper function.
>
> Signed-off-by: Liu Song <liu.song13@zte.com.cn>
> ---
> drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c b/drivers/hid/intel-
> thc-hid/intel-thc/intel-thc-dev.c
> index 6f2263869b20..2b794bb481a0 100644
> --- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c
> +++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c
> @@ -4,6 +4,7 @@
> #include <linux/bitfield.h>
> #include <linux/math.h>
> #include <linux/regmap.h>
> +#include <linux/string_choices.h>
>
> #include "intel-thc-dev.h"
> #include "intel-thc-hw.h"
> @@ -664,7 +665,7 @@ int thc_interrupt_quiesce(const struct thc_device *dev,
> bool int_quiesce)
> if (ret) {
> dev_err_once(dev->dev,
> "Timeout while waiting THC idle, target quiesce state
> = %s\n",
> - int_quiesce ? "true" : "false");
> + str_true_false(int_quiesce));
> return ret;
> }
>
Thanks for the patch! Looks good to me!
Reviewed-by: Even Xu <even.xu@intel.com>
> --
> 2.27.0
^ permalink raw reply
* [PATCH] HID: uclogic: Use str_true_false() helper
From: liu.xuemei1 @ 2025-07-24 2:38 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-input, liu.song13
From: Liu Song <liu.song13@zte.com.cn>
Remove hard-coded strings by using the str_true_false() helper function.
Signed-off-by: Liu Song <liu.song13@zte.com.cn>
---
drivers/hid/hid-uclogic-params.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 4a17f7332c3f..ffa14a4621ef 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -20,6 +20,7 @@
#include <linux/ctype.h>
#include <linux/string.h>
#include <linux/unaligned.h>
+#include <linux/string_choices.h>
/**
* uclogic_params_pen_inrange_to_str() - Convert a pen in-range reporting type
@@ -59,7 +60,7 @@ static void uclogic_params_pen_hid_dbg(const struct hid_device *hdev,
size_t i;
hid_dbg(hdev, "\t.usage_invalid = %s\n",
- (pen->usage_invalid ? "true" : "false"));
+ str_true_false(pen->usage_invalid));
hid_dbg(hdev, "\t.desc_ptr = %p\n", pen->desc_ptr);
hid_dbg(hdev, "\t.desc_size = %u\n", pen->desc_size);
hid_dbg(hdev, "\t.id = %u\n", pen->id);
@@ -74,9 +75,9 @@ static void uclogic_params_pen_hid_dbg(const struct hid_device *hdev,
hid_dbg(hdev, "\t.inrange = %s\n",
uclogic_params_pen_inrange_to_str(pen->inrange));
hid_dbg(hdev, "\t.fragmented_hires = %s\n",
- (pen->fragmented_hires ? "true" : "false"));
+ str_true_false(pen->fragmented_hires));
hid_dbg(hdev, "\t.tilt_y_flipped = %s\n",
- (pen->tilt_y_flipped ? "true" : "false"));
+ str_true_false(pen->tilt_y_flipped));
}
/**
@@ -119,8 +120,7 @@ void uclogic_params_hid_dbg(const struct hid_device *hdev,
{
size_t i;
- hid_dbg(hdev, ".invalid = %s\n",
- params->invalid ? "true" : "false");
+ hid_dbg(hdev, ".invalid = %s\n", str_true_false(params->invalid));
hid_dbg(hdev, ".desc_ptr = %p\n", params->desc_ptr);
hid_dbg(hdev, ".desc_size = %u\n", params->desc_size);
hid_dbg(hdev, ".pen = {\n");
--
2.27.0
^ permalink raw reply related
* [PATCH] HID: Intel-thc-hid: Intel-thc: Use str_true_false() helper
From: liu.xuemei1 @ 2025-07-24 2:36 UTC (permalink / raw)
To: jikos, bentiss
Cc: even.xu, xinpeng.sun, srinivas.pandruvada, liu.song13,
linux-input, linux-kernel
From: Liu Song <liu.song13@zte.com.cn>
Remove hard-coded strings by using the str_true_false() helper function.
Signed-off-by: Liu Song <liu.song13@zte.com.cn>
---
drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c
index 6f2263869b20..2b794bb481a0 100644
--- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c
+++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c
@@ -4,6 +4,7 @@
#include <linux/bitfield.h>
#include <linux/math.h>
#include <linux/regmap.h>
+#include <linux/string_choices.h>
#include "intel-thc-dev.h"
#include "intel-thc-hw.h"
@@ -664,7 +665,7 @@ int thc_interrupt_quiesce(const struct thc_device *dev, bool int_quiesce)
if (ret) {
dev_err_once(dev->dev,
"Timeout while waiting THC idle, target quiesce state = %s\n",
- int_quiesce ? "true" : "false");
+ str_true_false(int_quiesce));
return ret;
}
--
2.27.0
^ permalink raw reply related
page: next (older) | 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