* [syzbot] [input?] KASAN: slab-use-after-free Read in str_to_user (2)
From: syzbot @ 2026-07-06 1:19 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: dc59e4fea9d8 Linux 7.2-rc1
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=105fb11c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6ec4d592e55f7960
dashboard link: https://syzkaller.appspot.com/bug?extid=aec1962419768c5caf88
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: https://storage.googleapis.com/syzbot-assets/23fd2bbd359c/disk-dc59e4fe.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8ffcad9a17ea/vmlinux-dc59e4fe.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1c2fcc6db866/bzImage-dc59e4fe.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+aec1962419768c5caf88@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in strlen+0x85/0xa0 lib/string.c:402
Read of size 1 at addr ffff888112fec220 by task syz.3.1096/9318
CPU: 1 UID: 0 PID: 9318 Comm: syz.3.1096 Not tainted syzkaller #0 PREEMPT(lazy)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026
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+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
strlen+0x85/0xa0 lib/string.c:402
__fortify_strlen include/linux/fortify-string.h:218 [inline]
str_to_user+0x26/0xa0 drivers/input/evdev.c:769
evdev_do_ioctl+0x1529/0x1b60 drivers/input/evdev.c:1172
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:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x10b/0x7f0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4fe1cdde59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4fe0737028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f4fe1f65fa0 RCX: 00007f4fe1cdde59
RDX: 0000200000003d80 RSI: 0000000080404507 RDI: 0000000000000008
RBP: 00007f4fe1d73e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4fe1f66038 R14: 00007f4fe1f65fa0 R15: 00007ffc2d29e718
</TASK>
Allocated by task 5308:
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+0x8f/0xa0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5362 [inline]
__kmalloc_noprof+0x309/0x7c0 mm/slub.c:5387
_kmalloc_noprof include/linux/slab.h:973 [inline]
_kzalloc_noprof include/linux/slab.h:1290 [inline]
usb_get_configuration+0x1ac/0x4410 drivers/usb/core/config.c:932
usb_enumerate_device drivers/usb/core/hub.c:2527 [inline]
usb_new_device+0x580/0x7d0 drivers/usb/core/hub.c:2665
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/0x1940 kernel/workqueue.c:3322
process_scheduled_works kernel/workqueue.c:3405 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 5418:
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+0x43/0x70 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2705 [inline]
slab_free mm/slub.c:6405 [inline]
kfree+0x20c/0x650 mm/slub.c:6720
usb_destroy_configuration+0x561/0x700 drivers/usb/core/config.c:896
usb_release_dev+0x42/0x110 drivers/usb/core/usb.c:494
device_release+0xd2/0x270 drivers/base/core.c:2636
kobject_cleanup lib/kobject.c:689 [inline]
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x1f7/0x640 lib/kobject.c:737
put_device+0x1f/0x30 drivers/base/core.c:3880
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/0x1940 kernel/workqueue.c:3322
process_scheduled_works kernel/workqueue.c:3405 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff888112fec000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 544 bytes inside of
freed 1024-byte region [ffff888112fec000, ffff888112fec400)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fe8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x200000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000040 ffff888100041dc0 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
head: 0200000000000040 ffff888100041dc0 dead000000000100 dead000000000122
head: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
head: 0200000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 16487694787, free_ts 14540795040
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1859
prep_new_page mm/page_alloc.c:1867 [inline]
get_page_from_freelist+0xf25/0x3400 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x28f/0x2b90 mm/page_alloc.c:5304
alloc_slab_page mm/slub.c:3294 [inline]
allocate_slab mm/slub.c:3408 [inline]
new_slab+0xa2/0x670 mm/slub.c:3454
refill_objects+0xe3/0x410 mm/slub.c:7338
refill_sheaf mm/slub.c:2832 [inline]
__pcs_replace_empty_main+0x376/0x680 mm/slub.c:4703
alloc_from_pcs mm/slub.c:4801 [inline]
slab_alloc_node mm/slub.c:4933 [inline]
__do_kmalloc_node mm/slub.c:5361 [inline]
__kmalloc_noprof+0x60d/0x7c0 mm/slub.c:5387
_kmalloc_noprof include/linux/slab.h:973 [inline]
_kzalloc_noprof include/linux/slab.h:1290 [inline]
__alloc_workqueue+0x1bd/0x1940 kernel/workqueue.c:5827
alloc_workqueue_va kernel/workqueue.c:5946 [inline]
alloc_workqueue_noprof+0xc7/0x130 kernel/workqueue.c:5962
init_netconsole+0xf3a/0x1150 drivers/net/netconsole.c:2418
do_one_initcall+0x11d/0x700 init/main.c:1347
do_initcall_level init/main.c:1409 [inline]
do_initcalls init/main.c:1425 [inline]
do_basic_setup init/main.c:1445 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1658
kernel_init+0x1f/0x1e0 init/main.c:1548
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page last free pid 11 tgid 11 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1406 [inline]
free_pages_prepare+0x558/0xcb0 mm/page_alloc.c:1451
__free_contig_range_common.constprop.0+0x12c/0x230 mm/page_alloc.c:6897
__free_contig_range mm/page_alloc.c:6942 [inline]
free_pages_bulk+0x126/0x1f0 mm/page_alloc.c:5257
vm_area_free_pages+0xad/0x2b0 mm/vmalloc.c:3439
vfree mm/vmalloc.c:3488 [inline]
vfree+0x107/0x750 mm/vmalloc.c:3462
delayed_vfree_work+0x56/0x80 mm/vmalloc.c:3392
process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
process_scheduled_works kernel/workqueue.c:3405 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 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:
ffff888112fec100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888112fec180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888112fec200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888112fec280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888112fec300: 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
* RE: [PATCH v2 1/3] HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
From: Xu, Even @ 2026-07-06 2:21 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
In-Reply-To: <20260703081234.A85D41F00A3E@smtp.kernel.org>
> -----Original Message-----
> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> Sent: Friday, July 3, 2026 4:13 PM
> To: Xu, Even <even.xu@intel.com>
> Cc: linux-input@vger.kernel.org; dmitry.torokhov@gmail.com
> Subject: Re: [PATCH v2 1/3] HID: Intel-thc-hid: Intel-thc: Add API to reset read
> DMA
>
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to
> consider:
>
> New issues:
> - [High] thc_rxdma_reset() fails to re-initialize the RxDMA PRD tables, leading to
> hardware reading shrunken buffer sizes on restart.
> - [High] thc_rxdma_reset() unsafely clears PRD base addresses for all DMA
> channels while TX or SW DMA engines may still be running.
> - [Medium] thc_rxdma_reset() ignores the return value of
> thc_interrupt_quiesce(dev, false) on the success path.
>
> Pre-existing issues:
> - [High] Incorrect polling condition and execution order in thc_interrupt_quiesce
> during unquiesce (int_quiesce = false).
> --
>
> commit b0beafd1bc7a02f7a2277c5a6d69c17c58724f01
> Author: Even Xu <even.xu@intel.com>
>
> HID: Intel-thc-hid: Intel-thc: Add API to reset read DMA
>
> Add a helper function thc_rxdma_reset() to do read DMA reset, it can be called
> when fatal DMA error happens.
>
> > diff --git a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> > b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> > index 6ee675e0a7384..7ceb8aeeccd37 100644
> > --- a/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> > +++ b/drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c
> > @@ -561,6 +561,57 @@ static int thc_wait_for_dma_pause(struct
> > thc_device *dev, enum thc_dma_channel c
> [ ... ]
> > +int thc_rxdma_reset(struct thc_device *dev) {
> [ ... ]
> > + ret = thc_wait_for_dma_pause(dev, THC_RXDMA2);
> > + if (ret) {
> > + dev_err(dev->dev, "Wait for RxDMA2 pause failed during RxDMA
> reset\n");
> > + goto end;
> > + }
> > +
> > + thc_dma_unconfigure(dev);
>
> [Severity: High]
> Could this cause memory corruption or IOMMU faults if TX or SW DMA engines
> are still running?
>
> thc_rxdma_reset() explicitly pauses RxDMA1 and RxDMA2 but does not pause
> TXDMA or SWDMA. It then calls thc_dma_unconfigure(), which loops over all
> DMA channels (MAX_THC_DMA_CHANNEL) and blindly overwrites their PRD
> base addresses to 0x0.
>
> If TXDMA was left running (for instance, if a prior thc_dma_write() timed out
> without clearing the TXDMA start bit), setting its PRD base address to 0 while it is
> actively fetching could cause the hardware to fetch descriptors from physical
> address 0.
>
> > +
> > + ret = thc_dma_configure(dev);
>
This isn't a problem, all DMA operations are protected by mutex "thc_bus_lock", that guarantees when do this rxdma_reset, TxDMA and SWDMA are not working.
> [Severity: High]
> Does this leave dirty 'len' descriptors in the PRD memory layout?
>
> thc_dma_configure() restarts the DMA engine pointers to 0, but it does not re-
> initialize the PRD memory layout. The hardware updates the 'len' field of PRD
> entries to indicate the actual length of received packets.
>
> Restarting the DMA from index 0 without restoring 'len' to the maximum buffer
> capacity could cause the hardware to use previously received smaller packet sizes
> as the maximum capacity for new transfers, resulting in truncated packets or
> DMA errors.
>
> > + if (ret) {
> > + dev_err(dev->dev, "Re-config DMA failed during RxDMA
> reset\n");
> > + goto end;
> > + }
> > +
> > + thc_interrupt_quiesce(dev, false);
>
This is expected, once DMA buffers were allocated, in order to avoid memory fragment, this DMA buffers will be reused.
That means the memory address and the max memory length are fixed.
Need pay attention is, this length is just a max memory length, the real length for every DMA data will be stored in every PRD entry and the length will be updated every time once DMA finished.
> [Severity: Medium]
> Is it safe to ignore the return value of thc_interrupt_quiesce() here?
>
> Discarding this return value on the success path could silently hide a hardware
> timeout or regmap read failure, potentially leaving interrupts disabled while the
> function reports success.
>
> [Severity: High]
> This is a pre-existing issue, but is the polling condition and execution order in
> thc_interrupt_quiesce() correct when unquiescing?
>
> When thc_interrupt_quiesce() is called with int_quiesce = false, it polls the
> HW_STS bit expecting it to be 1 BEFORE it clears the QUIESCE_EN bit:
>
> drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c:thc_interrupt_quiesce() {
> ...
> ret = regmap_read_poll_timeout(dev->thc_regmap,
> THC_M_PRT_CONTROL_OFFSET, ctrl,
> ctrl &
> THC_M_PRT_CONTROL_THC_DEVINT_QUIESCE_HW_STS,
> THC_REGMAP_POLLING_INTERVAL_US,
> THC_QUIESCE_EN_TIMEOUT_US);
> ...
> /* Unquiesce device interrupt - Clear the quiesce bit */
> if (!int_quiesce)
> regmap_write_bits(dev->thc_regmap, THC_M_PRT_CONTROL_OFFSET,
> THC_M_PRT_CONTROL_THC_DEVINT_QUIESCE_EN, 0); }
>
> Since the device is already quiesced, HW_STS is already 1, causing the poll to
> return immediately. It then clears the QUIESCE_EN bit and returns without ever
> waiting for HW_STS to become 0 to acknowledge the unquiesce. This could cause
> the driver to proceed before interrupts are actually re-enabled.
That's what this function call works. Called with int_quiesce = false means quiesce the interrupt, if already quiesced, HW_STS should be 0, so clear this bit directly is correct behavior.
>
> > +
> > +end:
> > + mutex_unlock(&dev->thc_bus_lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(thc_rxdma_reset, "INTEL_THC");
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260703075858.2780398-1-
> even.xu@intel.com?part=1
^ permalink raw reply
* RE: [PATCH v2 2/3] HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
From: Xu, Even @ 2026-07-06 2:30 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
In-Reply-To: <20260703081055.101CA1F00A3A@smtp.kernel.org>
> -----Original Message-----
> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> Sent: Friday, July 3, 2026 4:11 PM
> To: Xu, Even <even.xu@intel.com>
> Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
> Subject: Re: [PATCH v2 2/3] HID: Intel-thc-hid: Intel-quicki2c: Refine recover
> callback
>
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to
> consider:
>
> New issues:
> - [High] Use-After-Free due to premature `cancel_work_sync` during device
> removal and shutdown.
>
> Pre-existing issues:
> - [High] Missing `pci_free_irq_vectors()` in probe error paths and device removal
> leaks IRQ resources.
> - [High] The hard IRQ handler accesses hardware registers unconditionally,
> violating PM subsystem guidelines.
> --
>
> commit e88da9d40562f5d0be755568ae60010a7ba925df
> Author: Even Xu <even.xu@intel.com>
>
> HID: Intel-thc-hid: Intel-quicki2c: Refine recover callback
>
> This commit refines the recover flow by offloading it to a workqueue instead of
> processing it within the IRQ handler. It simplifies the operation with a reset API
> and ensures interrupts are disabled during the recovery process.
>
> > diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > index 46d3e9a019995..11e0e129b44c3 100644
> > --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > @@ -245,28 +245,28 @@ static irqreturn_t
> > quicki2c_irq_quick_handler(int irq, void *dev_id) }
>
> [Severity: High]
> This is a pre-existing issue, but does quicki2c_irq_quick_handler() access
> hardware registers unconditionally?
>
> If this device shares an INTx interrupt line, a spurious interrupt from another
> device could cause quicki2c_irq_quick_handler() to execute. It then calls
> thc_interrupt_enable() which writes to memory-mapped registers. If the device is
> in a low-power state, this hardware access can trigger a bus fault.
>
> Should pm_runtime_get_if_active() be used to check if the device is active before
> touching the hardware registers?
>
> [ ... ]
>
> > @@ -771,6 +771,8 @@ static void quicki2c_remove(struct pci_dev *pdev)
> > if (!qcdev)
> > return;
> >
> > + cancel_work_sync(&qcdev->recover_work);
>
THC runtime pm doesn't put THC into D3, THC registers can be accessed all the time.
> [Severity: High]
> Can this sequence lead to a use-after-free?
>
> cancel_work_sync() is called here, but hardware interrupts are not yet quiesced,
> and the state is still active. If an interrupt fires immediately after
> cancel_work_sync(), quicki2c_irq_thread_handler() can execute and call:
>
> schedule_work(&qcdev->recover_work);
>
> This re-enqueues the work item. After quicki2c_remove() returns, devres frees
> the qcdev structure. When the scheduled work later executes, it will dereference
> the freed qcdev pointer.
>
> Should the work be cancelled after interrupts are disabled and the device state is
> set to QUICKI2C_DISABLED?
>
> > quicki2c_hid_remove(qcdev);
> > quicki2c_dma_deinit(qcdev);
> >
> > pm_runtime_get_noresume(qcdev->dev);
> >
> > quicki2c_dev_deinit(qcdev);
> >
> > pci_clear_master(pdev);
> > }
>
Good finding!
In fact, I have another patch for remove() and shutdown(), if so, let me combine them into this patch.
> [Severity: High]
> This is a pre-existing issue, but does quicki2c_remove() leak IRQ resources?
>
> The remove path unbinds the device but doesn't appear to call
> pci_free_irq_vectors(). Similarly, if quicki2c_probe() fails after
> pci_alloc_irq_vectors(), the error path (disable_pci_device) does not free the
> vectors.
>
> Repeated unbind/bind operations or probe deferrals will continually leak these
> vectors, which can eventually exhaust system IRQ capacity.
>
This same as above.
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260703075858.2780398-1-
> even.xu@intel.com?part=2
^ permalink raw reply
* Re: [PATCH 05/13] mfd: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-06 8:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-6-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:26:25PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/mfd/arizona-irq.c | 2 +-
> drivers/mfd/wm8994-irq.c | 2 +-
For the wolfson bits:
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH 07/13] ASoC: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-06 9:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-8-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:26:27PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/codecs/cs42l84.c | 2 +-
> sound/soc/codecs/cx2072x.c | 2 +-
For the Cirrus bits:
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* [PATCH] HID: mcp2200: validate input report length
From: Pengpeng Hou @ 2026-07-06 9:09 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Pengpeng, Benjamin Tissoires, linux-input, linux-kernel
From: Pengpeng <pengpeng@iscas.ac.cn>
mcp2200_raw_event() dispatches on the first byte of the HID input
report and overlays the READ_ALL response structure on the same buffer.
The HID core passes the actual report size to the callback, so validate
that the command byte and READ_ALL response fields are present before
reading them.
Reject truncated reports for the pending command instead of reading
beyond the current input report payload.
Signed-off-by: Pengpeng <pengpeng@iscas.ac.cn>
---
drivers/hid/hid-mcp2200.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
index dafdd5b4a079..d2f45892dc22 100644
--- a/drivers/hid/hid-mcp2200.c
+++ b/drivers/hid/hid-mcp2200.c
@@ -299,8 +299,19 @@ static int mcp2200_raw_event(struct hid_device *hdev, struct hid_report *report,
struct mcp2200 *mcp = hid_get_drvdata(hdev);
struct mcp_read_all_resp *all_resp;
+ if (size < 1) {
+ mcp->status = -EINVAL;
+ complete(&mcp->wait_in_report);
+ return 0;
+ }
+
switch (data[0]) {
case READ_ALL:
+ if (size < sizeof(*all_resp)) {
+ mcp->status = -EINVAL;
+ break;
+ }
+
all_resp = (struct mcp_read_all_resp *) data;
mcp->status = 0;
mcp->gpio_inval = all_resp->io_port_val_bmap;
--
2.43.0
^ permalink raw reply related
* [PATCH] Input: atmel_mxt_ts - validate firmware frame bounds
From: Pengpeng Hou @ 2026-07-06 9:11 UTC (permalink / raw)
To: Nick Dyer; +Cc: Pengpeng, Dmitry Torokhov, linux-input, linux-kernel
From: Pengpeng <pengpeng@iscas.ac.cn>
mxt_flash_fw() walks a length-prefixed firmware image. The loop only
checks that the cursor is below fw->size before reading the two-byte
frame length and passing the declared frame to the bootloader write path.
Check that the length field and the complete frame, including CRC bytes,
fit in the remaining firmware image before reading or writing the frame.
Signed-off-by: Pengpeng <pengpeng@iscas.ac.cn>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2c0e5a67135b..2aa52b4e5ff5 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2927,10 +2927,19 @@ static int mxt_flash_fw(struct mxt_data *data, const struct firmware *fw)
if (error)
return error;
+ if (fw->size - pos < 2) {
+ dev_err(dev, "Truncated frame size in firmware\n");
+ return -EINVAL;
+ }
+
frame_size = ((*(fw->data + pos) << 8) | *(fw->data + pos + 1));
/* Take account of CRC bytes */
frame_size += 2;
+ if (frame_size > fw->size - pos) {
+ dev_err(dev, "Truncated frame in firmware\n");
+ return -EINVAL;
+ }
/* Write one frame to device */
error = mxt_bootloader_write(data, fw->data + pos, frame_size);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] HID: mcp2200: validate input report length
From: sashiko-bot @ 2026-07-06 9:19 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260706090932.75673-1-pengpeng@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] A raw event arriving immediately after `hid_hw_open` will cause a NULL pointer dereference because driver data and synchronization primitives are not yet initialized.
- [High] Concurrent calls to `mcp_cmd_read_all` can lead to corrupted state, lost wakeups, and data races because `wait_in_report` and shared response fields are not protected by locks during command execution.
- [High] The GPIO chip is managed via devres and unregistered after the HID hardware is stopped, leading to potential use-after-free or invalid hardware accesses.
--
commit d11b6ebfc1ea2a8baf37113e30af821787d261be
Author: Pengpeng <pengpeng@iscas.ac.cn>
Subject: HID: mcp2200: validate input report length
This commit updates mcp2200_raw_event() to validate that the command byte
and response fields are present in the HID input report before accessing
them. It rejects truncated reports instead of reading past the end of the
payload.
> diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
> index dafdd5b4a0797..d2f45892dc22a 100644
> --- a/drivers/hid/hid-mcp2200.c
> +++ b/drivers/hid/hid-mcp2200.c
> @@ -299,8 +299,19 @@ static int mcp2200_raw_event(struct hid_device *hdev, struct hid_report *report,
> struct mcp2200 *mcp = hid_get_drvdata(hdev);
> struct mcp_read_all_resp *all_resp;
>
> + if (size < 1) {
> + mcp->status = -EINVAL;
[Severity: High]
This is a pre-existing issue, but is it possible for an interrupt to fire
immediately after hid_hw_open() in mcp2200_probe() and trigger a NULL
pointer dereference here?
If mcp2200_raw_event() is called before hid_set_drvdata() and lock
initialization complete:
drivers/hid/hid-mcp2200.c:mcp2200_probe() {
...
ret = hid_hw_open(hdev);
...
mutex_init(&mcp->lock);
init_completion(&mcp->wait_in_report);
hid_set_drvdata(hdev, mcp);
...
}
Could mcp be NULL here, leading to a crash when accessing mcp->status?
> + complete(&mcp->wait_in_report);
> + return 0;
> + }
> +
> switch (data[0]) {
> case READ_ALL:
> + if (size < sizeof(*all_resp)) {
> + mcp->status = -EINVAL;
> + break;
> + }
> +
> all_resp = (struct mcp_read_all_resp *) data;
> mcp->status = 0;
> mcp->gpio_inval = all_resp->io_port_val_bmap;
[Severity: High]
This isn't a bug introduced by this patch, but can concurrent calls to
mcp_cmd_read_all() lead to corrupted state or lost wakeups?
In mcp_cmd_read_all(), the mutex is released before waiting for the
response:
drivers/hid/hid-mcp2200.c:mcp_cmd_read_all() {
...
mutex_unlock(&mcp->lock);
t = wait_for_completion_timeout(&mcp->wait_in_report, ...);
...
}
Does modifying mcp->status and mcp->gpio_inval locklessly here in
mcp2200_raw_event() create a data race if multiple threads are reading or
writing GPIO state concurrently?
[ ... ]
[Severity: High]
This is a pre-existing issue, but does using devres for the GPIO chip
create a use-after-free risk during device removal?
In mcp2200_probe(), the chip is registered with devres:
drivers/hid/hid-mcp2200.c:mcp2200_probe() {
...
ret = devm_gpiochip_add_data(&hdev->dev, &mcp->gc, mcp);
...
}
Then in mcp2200_remove(), the hardware is stopped before the chip is
unregistered:
drivers/hid/hid-mcp2200.c:mcp2200_remove() {
...
hid_hw_close(hdev);
hid_hw_stop(hdev);
...
}
Could a user-space process continue interacting with the GPIO device while
the USB device is physically removed, causing invalid hardware accesses
before devres cleans up the GPIO chip?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706090932.75673-1-pengpeng@iscas.ac.cn?part=1
^ permalink raw reply
* [PATCH] Input: iforce - validate packet lengths
From: Pengpeng Hou @ 2026-07-06 9:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Pengpeng Hou, Bryam Vargas, linux-input, linux-kernel
iforce_process_packet() decodes several packet formats from a
variable-length input buffer.
Add minimum length checks for joystick, wheel and status packets before
reading their fixed fields.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/input/joystick/iforce/iforce-packets.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/input/joystick/iforce/iforce-packets.c b/drivers/input/joystick/iforce/iforce-packets.c
index effa76bfd8f9..54697b252b84 100644
--- a/drivers/input/joystick/iforce/iforce-packets.c
+++ b/drivers/input/joystick/iforce/iforce-packets.c
@@ -155,6 +155,9 @@ void iforce_process_packet(struct iforce *iforce,
switch (packet_id) {
case 0x01: /* joystick position data */
+ if (len < 5)
+ break;
+
input_report_abs(dev, ABS_X,
(__s16) get_unaligned_le16(data));
input_report_abs(dev, ABS_Y,
@@ -170,6 +173,9 @@ void iforce_process_packet(struct iforce *iforce,
break;
case 0x03: /* wheel position data */
+ if (len < 4)
+ break;
+
input_report_abs(dev, ABS_WHEEL,
(__s16) get_unaligned_le16(data));
input_report_abs(dev, ABS_GAS, 255 - data[2]);
@@ -181,6 +187,9 @@ void iforce_process_packet(struct iforce *iforce,
break;
case 0x02: /* status report */
+ if (len < 2)
+ break;
+
input_report_key(dev, BTN_DEAD, data[0] & 0x02);
input_sync(dev);
--
2.43.0
^ permalink raw reply related
* [PATCH v1] HID: wacom: #include <linux/device-id/hid.h> instead of <linux/mod_devicetable.h>
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-06 9:21 UTC (permalink / raw)
To: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel
The single device-id structure that is used by drivers/hid/wacom.h and
its users (drivers/hid/wacom_sys.c + drivers/hid/wacom_wac.c) is struct
hid_device_id. So #include the much more lightweight
<linux/device-id/hid.h> instead the full <linux/mod_devicetable.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
there is no coordination needed, just make sure to apply it to v7.2-rc2 or
later. So please take it via the hid tree for the next merge window.
Best regards
Uwe
drivers/hid/wacom.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/wacom.h b/drivers/hid/wacom.h
index 1deacb4568cb..d2398b1cdbb2 100644
--- a/drivers/hid/wacom.h
+++ b/drivers/hid/wacom.h
@@ -82,7 +82,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/module.h>
-#include <linux/mod_devicetable.h>
+#include <linux/device-id/hid.h>
#include <linux/hid.h>
#include <linux/kfifo.h>
#include <linux/leds.h>
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH] Input: atmel_mxt_ts - validate firmware frame bounds
From: sashiko-bot @ 2026-07-06 9:24 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260706091144.76132-1-pengpeng@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but missing serialization in the sysfs `update_fw` attribute leads to double-free and use-after-free vulnerabilities.
- [High] This problem wasn't introduced by this patch, but direct use of a vmapped firmware buffer for I2C transfers causes DMA mapping failures or memory corruption.
--
commit 4f9a71983f301889709f29b76263c84f5ab07dfc
Author: Pengpeng <pengpeng@iscas.ac.cn>
Input: atmel_mxt_ts - validate firmware frame bounds
This commit adds bounds checking to the firmware update loop in
mxt_flash_fw() to ensure that the declared frame size and its CRC bytes fit
within the remaining firmware image. This prevents reading past the end of
the firmware buffer.
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 2c0e5a67135b6..2aa52b4e5ff50 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
[ ... ]
> @@ -2927,10 +2927,19 @@ static int mxt_flash_fw(struct mxt_data *data, const struct firmware *fw)
> if (error)
> return error;
>
> + if (fw->size - pos < 2) {
> + dev_err(dev, "Truncated frame size in firmware\n");
> + return -EINVAL;
> + }
> +
> frame_size = ((*(fw->data + pos) << 8) | *(fw->data + pos + 1));
>
> /* Take account of CRC bytes */
> frame_size += 2;
> + if (frame_size > fw->size - pos) {
> + dev_err(dev, "Truncated frame in firmware\n");
> + return -EINVAL;
> + }
>
> /* Write one frame to device */
> error = mxt_bootloader_write(data, fw->data + pos, frame_size);
[Severity: High]
This isn't a bug introduced by this patch, but does this direct use of the
firmware buffer for I2C transfers risk DMA mapping failures?
The request_firmware() function can map the firmware buffer using vmap()
for files larger than PAGE_SIZE.
When mxt_bootloader_write() passes this potentially vmapped buffer directly
into i2c_transfer(), an underlying I2C adapter driver using DMA will
attempt to map a vmapped address, which yields an invalid physical address.
Should we bounce this buffer into memory allocated with kmalloc() before
passing it to the I2C subsystem?
[Severity: High]
This isn't a bug introduced by this patch, but does the firmware update path
lack serialization?
Concurrent writes to the sysfs update_fw attribute can execute mxt_load_fw()
in parallel:
mxt_update_fw_store() {
...
error = mxt_load_fw(dev, MXT_FW_NAME);
}
If both threads evaluate the bootloader state as true simultaneously,
they will both execute the cleanup routines:
mxt_load_fw() {
if (!data->in_bootloader) {
mxt_free_input_device(data);
mxt_free_object_table(data);
...
}
Could this result in a double-free on pointers like data->raw_info_block
and a double-unregister of the input device?
> if (error)
> return error;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706091144.76132-1-pengpeng@iscas.ac.cn?part=1
^ permalink raw reply
* Re: [PATCH] Input: iforce - validate packet lengths
From: sashiko-bot @ 2026-07-06 9:34 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260706092016.78176-1-pengpeng@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Zero-length USB packets cause an integer underflow that bypasses length checks, triggering a massive out-of-bounds kernel memory read and panic.
- [High] Incomplete bounds checks for joystick and wheel packets allow logical out-of-bounds reads.
- [High] Out-of-bounds read in status report packet processing loop.
--
commit ebc2b4788d350db685692da195ae9d9cd27098a0
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>
Input: iforce - validate packet lengths
iforce_process_packet() decodes several packet formats from a
variable-length input buffer. Add minimum length checks for joystick,
wheel and status packets before reading their fixed fields.
> diff --git a/drivers/input/joystick/iforce/iforce-packets.c b/drivers/input/joystick/iforce/iforce-packets.c
> index effa76bfd8f9a..54697b252b84d 100644
> --- a/drivers/input/joystick/iforce/iforce-packets.c
> +++ b/drivers/input/joystick/iforce/iforce-packets.c
> @@ -155,6 +155,9 @@ void iforce_process_packet(struct iforce *iforce,
> switch (packet_id) {
>
> case 0x01: /* joystick position data */
> + if (len < 5)
> + break;
> +
[Severity: Critical]
This isn't a bug introduced by this patch, but does len underflow when a
zero-length USB packet is received?
Looking at iforce_usb_irq() in drivers/input/joystick/iforce/iforce-usb.c, it
calls iforce_process_packet() with urb->actual_length - 1:
iforce_process_packet(iforce, iforce_usb->data_in[0],
iforce_usb->data_in + 1, urb->actual_length - 1);
If urb->actual_length is 0, this underflows to SIZE_MAX. The new bounds check
here will be bypassed, and subsequent loops can read linearly out of bounds
into unmapped memory, potentially causing a panic.
[Severity: High]
This is a pre-existing issue, but is the len < 5 check sufficient to prevent
out-of-bounds reads when processing hats and buttons?
When iforce_process_packet() calls iforce_report_hats_buttons(), it
unconditionally accesses data[6]:
input_report_abs(dev, ABS_HAT0X, iforce_hat_to_axis[data[6] >> 4].x);
If a short packet arrives (e.g., actual length 6, leading to len = 5), the
check passes, but we still read stale memory when accessing data[6],
potentially reporting phantom hat movements or button presses.
[ ... ]
> case 0x03: /* wheel position data */
> + if (len < 4)
> + break;
> +
[Severity: High]
This is also a pre-existing issue, but this check is similarly insufficient
because iforce_report_hats_buttons() requires at least 7 bytes of data to
safely access data[6].
[ ... ]
> case 0x02: /* status report */
> + if (len < 2)
> + break;
> +
[Severity: High]
This isn't a bug introduced by this patch, but could the status report
processing loop read out of bounds?
Downstream in this case block, there is a loop:
for (j = 3; j < len; j += 2)
mark_core_as_ready(iforce, get_unaligned_le16(data + j));
If a packet arrives with an even length (e.g., len = 4), the loop condition
j < len allows get_unaligned_le16() to read two bytes starting at offset 3.
This extends beyond the valid payload length of 4, inadvertently reading stale
data that could match and corrupt force-feedback state tracking for unrelated
effects.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706092016.78176-1-pengpeng@iscas.ac.cn?part=1
^ permalink raw reply
* Re: [PATCH v2 1/7] Input: elan_i2c - Wait for initialization after enabling regulator supply
From: Chen-Yu Tsai @ 2026-07-06 10:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Jiri Kosina, Andi Shyti, linux-mediatek,
devicetree, linux-arm-kernel, chrome-platform, linux-input,
linux-i2c, linux-kernel
In-Reply-To: <akmZOC_J2ZTl4zLX@google.com>
On Sun, Jul 5, 2026 at 7:44 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Chen-Yu,
>
> On Fri, Jul 03, 2026 at 07:55:54PM +0800, Chen-Yu Tsai wrote:
> > Elan trackpad controllers require some delay after enabling power to
> > the controller for the hardware and firmware to initialize:
> >
> > - 2ms for hardware initialization
> > - 100ms for firmware initialization
> >
> > Until then, the hardware will not respond to I2C transfers. This was
> > observed on the MT8173 Chromebooks after the regulator supply for the
> > trackpad was changed to "not always on".
> >
> > Add proper delays after regulator_enable() calls. To avoid impacting
> > the boot time of existing devices that have the power rails always on,
> > skip the delay if the regulator supply was already enabled. In this
> > case the regulator is either always on, was on by default at power up,
> > or was left on by some other driver, such as the I2C OF component
> > prober. Either way the controller has had ample time to initialize.
>
> Unfortunately we do not know that [it had ample time]. For this code be
> reliable we need to record the time at which given regulator was turned
> on and then execute/adjust the delay as needed. Until we have it we need
> to assume the regulator was enabled at the time of regulator_enable()
> call.
>
> I am not concerned with increased boot time too much given the driver is
> set up for asynchronous probing.
I'm a bit confused since you raised the issue for ACPI platforms that don't
go through the regulator API. Now you're saying it's not a big issue?
Either way I will add some new regulator consumer APIs to handle this.
This needs to be in the regulator core to prevent race conditions, such
as when one thread deems the delay is enough just when another disables
the regulator.
ChenYu
^ permalink raw reply
* Re: [PATCH 02/13] m68k/coldfire: replace linux/gpio.h inclusions
From: Greg Ungerer @ 2026-07-06 11:22 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Thomas Bogendoerfer, Hauke Mehrtens,
Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-3-arnd@kernel.org>
Hi Arnd,
On 29/6/26 23:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for coldfire.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For the ColdFire changes, LGTM:
Reviewed-by: Greg Ungerer <gerg@linux-m68k.com>
Regards
Greg
> ---
> arch/m68k/coldfire/device.c | 2 +-
> arch/m68k/include/asm/mcfgpio.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
> index 1420bae0964f..9a0258acd998 100644
> --- a/arch/m68k/coldfire/device.c
> +++ b/arch/m68k/coldfire/device.c
> @@ -12,7 +12,7 @@
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/spi/spi.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #include <linux/fec.h>
> #include <linux/dmaengine.h>
> #include <asm/traps.h>
> diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
> index 7103cfa4edb6..29726aa40eb6 100644
> --- a/arch/m68k/include/asm/mcfgpio.h
> +++ b/arch/m68k/include/asm/mcfgpio.h
> @@ -16,7 +16,7 @@ int __mcfgpio_request(unsigned gpio);
> void __mcfgpio_free(unsigned gpio);
>
> #ifdef CONFIG_GPIOLIB
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #else
>
> /* our alternate 'gpiolib' functions */
^ permalink raw reply
* [PATCH] HID: i2c-hid: Fix "(null)" device name error logs in i2c_hid_parse
From: Ai Chao @ 2026-07-06 12:29 UTC (permalink / raw)
To: jikos, bentiss, dianders, treapking, kenkinming2002, raoxu,
superm1
Cc: linux-input, linux-kernel, Ai Chao
When i2c-hid fails to read the HID report descriptor during device
initialization, the error message prints as:
hid (null): reading report descriptor failed
The HID device name is set in hid_add_device() after calling
hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls
hid_err(), the device name has not been set yet, resulting in "(null)"
output.
Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because
the I2C client device is fully initialized with a proper name, providing
meaningful error messages for debugging.
Before: hid (null): reading report descriptor failed
After: i2c_hid i2c-TPD0001:00: reading report descriptor failed
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3adb16366e93..0e725a0f0abe 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -792,7 +792,7 @@ static int i2c_hid_parse(struct hid_device *hid)
ihid->hdesc.wReportDescRegister,
rdesc, rsize);
if (ret) {
- hid_err(hid, "reading report descriptor failed\n");
+ dev_err(&client->dev, "reading report descriptor failed\n");
goto out;
}
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: Fix "(null)" device name error logs in i2c_hid_parse
From: Mario Limonciello @ 2026-07-06 13:15 UTC (permalink / raw)
To: Ai Chao, jikos, bentiss, dianders, treapking, kenkinming2002,
raoxu
Cc: linux-input, linux-kernel
In-Reply-To: <20260706122910.3943372-1-aichao@kylinos.cn>
On 7/6/26 07:29, Ai Chao wrote:
> When i2c-hid fails to read the HID report descriptor during device
> initialization, the error message prints as:
>
> hid (null): reading report descriptor failed
>
> The HID device name is set in hid_add_device() after calling
> hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls
> hid_err(), the device name has not been set yet, resulting in "(null)"
> output.
>
> Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because
> the I2C client device is fully initialized with a proper name, providing
> meaningful error messages for debugging.
>
> Before: hid (null): reading report descriptor failed
> After: i2c_hid i2c-TPD0001:00: reading report descriptor failed
>
> Signed-off-by: Ai Chao <aichao@kylinos.cn>
I think it would be good to track down the Fixes tag that this goes with.
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 3adb16366e93..0e725a0f0abe 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -792,7 +792,7 @@ static int i2c_hid_parse(struct hid_device *hid)
> ihid->hdesc.wReportDescRegister,
> rdesc, rsize);
> if (ret) {
> - hid_err(hid, "reading report descriptor failed\n");
> + dev_err(&client->dev, "reading report descriptor failed\n");
> goto out;
> }
> }
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox