* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2026-04-01 16:22 UTC (permalink / raw)
To: Werner Sembach; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <11135d8c-ef30-410a-a94a-4e11e062c27b@tuxedocomputers.com>
Hi Werner,
On Wed, Apr 01, 2026 at 05:48:20PM +0200, Werner Sembach wrote:
> Hello Dmitry
>
> Am 23.02.26 um 22:54 schrieb Dmitry Torokhov:
> > On Mon, Feb 23, 2026 at 03:20:45PM +0100, Werner Sembach wrote:
> > > From: Christoffer Sandberg <cs@tuxedo.de>
> > >
> > > The device occasionally wakes up from suspend with missing input on the
> > > internal keyboard and the following suspend attempt results in an instant
> > > wake-up. The quirks fix both issues for this device.
> > >
> > > Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> > > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > Applied, thank you.
> >
> May i ask you where it was applied?
>
> I can only find the former patch https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?id=aed3716db7fff74919cc5775ca3a80c8bb246489
> for the InfinityBook Max 15 and not this one for the InfinityBook Max 16
> (both patches have a nearly identical subject line).
Isn't it this:
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=5839419cffc7788a356428d321e3ec18055c0286
?
>
> Also I forgot to add cc stable, if the patch is not yet applied, can you add
> it before?
I added the tags to the commit above (unless it is not the right one,
they all look very similar).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Dmitry Torokhov @ 2026-04-01 16:11 UTC (permalink / raw)
To: Luca Weiss
Cc: Griffin Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <DHHWDE7QEOTO.1AQ85UBLO8IQG@fairphone.com>
On Wed, Apr 01, 2026 at 04:44:47PM +0200, Luca Weiss wrote:
> Hi Dmitry,
>
> On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
> > On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
> >> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
> >>
> >> The AW86938 has a similar but slightly different register layout. In
> >> particular, the boost mode register values.
> >> The AW86938 also has some extra features that aren't implemented
> >> in this driver yet.
> >>
> >> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
> >
> > Applied, thank you.
>
> I'm curious, where did you apply these patches? linux-next doesn't have
> it and I don't see it in your kernel.org repo either.
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
>
> Did this slip through the cracks or will these patches still appear
> there?
My bad, I think there was a conflict with Dan Carpenter's patch and as a
result the series got stuck in my internal queue. My apologies.
Should be out in 'next' branch now.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Werner Sembach @ 2026-04-01 15:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <aZzMe2-4IqzIg3HS@google.com>
Hello Dmitry
Am 23.02.26 um 22:54 schrieb Dmitry Torokhov:
> On Mon, Feb 23, 2026 at 03:20:45PM +0100, Werner Sembach wrote:
>> From: Christoffer Sandberg <cs@tuxedo.de>
>>
>> The device occasionally wakes up from suspend with missing input on the
>> internal keyboard and the following suspend attempt results in an instant
>> wake-up. The quirks fix both issues for this device.
>>
>> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Applied, thank you.
>
May i ask you where it was applied?
I can only find the former patch
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?id=aed3716db7fff74919cc5775ca3a80c8bb246489
for the InfinityBook Max 15 and not this one for the InfinityBook Max 16 (both
patches have a nearly identical subject line).
Also I forgot to add cc stable, if the patch is not yet applied, can you add it
before?
Best regards,
Werner
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: fix race condition when accessing stale stack pointer
From: Benoit Sevens @ 2026-04-01 14:48 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
Benoît Sevens
From: Benoît Sevens <bsevens@google.com>
The driver uses hidpp->send_receive_buf to point to a stack-allocated
buffer in the synchronous command path (__do_hidpp_send_message_sync).
However, this pointer is not cleared when the function returns.
If an event is processed (e.g. by a different thread) while the
send_mutex is held by a new command, but before that command has
updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
observe that the mutex is locked and dereference the stale pointer.
This results in an out-of-bounds access on a different thread's kernel
stack (or a NULL pointer dereference on the very first command).
Fix this by:
1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
in the synchronous command path.
2. Moving the assignment of the local 'question' and 'answer' pointers
inside the mutex_is_locked() block in the handler, and adding
a NULL check before dereferencing.
Signed-off-by: Benoît Sevens <bsevens@google.com>
---
drivers/hid/hid-logitech-hidpp.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index e871f1729d4b..42f7ea5b25dc 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -306,21 +306,22 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
if (ret) {
dbg_hid("__hidpp_send_report returned err: %d\n", ret);
memset(response, 0, sizeof(struct hidpp_report));
- return ret;
+ goto out;
}
if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
5*HZ)) {
dbg_hid("%s:timeout waiting for response\n", __func__);
memset(response, 0, sizeof(struct hidpp_report));
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
response->rap.sub_id == HIDPP_ERROR) {
ret = response->rap.params[1];
dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
if ((response->report_id == REPORT_ID_HIDPP_LONG ||
@@ -328,10 +329,14 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+
+out:
+ hidpp->send_receive_buf = NULL;
+ return ret;
}
/*
@@ -3840,8 +3845,7 @@ static int hidpp_input_configured(struct hid_device *hdev,
static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
int size)
{
- struct hidpp_report *question = hidpp->send_receive_buf;
- struct hidpp_report *answer = hidpp->send_receive_buf;
+ struct hidpp_report *question, *answer;
struct hidpp_report *report = (struct hidpp_report *)data;
int ret;
int last_online;
@@ -3851,6 +3855,12 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
* previously sent command.
*/
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
+ question = hidpp->send_receive_buf;
+ answer = hidpp->send_receive_buf;
+
+ if (!question)
+ return 0;
+
/*
* Check for a correct hidpp20 answer or the corresponding
* error
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Luca Weiss @ 2026-04-01 14:44 UTC (permalink / raw)
To: Dmitry Torokhov, Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <aae7fRYaoDHMptyu@google.com>
Hi Dmitry,
On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
> On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
>> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
>>
>> The AW86938 has a similar but slightly different register layout. In
>> particular, the boost mode register values.
>> The AW86938 also has some extra features that aren't implemented
>> in this driver yet.
>>
>> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
>
> Applied, thank you.
I'm curious, where did you apply these patches? linux-next doesn't have
it and I don't see it in your kernel.org repo either.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
Did this slip through the cracks or will these patches still appear
there?
Regards
Luca
^ permalink raw reply
* [syzbot] [input?] [usb?] KASAN: slab-use-after-free Read in hiddev_disconnect (4)
From: syzbot @ 2026-04-01 9:33 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 46b513250491 Merge tag 'v7.0-rc5-smb3-client-fix' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=177c11da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=5a3e5e8c17cc174e
dashboard link: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-46b51325.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/22fdb6baf246/vmlinux-46b51325.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a3a69d9008ed/bzImage-46b51325.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
usb 6-1: USB disconnect, device number 25
==================================================================
BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x23b/0x260 kernel/locking/spinlock_debug.c:115
Read of size 4 at addr ffff8880289f981c by task kworker/1:3/6000
CPU: 1 UID: 0 PID: 6000 Comm: kworker/1:3 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x156/0x4c9 mm/kasan/report.c:482
kasan_report+0xdf/0x1e0 mm/kasan/report.c:595
debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
do_raw_spin_lock+0x23b/0x260 kernel/locking/spinlock_debug.c:115
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock_irqsave+0x42/0x60 kernel/locking/spinlock.c:162
__mutex_unlock_slowpath+0x18b/0x790 kernel/locking/mutex.c:963
hiddev_disconnect+0x15b/0x1d0 drivers/hid/usbhid/hiddev.c:940
hid_disconnect+0xbe/0x1b0 drivers/hid/hid-core.c:2353
hid_hw_stop drivers/hid/hid-core.c:2400 [inline]
hid_device_remove+0x1b2/0x270 drivers/hid/hid-core.c:2834
device_remove+0xcb/0x180 drivers/base/dd.c:631
__device_release_driver drivers/base/dd.c:1344 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1367
bus_remove_device+0x2bc/0x560 drivers/base/bus.c:657
device_del+0x376/0x9b0 drivers/base/core.c:3880
hid_remove_device drivers/hid/hid-core.c:3009 [inline]
hid_destroy_device+0x19c/0x240 drivers/hid/hid-core.c:3031
usbhid_disconnect+0xa0/0xe0 drivers/hid/usbhid/hid-core.c:1477
usb_unbind_interface+0x1dd/0x9e0 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:633 [inline]
device_remove+0x12a/0x180 drivers/base/dd.c:625
__device_release_driver drivers/base/dd.c:1344 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1367
bus_remove_device+0x2bc/0x560 drivers/base/bus.c:657
device_del+0x376/0x9b0 drivers/base/core.c:3880
usb_disable_device+0x367/0x810 drivers/usb/core/message.c:1476
usb_disconnect+0x2e2/0x9a0 drivers/usb/core/hub.c:2345
hub_port_connect drivers/usb/core/hub.c:5407 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x1d0c/0x4af0 drivers/usb/core/hub.c:5953
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 24:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
hiddev_connect+0x259/0x5d0 drivers/hid/usbhid/hiddev.c:893
hid_connect+0x241/0x1750 drivers/hid/hid-core.c:2267
hid_hw_start+0xaa/0x140 drivers/hid/hid-core.c:2380
plantronics_probe+0x2b9/0x3a0 drivers/hid/hid-plantronics.c:209
__hid_device_probe drivers/hid/hid-core.c:2776 [inline]
hid_device_probe+0x50e/0x800 drivers/hid/hid-core.c:2813
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:2952
usbhid_probe+0xd57/0x1350 drivers/hid/usbhid/hid-core.c:1450
usb_probe_interface+0x303/0x8f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_set_configuration+0xd97/0x1c60 drivers/usb/core/message.c:2266
usb_generic_driver_probe+0xa1/0xe0 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x400 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_new_device.cold+0x685/0x115c drivers/usb/core/hub.c:2695
hub_port_connect drivers/usb/core/hub.c:5567 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x314d/0x4af0 drivers/usb/core/hub.c:5953
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 11803:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kfree+0x1f6/0x6b0 mm/slub.c:6483
hiddev_release+0x40d/0x520 drivers/hid/usbhid/hiddev.c:232
__fput+0x3ff/0xb40 fs/file_table.c:469
task_work_run+0x150/0x240 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x100/0x4a0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x67c/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8880289f9800
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 28 bytes inside of
freed 512-byte region [ffff8880289f9800, ffff8880289f9a00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8880289f8c00 pfn:0x289f8
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000240(workingset|head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000240 ffff88801b842c80 ffffea0000b3f710 ffffea00015f9410
raw: ffff8880289f8c00 0000000800100008 00000000f5000000 0000000000000000
head: 00fff00000000240 ffff88801b842c80 ffffea0000b3f710 ffffea00015f9410
head: ffff8880289f8c00 0000000800100008 00000000f5000000 0000000000000000
head: 00fff00000000002 ffffea0000a27e01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 10245, tgid 10245 (udevd), ts 189371739713, free_ts 189294134261
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab mm/slub.c:3481 [inline]
new_slab+0xa6/0x6b0 mm/slub.c:3539
refill_objects+0x26b/0x400 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1ab/0x660 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__kmalloc_cache_noprof+0x493/0x6f0 mm/slub.c:5375
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
kernfs_fop_open+0x23d/0xd50 fs/kernfs/file.c:641
do_dentry_open+0x6d8/0x1660 fs/open.c:949
vfs_open+0x82/0x3f0 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x208c/0x31a0 fs/namei.c:4830
do_file_open+0x20e/0x430 fs/namei.c:4859
do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 11125 tgid 11125 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0x7e1/0x10d0 mm/page_alloc.c:2978
stack_depot_save_flags+0x435/0x9d0 lib/stackdepot.c:735
kasan_save_stack+0x3f/0x50 mm/kasan/common.c:58
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
ida_alloc_range+0x464/0x830 lib/idr.c:420
ida_alloc include/linux/idr.h:293 [inline]
create_worker+0x99/0x750 kernel/workqueue.c:2796
maybe_create_worker kernel/workqueue.c:3075 [inline]
manage_workers kernel/workqueue.c:3152 [inline]
worker_thread+0x8e2/0xe50 kernel/workqueue.c:3415
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff8880289f9700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880289f9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8880289f9800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880289f9880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880289f9900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH v2] Input: usbtouchscreen - refactor endpoint lookup
From: Johan Hovold @ 2026-04-01 8:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
Use the common USB helpers for looking up bulk and interrupt endpoints
(and determining endpoint numbers) instead of open coding.
Note that the NEXIO data interface has two bulk endpoints (see commit
5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support")
for the descriptors).
The lookup in probe handles both bulk-in and interrupt-in endpoints and
was added to handle NEXIO devices. Replace the open coded lookup with a
lookup for the common interrupt endpoint and an explicit fallback
accepting a bulk endpoint.
This iterates over the (two) endpoints twice for NEXIO devices but makes
it more clear what is going on.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
Changes in v2
- add the missing fallback to handle bulk endpoints to probe
- amend commit message
drivers/input/touchscreen/usbtouchscreen.c | 43 ++++++++--------------
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 657555c8796c..daa28135f887 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -969,24 +969,21 @@ static int nexio_init(struct usbtouch_usb *usbtouch)
{
struct usb_device *dev = interface_to_usbdev(usbtouch->interface);
struct usb_host_interface *interface = usbtouch->interface->cur_altsetting;
+ struct usb_endpoint_descriptor *ep_in, *ep_out;
struct nexio_priv *priv = usbtouch->priv;
- int ret = -ENOMEM;
int actual_len, i;
char *firmware_ver = NULL, *device_name = NULL;
- int input_ep = 0, output_ep = 0;
+ int input_ep, output_ep;
+ int ret;
/* find first input and output endpoint */
- for (i = 0; i < interface->desc.bNumEndpoints; i++) {
- if (!input_ep &&
- usb_endpoint_dir_in(&interface->endpoint[i].desc))
- input_ep = interface->endpoint[i].desc.bEndpointAddress;
- if (!output_ep &&
- usb_endpoint_dir_out(&interface->endpoint[i].desc))
- output_ep = interface->endpoint[i].desc.bEndpointAddress;
- }
- if (!input_ep || !output_ep)
+ ret = usb_find_common_endpoints(interface, &ep_in, &ep_out, NULL, NULL);
+ if (ret)
return -ENXIO;
+ input_ep = usb_endpoint_num(ep_in);
+ output_ep = usb_endpoint_num(ep_out);
+
u8 *buf __free(kfree) = kmalloc(NEXIO_BUFSIZE, GFP_NOIO);
if (!buf)
return -ENOMEM;
@@ -1427,18 +1424,6 @@ static void usbtouch_free_buffers(struct usb_device *udev,
kfree(usbtouch->buffer);
}
-static struct usb_endpoint_descriptor *
-usbtouch_get_input_endpoint(struct usb_host_interface *interface)
-{
- int i;
-
- for (i = 0; i < interface->desc.bNumEndpoints; i++)
- if (usb_endpoint_dir_in(&interface->endpoint[i].desc))
- return &interface->endpoint[i].desc;
-
- return NULL;
-}
-
static int usbtouch_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1447,17 +1432,21 @@ static int usbtouch_probe(struct usb_interface *intf,
struct usb_endpoint_descriptor *endpoint;
struct usb_device *udev = interface_to_usbdev(intf);
const struct usbtouch_device_info *type;
- int err = -ENOMEM;
+ int err;
/* some devices are ignored */
type = (const struct usbtouch_device_info *)id->driver_info;
if (!type)
return -ENODEV;
- endpoint = usbtouch_get_input_endpoint(intf->cur_altsetting);
- if (!endpoint)
- return -ENXIO;
+ err = usb_find_int_in_endpoint(intf->cur_altsetting, &endpoint);
+ if (err) {
+ err = usb_find_bulk_in_endpoint(intf->cur_altsetting, &endpoint);
+ if (err)
+ return -ENXIO;
+ }
+ err = -ENOMEM;
usbtouch = kzalloc_obj(*usbtouch);
input_dev = input_allocate_device();
if (!usbtouch || !input_dev)
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Johan Hovold @ 2026-04-01 7:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <acwskOMBhv9yWkD7@google.com>
On Tue, Mar 31, 2026 at 01:21:05PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 04:55:35PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> > > Use the common USB helpers for looking up bulk and interrupt endpoints
> > > instead of open coding.
> >
> > Applied the lot, thank you.
>
> Actually, dropped patch #4:
>
> https://sashiko.dev/#/patchset/20260330095948.1663141-1-johan%40kernel.org
Thanks, I saw this one last night as well (after reading the LWN
article).
I'll send a v2.
Johan
^ permalink raw reply
* [PATCH] HID: core: do not allow parsing 0-sized reports
From: Dmitry Torokhov @ 2026-04-01 6:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Peter Hutterer, Kees Cook, Alan Stern,
Charles Keepax, linux-input, linux-kernel
Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
reworked collection parsing code and inadvertently allowed returning
"success" when parsing 0-sized reports where old code returned -EINVAL.
Restore the original behavior by doing an explicit check.
Note that the error message now differs from the generic "item fetching
failed at offset %u/%u" that is now used only for non-empty descriptors.
Fixes: d7db259bd6df ("HID: core: factor out hid_parse_collections()")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b40953e0f52e..be9d2b3356c3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1272,6 +1272,11 @@ static int hid_parse_collections(struct hid_device *device)
device->collection[i].parent_idx = -1;
ret = -EINVAL;
+ if (start == end) {
+ hid_err(device, "rejecting 0-sized report descriptor\n");
+ goto out;
+ }
+
while ((next = fetch_item(start, end, &item)) != NULL) {
start = next;
--
2.53.0.1185.g05d4b7b318-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH 0/3] snvs_pwrkey - code improvements and add report event
From: Dmitry Torokhov @ 2026-04-01 4:50 UTC (permalink / raw)
To: Joy Zou
Cc: Frank Li, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260326-pwrkey-cleanup-v1-0-d85d7c0bf275@nxp.com>
On Thu, Mar 26, 2026 at 06:39:37PM +0800, Joy Zou wrote:
> This patch series improves the snvs_pwrkey driver with better code quality
> and add report press event.
>
> The main improvements include:
> 1. Clean up the code by using local device pointers and dev_err_probe() for
> better readability and easier debugging.
>
> 2. Fix potential event loss during system suspend by reporting key press events
> directly in the interrupt handler.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Please address comments form here:
https://sashiko.dev/#/patchset/20260326-pwrkey-cleanup-v1-0-d85d7c0bf275%40nxp.com
Majority of them seem valid.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-04-01 1:21 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Louis-Alexis Eyraud, Gary Bisson, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010924.UuETwSKZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: unused variable 'ldo_volt_table1b' [-Wunused-const-variable]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
1 warning generated.
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-31 20:21 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <acsNayeGbU6cRw3P@google.com>
On Mon, Mar 30, 2026 at 04:55:35PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> > Use the common USB helpers for looking up bulk and interrupt endpoints
> > instead of open coding.
>
> Applied the lot, thank you.
Actually, dropped patch #4:
https://sashiko.dev/#/patchset/20260330095948.1663141-1-johan%40kernel.org
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: oe-kbuild-all, Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Louis-Alexis Eyraud,
Gary Bisson, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010103.FzAGRPye-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: 'ldo_volt_table1b' defined but not used [-Wunused-const-variable=]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: kernel test robot @ 2026-03-31 16:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-6-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-6-l.scorcia%40gmail.com
patch subject: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
config: s390-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603312339.CMJpqhEq-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/mt6397-core.c:421:16: warning: cast to smaller integer type 'enum mfd_match_data' from 'const void *' [-Wvoid-pointer-to-enum-cast]
421 | device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +421 drivers/mfd/mt6397-core.c
398
399 static int mt6397_probe(struct platform_device *pdev)
400 {
401 int ret;
402 unsigned int id = 0;
403 struct mt6397_chip *pmic;
404 const struct chip_data *pmic_core;
405 enum mfd_match_data device_data;
406
407 pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
408 if (!pmic)
409 return -ENOMEM;
410
411 pmic->dev = &pdev->dev;
412
413 /*
414 * mt6397 MFD is child device of soc pmic wrapper.
415 * Regmap is set from its parent.
416 */
417 pmic->regmap = dev_get_regmap(pdev->dev.parent, NULL);
418 if (!pmic->regmap)
419 return -ENODEV;
420
> 421 device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
422 switch (device_data) {
423 case MATCH_DATA_MT6323:
424 pmic_core = &mt6323_core;
425 break;
426 case MATCH_DATA_MT6328:
427 pmic_core = &mt6328_core;
428 break;
429 case MATCH_DATA_MT6331:
430 pmic_core = &mt6331_mt6332_core;
431 break;
432 case MATCH_DATA_MT6357:
433 pmic_core = &mt6357_core;
434 break;
435 case MATCH_DATA_MT6358:
436 pmic_core = &mt6358_core;
437 break;
438 case MATCH_DATA_MT6359:
439 pmic_core = &mt6359_core;
440 break;
441 case MATCH_DATA_MT6392:
442 pmic_core = &mt6392_core;
443 break;
444 case MATCH_DATA_MT6397:
445 pmic_core = &mt6397_core;
446 break;
447 default:
448 dev_err(&pdev->dev, "Unknown device match data %u\n", device_data);
449 return -ENODEV;
450 }
451
452 ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
453 if (ret) {
454 dev_err(&pdev->dev, "Failed to read chip id: %d\n", ret);
455 return ret;
456 }
457
458 pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
459
460 platform_set_drvdata(pdev, pmic);
461
462 pmic->irq = platform_get_irq(pdev, 0);
463 if (pmic->irq <= 0)
464 return pmic->irq;
465
466 ret = pmic_core->irq_init(pmic);
467 if (ret)
468 return ret;
469
470 ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
471 pmic_core->cells, pmic_core->cell_size,
472 NULL, 0, pmic->irq_domain);
473 if (ret) {
474 irq_domain_remove(pmic->irq_domain);
475 dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
476 }
477
478 return ret;
479 }
480
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e
From: kernel test robot @ 2026-03-31 14:31 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: 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e Input: usbtouchscreen - refactor endpoint lookup
elapsed time: 844m
configs tested: 179
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-002-20260331 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-002-20260331 clang-23
arm randconfig-003-20260331 clang-23
arm randconfig-004-20260331 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-004-20260331 clang-18
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260331 clang-18
csky randconfig-002-20260331 clang-18
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260331 gcc-14
i386 randconfig-002-20260331 gcc-14
i386 randconfig-003-20260331 gcc-14
i386 randconfig-004-20260331 gcc-14
i386 randconfig-005-20260331 gcc-14
i386 randconfig-006-20260331 gcc-14
i386 randconfig-007-20260331 gcc-14
i386 randconfig-011-20260331 clang-20
i386 randconfig-012-20260331 clang-20
i386 randconfig-013-20260331 clang-20
i386 randconfig-014-20260331 clang-20
i386 randconfig-015-20260331 clang-20
i386 randconfig-016-20260331 clang-20
i386 randconfig-017-20260331 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip32_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-002-20260331 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc pcm030_defconfig clang-23
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-002-20260331 clang-23
powerpc64 alldefconfig clang-23
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-002-20260331 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-002-20260331 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-002-20260331 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-002-20260331 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-002-20260331 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-002-20260331 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-002-20260331 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-076-20260331 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-002-20260331 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Frank Li @ 2026-03-31 14:11 UTC (permalink / raw)
To: Joy Zou
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260331104655.GA1415371@shlinux88>
On Tue, Mar 31, 2026 at 06:46:55PM +0800, Joy Zou wrote:
> On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> > On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > > 200ms to restore the PCIe link during the no_irq resume phase. This
> > > causes key press events to be lost because the key may be released
> > > before the timer starts running, as interrupts are disabled during
> > > this 200ms window.
> >
> > if irq disable, how imx_snvs_pwrkey_interrupt get run?
> >
> Thank you for your comments. I might have missed some details in my commit
> message. Could you please review the description below and let me know if
> it's clear and comprehensive enough?
>
> The driver implements debounce protection using a timer-based mechanism:
> when a key interrupt occurs, a timer is scheduled to verify the key state
> after DEBOUNCE_TIME before reporting the event. This works well during
> normal operation.
>
> However, key press events can be lost during system resume on platforms
> like i.MX8MQ-EVK because:
> 1. During the no_irq resume phase, PCIe driver restoration can take up to
> 200ms with IRQs disabled.
> 2. The power key interrupt remains pending during the no_irq phase.
> 3. If the key is released before IRQs are re-enabled, the timer eventually
> runs but sees the key as released and skips reporting the event.
>
> Report key press events directly in interrupt handler to prevent event
> loss during system suspend. This is safe because:
>
> 1. Only one event is reported per suspend cycle.
> 2. Normal operation retains the existing timer-based debounce mechanism.
much better. Thanks
Frank
> BR
> Joy Zou
> > Frank
> > >
> > > Report key press events directly in interrupt handler to prevent event
> > > loss during system suspend.
> > >
> > > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > > ---
> > > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> > >
> > > pm_wakeup_event(input->dev.parent, 0);
> > >
> > > + /*
> > > + * Report key press events directly in interrupt handler to prevent event
> > > + * loss during system suspend.
> > > + */
> > > + if (pdev->dev.power.is_suspended) {
> > > + pdata->keystate = 1;
> > > + input_report_key(input, pdata->keycode, 1);
> > > + input_sync(input);
> > > + }
> > > +
> > > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > > if (lp_status & SNVS_LPSR_SPO) {
> > > if (pdata->minor_rev == 0) {
> > >
> > > --
> > > 2.37.1
> > >
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Joy Zou @ 2026-03-31 10:46 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <acWPp7KHxv9a5Az6@lizhi-Precision-Tower-5810>
On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > 200ms to restore the PCIe link during the no_irq resume phase. This
> > causes key press events to be lost because the key may be released
> > before the timer starts running, as interrupts are disabled during
> > this 200ms window.
>
> if irq disable, how imx_snvs_pwrkey_interrupt get run?
>
Thank you for your comments. I might have missed some details in my commit
message. Could you please review the description below and let me know if
it's clear and comprehensive enough?
The driver implements debounce protection using a timer-based mechanism:
when a key interrupt occurs, a timer is scheduled to verify the key state
after DEBOUNCE_TIME before reporting the event. This works well during
normal operation.
However, key press events can be lost during system resume on platforms
like i.MX8MQ-EVK because:
1. During the no_irq resume phase, PCIe driver restoration can take up to
200ms with IRQs disabled.
2. The power key interrupt remains pending during the no_irq phase.
3. If the key is released before IRQs are re-enabled, the timer eventually
runs but sees the key as released and skips reporting the event.
Report key press events directly in interrupt handler to prevent event
loss during system suspend. This is safe because:
1. Only one event is reported per suspend cycle.
2. Normal operation retains the existing timer-based debounce mechanism.
BR
Joy Zou
> Frank
> >
> > Report key press events directly in interrupt handler to prevent event
> > loss during system suspend.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > ---
> > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> >
> > pm_wakeup_event(input->dev.parent, 0);
> >
> > + /*
> > + * Report key press events directly in interrupt handler to prevent event
> > + * loss during system suspend.
> > + */
> > + if (pdev->dev.power.is_suspended) {
> > + pdata->keystate = 1;
> > + input_report_key(input, pdata->keycode, 1);
> > + input_sync(input);
> > + }
> > +
> > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > if (lp_status & SNVS_LPSR_SPO) {
> > if (pdata->minor_rev == 0) {
> >
> > --
> > 2.37.1
> >
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-03-31 8:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260331-flawless-bronze-lorikeet-59a6ff@quoll>
> > - required:
> > - - compatible
>
> Not really, this affects existing ABI and might make the child schema
> being applied. Basically regulators node can be anything now.
>
> This is definitely not a binding we want. The syntax for parent schema
> when listing only compatibles is requiring this compatible. You cannot
> have here whatever empty node.
Hi, it felt quite strange to me too, but that's what I thought you
meant with your previous suggestion [1].
To keep the required attribute I would be happy to reintroduce the
compatible here, in the regulator schema and the pmic dtsi.
Before I do that and resubmit, could you please help me understand
what you meant before?
Thank you!
[1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Lee Jones @ 2026-03-31 7:58 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260331074052.194064-1-gnoack@google.com>
On Tue, 31 Mar 2026, Günther Noack wrote:
> Without this bounds check, this might otherwise overwrite index -1.
>
> Triggering this condition requires action both from the USB device and from
> userspace, which reduces the scenarios in which it can be exploited.
>
> Cc: Lee Jones <lee@kernel.org>
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index d1dea7297712..5f63f1d2303a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
> }
> break;
> case HIDPP_FF_DESTROY_EFFECT:
> - if (wd->effect_id >= 0)
> - /* regular effect destroyed */
> - data->effect_ids[wd->params[0]-1] = -1;
> - else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> - /* autocenter spring destroyed */
> - data->slot_autocenter = 0;
> + slot = wd->params[0];
> + if (slot > 0 && slot <= data->num_effects) {
> + if (wd->effect_id >= 0)
> + /* regular effect destroyed */
> + data->effect_ids[slot-1] = -1;
> + else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> + /* autocenter spring destroyed */
> + data->slot_autocenter = 0;
> + }
LGTM.
Reviewed-by: Lee Jones <lee@kernel.org>
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Günther Noack @ 2026-03-31 7:40 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires
Cc: Günther Noack, Lee Jones, linux-input, linux-kernel
Without this bounds check, this might otherwise overwrite index -1.
Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.
Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712..5f63f1d2303a 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
}
break;
case HIDPP_FF_DESTROY_EFFECT:
- if (wd->effect_id >= 0)
- /* regular effect destroyed */
- data->effect_ids[wd->params[0]-1] = -1;
- else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
- /* autocenter spring destroyed */
- data->slot_autocenter = 0;
+ slot = wd->params[0];
+ if (slot > 0 && slot <= data->num_effects) {
+ if (wd->effect_id >= 0)
+ /* regular effect destroyed */
+ data->effect_ids[slot-1] = -1;
+ else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+ /* autocenter spring destroyed */
+ data->slot_autocenter = 0;
+ }
break;
case HIDPP_FF_SET_GLOBAL_GAINS:
data->gain = (wd->params[0] << 8) + wd->params[1];
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Thorsten Leemhuis @ 2026-03-31 6:25 UTC (permalink / raw)
To: honjow, Jiri Kosina, Benjamin Tissoires
Cc: denis.benato, linux-kernel, linux-input,
Linux kernel regressions list
In-Reply-To: <20260324013847.68024-1-honjow311@gmail.com>
On 3/24/26 02:38, honjow wrote:
> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
> Feature reports for Report ID 1, but the firmware only transfers 11 data
> bytes per interrupt.
>
> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), the HID core rejects undersized reports instead of zero-
> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>
> Fix it by patching the report descriptor in report_fixup(), reducing
> Report Count from 63 to 11 for both Input and Feature.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
> Signed-off-by: honjow <honjow311@gmail.com>
> ---
> drivers/hid/Kconfig | 10 +++++++++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-gpd.c | 52 +++++++++++++++++++++++++++++++++++++++++++
> drivers/hid/hid-ids.h | 3 +++
> 4 files changed, 66 insertions(+)
> create mode 100644 drivers/hid/hid-gpd.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 10c12d8e65579..20c60f5aca4c5 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -419,6 +419,16 @@ config HID_GLORIOUS
> Support for Glorious PC Gaming Race mice such as
> the Glorious Model O, O- and D.
>
> +config HID_GPD
> + tristate "GPD Win handheld OEM HID support"
Hmmm, why does this need to be a config option? Can't this be enabled
unconditionally? I ask in general, as it's just another point where
things can go wrong. But I mainly ask because it's a regression fix –
and from my understanding wrt to what Linus wants we don't expect users
to turn some .config on to keep their hardware running (unless it can't
be avoided at all costs).
Ciao, Thorsten
> + depends on USB_HID
> + help
> + Report descriptor fix for the OEM USB HID interface (GameSir
> + 2f24:0137) found on GPD Win handhelds. The firmware declares 63-byte
> + reports but only sends 11 bytes, which the HID core rejects.
> +
> + Say Y or M here if you use a GPD Win handheld with this interface.
> +
> config HID_HOLTEK
> tristate "Holtek HID devices"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 07dfdb6a49c59..03ef72ec4499f 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> +obj-$(CONFIG_HID_GPD) += hid-gpd.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
> new file mode 100644
> index 0000000000000..5b4d203e24995
> --- /dev/null
> +++ b/drivers/hid/hid-gpd.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * HID report descriptor fixup for GPD Win handhelds.
> + *
> + * The OEM HID interface (VID 2f24 / GameSir, PID 0137) declares Report ID 1
> + * with Report Count 63 (8-bit fields) for both Input and Feature, but the
> + * firmware only sends 11 bytes of payload after the report ID.
> + */
> +
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +
> +#include "hid-ids.h"
> +
> +#define RDESC_LEN 38
> +#define RPT_COUNT_INPUT_OFF 21
> +#define RPT_COUNT_FEATURE_OFF 34
> +
> +static const __u8 *gpd_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> + unsigned int *rsize)
> +{
> + if (*rsize != RDESC_LEN)
> + return rdesc;
> +
> + if (rdesc[RPT_COUNT_INPUT_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_INPUT_OFF] == 0x3f &&
> + rdesc[RPT_COUNT_FEATURE_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_FEATURE_OFF] == 0x3f) {
> + hid_info(hdev, "fixing report counts (63 -> 11 bytes)\n");
> + rdesc[RPT_COUNT_INPUT_OFF] = 11;
> + rdesc[RPT_COUNT_FEATURE_OFF] = 11;
> + }
> +
> + return rdesc;
> +}
> +
> +static const struct hid_device_id gpd_devices[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, gpd_devices);
> +
> +static struct hid_driver gpd_driver = {
> + .name = "gpd",
> + .id_table = gpd_devices,
> + .report_fixup = gpd_report_fixup,
> +};
> +
> +module_hid_driver(gpd_driver);
> +
> +MODULE_DESCRIPTION("HID report descriptor fix for GPD Win handheld (GameSir 2f24:0137)");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 933b7943bdb50..d0a6c19baa660 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -533,6 +533,9 @@
> #define USB_VENDOR_ID_FRUCTEL 0x25B6
> #define USB_DEVICE_ID_GAMETEL_MT_MODE 0x0002
>
> +#define USB_VENDOR_ID_GAMESIR 0x2f24
> +#define USB_DEVICE_ID_GAMESIR_0137 0x0137
> +
> #define USB_VENDOR_ID_GAMEVICE 0x27F8
> #define USB_DEVICE_ID_GAMEVICE_GV186 0x0BBE
> #define USB_DEVICE_ID_GAMEVICE_KISHI 0x0BBF
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-30 23:55 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> Use the common USB helpers for looking up bulk and interrupt endpoints
> instead of open coding.
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
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