* Re: [PATCH v3 5/8] HID: asus: avoid sleeping calls in atomic context
From: Denis Benato @ 2026-06-14 13:33 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Luke D . Jones, Mateusz Schyboll, Denis Benato, Connor Belli,
sahiko-bot
In-Reply-To: <CAGwozwHXKosBi23oS8uvVrjr+fKZ+O+yUpHb0oT=acFCgRDwng@mail.gmail.com>
On 6/13/26 18:15, Antheas Kapenekakis wrote:
> On Sat, 13 Jun 2026 at 17:30, Denis Benato <denis.benato@linux.dev> wrote:
>> Avoid possibly calling asus_wmi_send_event(): a method that can sleep in
>> asus_raw_event() that is called in atomic context.
>>
>> This commit changes when methods are called, not method parameters:
>> the driver behaves as before.
> Observe the new AI guidelines and add assisted by tags if necessary.
> Or write the patches manually for mainline. This sentence is an AI
> euphemism
No AI was harmed during the production of these patches.
TBF I tried, but it changed too much things I didn't want to
change and then I ran out of credits, so.... I decided good old
manual bricolage was better for this.
> Who let 1489a34e97ef through? I implemented the plumbing for WMI
> callbacks with asus_hid_event last year because WMI cannot be called
> through HID. Brightness events had the exact same problem.
> kbd_led_work/kbd_led_update_all could be renamed and used for this. I
> would rather avoid introducing a new work queue. The one I added is
> enough if not too much
Alright, I'll try to use that queue for everything.
> Antheas
>
>> Fixes: 1489a34e97ef ("HID: asus: Implement Fn+F5 fan control key handler")
>> Reported-by: sahiko-bot@kernel.org
>> Signed-off-by: Denis Benato <denis.benato@linux.dev>
>> ---
>> drivers/hid/hid-asus.c | 67 +++++++++++++++++++++++++++++++++++-------
>> 1 file changed, 56 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>> index f38b18ad65c6..a6467172c455 100644
>> --- a/drivers/hid/hid-asus.c
>> +++ b/drivers/hid/hid-asus.c
>> @@ -150,6 +150,13 @@ struct asus_drvdata {
>> unsigned long battery_next_query;
>> struct work_struct fn_lock_sync_work;
>> bool fn_lock;
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + struct work_struct wmi_work;
>> + bool wmi_work_disabled;
>> + u8 wmi_data[FEATURE_KBD_REPORT_SIZE];
>> + int wmi_size;
>> + spinlock_t wmi_lock;
>> +#endif
>> struct asus_xgm_led *xgm_led;
>> };
>>
>> @@ -338,6 +345,7 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
>> return 0;
>> }
>>
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> /*
>> * Send events to asus-wmi driver for handling special keys
>> */
>> @@ -361,6 +369,32 @@ static int asus_wmi_send_event(struct asus_drvdata *drvdata, u8 code)
>> return 0;
>> }
>>
>> +static void asus_wmi_work(struct work_struct *work)
>> +{
>> + struct asus_drvdata *drvdata = container_of(work, struct asus_drvdata, wmi_work);
>> + u8 report_data[FEATURE_KBD_REPORT_SIZE];
>> + int report_size;
>> + unsigned long flags;
>> + int ret;
>> +
>> + spin_lock_irqsave(&drvdata->wmi_lock, flags);
>> + memcpy(report_data, drvdata->wmi_data, drvdata->wmi_size);
>> + report_size = drvdata->wmi_size;
>> + spin_unlock_irqrestore(&drvdata->wmi_lock, flags);
>> +
>> + ret = asus_wmi_send_event(drvdata, ASUS_FAN_CTRL_KEY_CODE);
>> + if (ret) {
>> + if (ret != -ENODEV)
>> + hid_warn(drvdata->hdev, "Failed to notify asus-wmi: %d\n", ret);
>> +
>> + /* Fallback: pass the raw event to the HID core */
>> + hid_report_raw_event(drvdata->hdev, HID_INPUT_REPORT,
>> + report_data, report_size,
>> + report_size, 1);
>> + }
>> +}
>> +#endif
>> +
>> static int asus_event(struct hid_device *hdev, struct hid_field *field,
>> struct hid_usage *usage, __s32 value)
>> {
>> @@ -397,6 +431,9 @@ static int asus_raw_event(struct hid_device *hdev,
>> struct hid_report *report, u8 *data, int size)
>> {
>> struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + unsigned long flags;
>> +#endif
>>
>> if (drvdata->battery && data[0] == BATTERY_REPORT_ID)
>> return asus_report_battery(drvdata, data, size);
>> @@ -422,19 +459,18 @@ static int asus_raw_event(struct hid_device *hdev,
>> * pass to userspace so it can implement its own fan control.
>> */
>> if (data[1] == ASUS_FAN_CTRL_KEY_CODE) {
>> - int ret = asus_wmi_send_event(drvdata, ASUS_FAN_CTRL_KEY_CODE);
>> -
>> - if (ret == 0) {
>> - /* Successfully handled by asus-wmi, block event */
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + spin_lock_irqsave(&drvdata->wmi_lock, flags);
>> + memcpy(drvdata->wmi_data, data, min_t(int, size, sizeof(drvdata->wmi_data)));
>> + drvdata->wmi_size = size;
>> + spin_unlock_irqrestore(&drvdata->wmi_lock, flags);
>> +
>> + if (!drvdata->wmi_work_disabled) {
>> + schedule_work(&drvdata->wmi_work);
>> + /* Successfully handled asynchronously, block event */
>> return -1;
>> }
>> -
>> - /*
>> - * Warn if asus-wmi failed (but not if it's unavailable).
>> - * Let the event reach userspace in all failure cases.
>> - */
>> - if (ret != -ENODEV)
>> - hid_warn(hdev, "Failed to notify asus-wmi: %d\n", ret);
>> +#endif
>> }
>>
>> /*
>> @@ -1350,6 +1386,10 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>> hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>>
>> drvdata->hdev = hdev;
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + INIT_WORK(&drvdata->wmi_work, asus_wmi_work);
>> + spin_lock_init(&drvdata->wmi_lock);
>> +#endif
>>
>> if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
>> ret = asus_battery_probe(hdev);
>> @@ -1460,6 +1500,11 @@ static void asus_remove(struct hid_device *hdev)
>> if (drvdata->quirks & QUIRK_HID_FN_LOCK)
>> cancel_work_sync(&drvdata->fn_lock_sync_work);
>>
>> +#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + drvdata->wmi_work_disabled = true;
>> + cancel_work_sync(&drvdata->wmi_work);
>> +#endif
>> +
>> if (drvdata->xgm_led)
>> led_classdev_unregister(&drvdata->xgm_led->cdev);
>>
>> --
>> 2.47.3
>>
>>
^ permalink raw reply
* [BUG] KASAN: slab-out-of-bounds in rmi_create_function
From: Shuangpeng Bai @ 2026-06-14 15:16 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel
Hi Kernel Maintainers,
I hit the following report while testing current upstream kernel:
KASAN: slab-out-of-bounds in rmi_create_function
on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
To help trigger the bug more reliably, we applied a minimal diagnostic patch
that only adds delays and print statements.
The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/6f392317d13655f16a8983fe1587dbcc
I'm happy to test debug patches or provide additional information.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
[ 128.210187][ T10] BUG: KASAN: slab-out-of-bounds in rmi_create_function (include/linux/instrumented.h:97 include/asm-generic/bitops/instrumented-atomic.h:28 drivers/input/rmi4/rmi_driver.c:861)
[ 128.210768][ T10] Write of size 8 at addr ffff888178e09b50 by task kworker/0:1/10
[ 128.211308][ T10]
[ 128.211489][ T10] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 128.211492][ T10] Workqueue: events acpi_table_events_fn
[ 128.211499][ T10] Call Trace:
[ 128.211501][ T10] <TASK>
[ 128.211503][ T10] dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 128.211508][ T10] print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 128.211520][ T10] kasan_report (mm/kasan/report.c:595)
[ 128.211526][ T10] kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
[ 128.211530][ T10] rmi_create_function (include/linux/instrumented.h:97 include/asm-generic/bitops/instrumented-atomic.h:28 drivers/input/rmi4/rmi_driver.c:861)
[ 128.211533][ T10] rmi_scan_pdt (drivers/input/rmi4/rmi_driver.c:525 drivers/input/rmi4/rmi_driver.c:552)
[ 128.211549][ T10] rmi_init_functions (drivers/input/rmi4/rmi_driver.c:1074)
[ 128.211565][ T10] rmi_driver_probe (drivers/input/rmi4/rmi_driver.c:1207)
[ 128.211569][ T10] really_probe (drivers/base/dd.c:? drivers/base/dd.c:709)
[ 128.211571][ T10] __driver_probe_device (drivers/base/dd.c:871)
[ 128.211579][ T10] driver_probe_device (drivers/base/dd.c:901)
[ 128.211581][ T10] __device_attach_driver (drivers/base/dd.c:1029)
[ 128.211587][ T10] bus_for_each_drv (drivers/base/bus.c:500)
[ 128.211600][ T10] __device_attach (drivers/base/dd.c:1101)
[ 128.211613][ T10] device_initial_probe (drivers/base/dd.c:1156)
[ 128.211616][ T10] bus_probe_device (drivers/base/bus.c:613)
[ 128.211619][ T10] device_add (drivers/base/core.c:3706)
[ 128.211623][ T10] rmi_register_transport_device (drivers/input/rmi4/rmi_bus.c:98)
[ 128.211626][ T10] rmi_spi_probe (drivers/input/rmi4/rmi_spi.c:435)
[ 128.211629][ T10] really_probe (drivers/base/dd.c:? drivers/base/dd.c:709)
[ 128.211631][ T10] __driver_probe_device (drivers/base/dd.c:871)
[ 128.211634][ T10] driver_probe_device (drivers/base/dd.c:901)
[ 128.211636][ T10] __device_attach_driver (drivers/base/dd.c:1029)
[ 128.211641][ T10] bus_for_each_drv (drivers/base/bus.c:500)
[ 128.211653][ T10] __device_attach (drivers/base/dd.c:1101)
[ 128.211671][ T10] device_initial_probe (drivers/base/dd.c:1156)
[ 128.211674][ T10] bus_probe_device (drivers/base/bus.c:613)
[ 128.211676][ T10] device_add (drivers/base/core.c:3706)
[ 128.211679][ T10] __spi_add_device (drivers/spi/spi.c:756)
[ 128.211689][ T10] acpi_register_spi_device (drivers/spi/spi.c:786 drivers/spi/spi.c:3055)
[ 128.211697][ T10] acpi_spi_notify (drivers/spi/spi.c:5093)
[ 128.211699][ T10] notifier_call_chain (kernel/notifier.c:85)
[ 128.211702][ T10] blocking_notifier_call_chain (kernel/notifier.c:380)
[ 128.211705][ T10] acpi_generic_device_attach (drivers/acpi/scan.c:2297)
[ 128.211710][ T10] acpi_bus_attach (drivers/acpi/scan.c:2323 drivers/acpi/scan.c:2372)
[ 128.211740][ T10] device_for_each_child (drivers/base/core.c:4035)
[ 128.211751][ T10] acpi_dev_for_each_child (drivers/acpi/bus.c:1208)
[ 128.211761][ T10] acpi_bus_attach (drivers/acpi/scan.c:2393)
[ 128.211776][ T10] device_for_each_child (drivers/base/core.c:4035)
[ 128.211787][ T10] acpi_dev_for_each_child (drivers/acpi/bus.c:1208)
[ 128.211797][ T10] acpi_bus_attach (drivers/acpi/scan.c:2393)
[ 128.211816][ T10] device_for_each_child (drivers/base/core.c:4035)
[ 128.211827][ T10] acpi_dev_for_each_child (drivers/acpi/bus.c:1208)
[ 128.211839][ T10] acpi_bus_attach (drivers/acpi/scan.c:2393)
[ 128.211859][ T10] acpi_bus_scan (drivers/acpi/scan.c:2743)
[ 128.211871][ T10] acpi_table_events_fn (drivers/acpi/scan.c:2933)
[ 128.211874][ T10] process_scheduled_works (kernel/workqueue.c:3314 kernel/workqueue.c:3397)
[ 128.211879][ T10] worker_thread (kernel/workqueue.c:3478)
[ 128.211884][ T10] kthread (kernel/kthread.c:436)
[ 128.211891][ T10] ret_from_fork (kernel/process.c:158)
[ 128.211902][ T10] ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Best,
Shuangpeng
^ permalink raw reply
* Re: [PATCH 2/2] iio: hid-sensor-rotation: Fix stale or zero output when reading raw values
From: Jonathan Cameron @ 2026-06-14 16:50 UTC (permalink / raw)
To: Zhang, Lixu
Cc: Jiri Kosina, Srinivas Pandruvada, Benjamin Tissoires,
David Lechner, Nuno Sá, Andy Shevchenko,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SJ0PR11MB5613EE4659912C262E950C9D93182@SJ0PR11MB5613.namprd11.prod.outlook.com>
On Fri, 12 Jun 2026 05:33:32 +0000
"Zhang, Lixu" <lixu.zhang@intel.com> wrote:
> >-----Original Message-----
> >From: Jonathan Cameron <jic23@kernel.org>
> >Sent: Friday, June 12, 2026 12:35 AM
> >To: Zhang, Lixu <lixu.zhang@intel.com>
> >Cc: Jiri Kosina <jikos@kernel.org>; Srinivas Pandruvada
> ><srinivas.pandruvada@linux.intel.com>; Benjamin Tissoires
> ><bentiss@kernel.org>; David Lechner <dlechner@baylibre.com>; Nuno Sá
> ><nuno.sa@analog.com>; Andy Shevchenko <andy@kernel.org>; linux-
> >input@vger.kernel.org; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org
> >Subject: Re: [PATCH 2/2] iio: hid-sensor-rotation: Fix stale or zero output when
> >reading raw values
> >
> >On Wed, 10 Jun 2026 16:29:10 +0800
> >Zhang Lixu <lixu.zhang@intel.com> wrote:
> >
> >> When reading the raw quaternion attribute (in_rot_quaternion_raw), the
> >> driver currently returns either all zeros (if the sensor was never
> >> enabled) or stale data (if the sensor was previously enabled) because
> >> it reads from the internal buffer without explicitly requesting a new
> >> sample from the sensor.
> >>
> >> To fix this, power up the sensor, call
> >> sensor_hub_input_attr_read_values()
> >> to issue a synchronous GET_REPORT and receive the full quaternion data
> >> directly into a local buffer, then decode the four components.
> >>
> >> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
> >Hi Zhang,
> >
> >Given this is clearly a fix, can you reply to this thread with an appropriate Fixes
> >tag. Otherwise looks fine to me.
>
> Sure, here is the Fixes tag:
>
> Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support")
>
> >
> >Given timing and I guess that this bug is fairly old, this will probably only go
> >upstream after rc1.
>
> That's perfectly fine. Thanks for the review!
Applied to the fixes-togreg branch of iio.git.
Note I'll be rebasing that on rc1 before sending out a pull request.
Thanks,
Jonathan
>
> Best regards,
> Lixu
>
> >
> >Thanks,
> >
> >Jonathan
> >
>
^ permalink raw reply
* Re: [PATCH 2/9] iio: orientation: hid-sensor-incl-3d: Fix race between callback registration and device exposure
From: Jonathan Cameron @ 2026-06-14 18:24 UTC (permalink / raw)
To: Pandruvada, Srinivas
Cc: dlechner@baylibre.com, archana.patni@linux.intel.com,
hongyan.song@intel.com, nuno.sa@analog.com, jikos@kernel.org,
andy@kernel.org, sanjayembeddedse@gmail.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <b3c449ee646fc3bff89dbbdfaf04f731fea87b2b.camel@intel.com>
On Mon, 8 Jun 2026 15:34:05 +0000
"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> On Sat, 2026-06-06 at 17:07 +0530, Sanjay Chitroda wrote:
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > The driver registers the IIO device before completing sensor hub
> > callback registration and unregisters callbacks while the IIO device
> > is still exposed during teardown.
> >
> > This creates race windows in both probe and remove paths, which can
> > lead to NULL pointer dereferences or use-after-free.
>
> Reordering is fine, but can you show how this use after free is
> possible?
Agreed - I'm not seeing a definite issue so more info needed.
For now I'm going to mark this changes-requested in patchwork.
It might be a touch slow if someone manages to get buffered capture
up before the callbacks are available, but I think that just means
dropping a few samples?
Jonathan
>
> Thanks,
> Srinivas
^ permalink raw reply
* [BUG] KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
From: Shuangpeng Bai @ 2026-06-14 19:19 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada, bentiss, linux-input,
linux-iio, linux-kernel
Hi Kernel Maintainers,
I hit the following report while testing current upstream kernel:
KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/d82ac0d19fda016e81d7fa1ab028d967
I'm happy to test debug patches or provide additional information.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
[ 73.157590][ T8356] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave (include/linux/instrumented.h:112 include/linux/atomic/atomic-instrumented.h:1300 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:133 kernel/locking/spinlock.c:166)
[ 73.161235][ T8356] Write of size 4 at addr ffff88810eb72528 by task hid_sensor_cust/8356
[ 73.163453][ T8356] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 73.163457][ T8356] Call Trace:
[ 73.163461][ T8356] <TASK>
[ 73.163464][ T8356] dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 73.163471][ T8356] print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 73.163486][ T8356] kasan_report (mm/kasan/report.c:595)
[ 73.163495][ T8356] kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
[ 73.163500][ T8356] _raw_spin_lock_irqsave (include/linux/instrumented.h:112 include/linux/atomic/atomic-instrumented.h:1300 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:133 kernel/locking/spinlock.c:166)
[ 73.163539][ T8356] add_wait_queue (kernel/sched/wait.c:23)
[ 73.163547][ T8356] hid_sensor_custom_poll (include/linux/poll.h:45 drivers/hid/hid-sensor-custom.c:706)
[ 73.163556][ T8356] do_sys_poll (include/linux/poll.h:82 fs/select.c:877 fs/select.c:920 fs/select.c:1015)
[ 73.163692][ T8356] __x64_sys_poll (fs/select.c:1072 fs/select.c:1060 fs/select.c:1060)
[ 73.163708][ T8356] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 73.163714][ T8356] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 73.163755][ T8356] </TASK>
[ 73.214615][ T8356] Freed by task 781 on cpu 1 at 72.569353s:
[ 73.215524][ T8356] kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[ 73.216247][ T8356] kasan_save_free_info (mm/kasan/generic.c:584)
[ 73.217018][ T8356] __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[ 73.217739][ T8356] kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[ 73.218335][ T8356] devres_release_all (drivers/base/devres.c:50 drivers/base/devres.c:547 drivers/base/devres.c:576)
[ 73.219108][ T8356] device_release_driver_internal (drivers/base/dd.c:598 drivers/base/dd.c:1357 drivers/base/dd.c:1375)
[ 73.220034][ T8356] bus_remove_device (drivers/base/bus.c:657)
[ 73.220796][ T8356] device_del (drivers/base/core.c:3895)
[ 73.221458][ T8356] platform_device_unregister (drivers/base/platform.c:797 drivers/base/platform.c:839)
[ 73.222310][ T8356] mfd_remove_devices_fn (drivers/mfd/mfd-core.c:385)
[ 73.223121][ T8356] device_for_each_child_reverse (drivers/base/core.c:4065)
[ 73.224033][ T8356] mfd_remove_devices (drivers/mfd/mfd-core.c:401)
[ 73.224779][ T8356] hid_device_remove (drivers/hid/hid-core.c:?)
[ 73.225537][ T8356] device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
[ 73.226449][ T8356] bus_remove_device (drivers/base/bus.c:657)
[ 73.227200][ T8356] device_del (drivers/base/core.c:3895)
[ 73.227857][ T8356] hid_destroy_device (drivers/hid/hid-core.c:3064 drivers/hid/hid-core.c:3086)
[ 73.228617][ T8356] usbhid_disconnect (drivers/hid/usbhid/hid-core.c:1476)
[ 73.238613][ T8356] The buggy address belongs to the object at ffff88810eb72400
[ 73.238613][ T8356] which belongs to the cache kmalloc-512 of size 512
[ 73.240744][ T8356] The buggy address is located 296 bytes inside of
[ 73.240744][ T8356] freed 512-byte region [ffff88810eb72400, ffff88810eb72600)
Best,
Shuangpeng
^ permalink raw reply
* Re: [PATCH v2] Input: apple_z2 - bound the device-reported finger count
From: Dmitry Torokhov @ 2026-06-14 20:56 UTC (permalink / raw)
To: hexlabsecurity
Cc: Sasha Finkelstein, linux-kernel, Janne Grunau, linux-arm-kernel,
linux-input, Sven Peter, asahi, Neal Gompa
In-Reply-To: <20260613-b4-disp-4ebcbd68-v2-1-0161acfbd688@proton.me>
Hi Bryam,
On Sat, Jun 13, 2026 at 08:22:51PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> apple_z2_parse_touches() takes the finger count from the touch
> controller's report and loops over that many fixed-size finger records
> without ever checking the count against the length of the report:
>
> nfingers = msg[APPLE_Z2_NUM_FINGERS_OFFSET];
> fingers = (struct apple_z2_finger *)(msg + APPLE_Z2_FINGERS_OFFSET);
> for (i = 0; i < nfingers; i++)
> /* read fingers[i] ... */
>
> msg points into the fixed 4000-byte z2->rx_buf and nfingers is a single
> device-supplied byte, so it can be as large as 255. A malicious,
> malfunctioning or counterfeit controller (or an interposer on the SPI
> bus) can report a large finger count in a short packet, making the loop
> read up to 255 * sizeof(struct apple_z2_finger) bytes starting 24 bytes
> into msg -- far past the 4000-byte buffer. This is a controller-driven
> heap out-of-bounds read, and the finger fields that are read (position,
> pressure, touch and tool dimensions) are forwarded to userspace as input
> events, leaking adjacent kernel memory.
>
> Bound the device-reported count to the number of finger records the
> report actually carries.
As Sashiko mentioned, if we do not trust hardware to send valid data we
should also validate that packet size supplied by the device is
reasonable.
Also I wonder why would we want to report some of fingers in case when
device sends bogus number of contacts? I'd drop such packet (maybe
logging ratelimited or "once" message).
You can ignore Sahiko's comment about __free(kfree) not handling error
pointers.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: touchwin - reset the packet index on every complete packet
From: Dmitry Torokhov @ 2026-06-14 20:59 UTC (permalink / raw)
To: hexlabsecurity; +Cc: linux-input, Rick Koch, linux-kernel
In-Reply-To: <20260613-b4-disp-69921bfd-v1-1-82c036899959@proton.me>
On Sat, Jun 13, 2026 at 08:07:20PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> tw_interrupt() accumulates each non-zero serial byte into a fixed
> three-byte buffer with a running index that is only reset once a full
> packet has been received *and* the device's two Y bytes agree:
>
> tw->data[tw->idx++] = data;
> if (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) {
> ...
> tw->idx = 0;
> }
>
> The reset is gated on tw->data[1] == tw->data[2], a value the device
> controls. A malicious, malfunctioning or counterfeit Touchwindow
> peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the
> index reaches TW_LENGTH without the equality holding, is never reset, and
> keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte
> array and the rest of the heap-allocated struct tw, one attacker-chosen
> byte at a time -- an unbounded, device-driven heap out-of-bounds write.
>
> Reset the index on every completed packet and report an event only when
> the two Y bytes match, like the other serio touchscreen drivers do.
>
> Fixes: 11ea3173d5f2 ("Input: add driver for Touchwin serial touchscreens")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
From: Maxwell Doose @ 2026-06-14 21:02 UTC (permalink / raw)
To: Shuangpeng Bai
Cc: jikos, jic23, srinivas.pandruvada, bentiss, linux-input,
linux-iio, linux-kernel
In-Reply-To: <178144969601.60470.12928355382146160896@gmail.com>
Hi Shuangpeng,
On Sun, 14 Jun 2026 15:19:21 -0400
Shuangpeng Bai <shuangpeng.kernel@gmail.com> wrote:
> I hit the following report while testing current upstream kernel:
>
> KASAN: slab-use-after-free in _raw_spin_lock_irqsave from
> hid-sensor-custom
>
> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
>
Is this correct? It seems to point to changes in HPFS.
>
> The reproducer and .config files are here.
> https://gist.github.com/shuangpengbai/d82ac0d19fda016e81d7fa1ab028d967
>
> I'm happy to test debug patches or provide additional information.
>
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>
This bug report also seems to have nothing to do with IIO after
investigating the call trace, seems more like for the HID/input folks
than iio. HID folks, seems like it was caused here:
[ 73.163547][ T8356] hid_sensor_custom_poll (include/linux/poll.h:45 drivers/hid/hid-sensor-custom.c:706)
before _raw_spin_lock_irqsave() gets called and KASAN triggers the slab-use-after-free.
--
best regards,
max
^ permalink raw reply
* Re: [PATCH] Input: goodix - clamp the device-reported contact count
From: Dmitry Torokhov @ 2026-06-14 21:02 UTC (permalink / raw)
To: Hans de Goede; +Cc: hexlabsecurity, linux-input, linux-kernel
In-Reply-To: <6f529998-2b4f-441e-88be-fbc4eb33461c@kernel.org>
On Sun, Jun 14, 2026 at 01:44:07PM +0200, Hans de Goede wrote:
> Hi,
>
> On 13-Jun-26 04:10, Bryam Vargas via B4 Relay wrote:
> > From: Bryam Vargas <hexlabsecurity@proton.me>
> >
> > goodix_ts_read_input_report() copies the number of touch points reported
> > by the device into an on-stack buffer
> >
> > u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
> >
> > which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only
> > runtime check bounds the per-interrupt count against ts->max_touch_num,
> > but that value is taken verbatim from a 4-bit field of the device
> > configuration block and is never clamped:
> >
> > ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
> >
> > The nibble can be 0..15, so a malfunctioning, malicious or counterfeit
> > controller (or an attacker tampering with the I2C bus) can advertise up
> > to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num
> > of up to 15 and the second goodix_i2c_read() writes
> > ts->contact_size * (touch_num - 1) bytes past the one-contact header into
> > point_data - up to 30 bytes (45 with the 9-byte report format) beyond the
> > 92-byte buffer: a stack out-of-bounds write.
> >
> > Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts
> > point_data[] is sized for, when reading it from the configuration.
> >
> > Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
>
> Thanks, patch looks good to me:
>
> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>
> Regards,
>
> Hans
>
>
> > ---
> > drivers/input/touchscreen/goodix.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
> > index f8798d11ec03..17fcfe45988c 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -1057,7 +1057,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> > }
> >
> > ts->int_trigger_type = ts->config[TRIGGER_LOC] & 0x03;
> > - ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
> > + ts->max_touch_num = min(ts->config[MAX_CONTACTS_LOC] & 0x0f,
> > + GOODIX_MAX_CONTACTS);
Should we drop the report if is has bogus data in it?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
From: Shuangpeng @ 2026-06-14 21:24 UTC (permalink / raw)
To: Maxwell Doose
Cc: jikos, jic23, srinivas.pandruvada, bentiss, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260614160213.085e1efc@linuxescape>
> On Jun 14, 2026, at 17:02, Maxwell Doose <m32285159@gmail.com> wrote:
>
> Hi Shuangpeng,
>
> On Sun, 14 Jun 2026 15:19:21 -0400
> Shuangpeng Bai <shuangpeng.kernel@gmail.com> wrote:
>
>> I hit the following report while testing current upstream kernel:
>>
>> KASAN: slab-use-after-free in _raw_spin_lock_irqsave from
>> hid-sensor-custom
>>
>> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
>>
>
> Is this correct? It seems to point to changes in HPFS.
>
That commit was the linux.git HEAD where I reproduced the crash. I did not mean
to imply that the HPFS merge introduced the issue.
>>
>> The reproducer and .config files are here.
>> https://gist.github.com/shuangpengbai/d82ac0d19fda016e81d7fa1ab028d967
>>
>> I'm happy to test debug patches or provide additional information.
>>
>> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>>
>
> This bug report also seems to have nothing to do with IIO after
> investigating the call trace, seems more like for the HID/input folks
> than iio. HID folks, seems like it was caused here:
>
> [ 73.163547][ T8356] hid_sensor_custom_poll (include/linux/poll.h:45 drivers/hid/hid-sensor-custom.c:706)
>
> before _raw_spin_lock_irqsave() gets called and KASAN triggers the slab-use-after-free.
>
Thanks for checking.
I agree that this does not look like an IIO-specific issue from the trace. The crash
is reported from hid_sensor_custom_poll() in drivers/hid/hid-sensor-custom.c.
> --
> best regards,
> max
^ permalink raw reply
* Re: [PATCH] Input: mms114 - reject an oversized device packet size
From: Dmitry Torokhov @ 2026-06-14 21:35 UTC (permalink / raw)
To: hexlabsecurity; +Cc: linux-kernel, linux-input, Joonyoung Shim, Kyungmin Park
In-Reply-To: <20260612-b4-disp-dc4b8dc4-v1-1-d7cb0a828d92@proton.me>
On Fri, Jun 12, 2026 at 11:21:14PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> mms114_interrupt() reads a packet of touch data from the device into a
> fixed-size on-stack buffer
>
> struct mms114_touch touch[MMS114_MAX_TOUCH];
>
> which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes,
> i.e. 80 bytes. The length of the I2C read into it is taken verbatim from
> the device:
>
> packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE);
> if (packet_size <= 0)
> goto out;
> ...
> error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size,
> (u8 *)touch);
>
> packet_size is a single device register byte (0x0F) and the only check
> is the lower bound packet_size <= 0; it is never bounded against the
> size of touch[]. A malfunctioning, malicious or counterfeit controller
> (or an attacker tampering with the I2C bus) can report a packet_size of
> up to 255, so __mms114_read_reg() writes up to 175 bytes past the end of
> touch[] on the IRQ-thread stack: a stack out-of-bounds write that can
> overwrite the stack canary, saved registers and the return address.
>
> A well-formed device never reports more than the buffer holds, so reject
> an oversized packet and drop the report, consistent with the handler's
> other error paths, rather than reading past the buffer.
>
> Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> drivers/input/touchscreen/mms114.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index af462086a65c..4c75f16c503d 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -226,6 +226,13 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
> if (packet_size <= 0)
> goto out;
>
> + /* the device controls packet_size; reject anything too big for touch[] */
> + if (packet_size > (int)sizeof(touch)) {
I gonna drop this cast (as thankfully we are not using -Wsign-compare)
and apply, thank you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
From: Maxwell Doose @ 2026-06-14 21:35 UTC (permalink / raw)
To: Shuangpeng
Cc: jikos, jic23, srinivas.pandruvada, bentiss, linux-input,
linux-iio, linux-kernel
In-Reply-To: <C79160E7-5244-407D-81E7-2A1B14231B22@gmail.com>
On Sun, 14 Jun 2026 17:24:12 -0400
Shuangpeng <shuangpeng.kernel@gmail.com> wrote:
> > On Jun 14, 2026, at 17:02, Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > Hi Shuangpeng,
> >
> > On Sun, 14 Jun 2026 15:19:21 -0400
> > Shuangpeng Bai <shuangpeng.kernel@gmail.com> wrote:
> >
> >> I hit the following report while testing current upstream kernel:
> >>
> >> KASAN: slab-use-after-free in _raw_spin_lock_irqsave from
> >> hid-sensor-custom
> >>
> >> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
> >>
> >
> > Is this correct? It seems to point to changes in HPFS.
> >
>
> That commit was the linux.git HEAD where I reproduced the crash. I did not mean
> to imply that the HPFS merge introduced the issue.
>
If you have (a lot of) time, it may be worth trying git bisect to get
the exact commit. No worries if you don't of course, but it would be
incredibly helpful to the HID folks.
--
best regards,
max
> >>
> >> The reproducer and .config files are here.
> >> https://gist.github.com/shuangpengbai/d82ac0d19fda016e81d7fa1ab028d967
> >>
> >> I'm happy to test debug patches or provide additional information.
> >>
> >> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> >>
> >
> > This bug report also seems to have nothing to do with IIO after
> > investigating the call trace, seems more like for the HID/input folks
> > than iio. HID folks, seems like it was caused here:
> >
> > [ 73.163547][ T8356] hid_sensor_custom_poll (include/linux/poll.h:45 drivers/hid/hid-sensor-custom.c:706)
> >
> > before _raw_spin_lock_irqsave() gets called and KASAN triggers the slab-use-after-free.
> >
>
> Thanks for checking.
>
> I agree that this does not look like an IIO-specific issue from the trace. The crash
> is reported from hid_sensor_custom_poll() in drivers/hid/hid-sensor-custom.c.
>
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free in _raw_spin_lock_irqsave from hid-sensor-custom
From: Shuangpeng @ 2026-06-14 21:50 UTC (permalink / raw)
To: Maxwell Doose
Cc: jikos, jic23, srinivas.pandruvada, bentiss, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260614163518.2a265172@linuxescape>
> On Jun 14, 2026, at 17:35, Maxwell Doose <m32285159@gmail.com> wrote:
>
> On Sun, 14 Jun 2026 17:24:12 -0400
> Shuangpeng <shuangpeng.kernel@gmail.com> wrote:
>
>>> On Jun 14, 2026, at 17:02, Maxwell Doose <m32285159@gmail.com> wrote:
>>>
>>> Hi Shuangpeng,
>>>
>>> On Sun, 14 Jun 2026 15:19:21 -0400
>>> Shuangpeng Bai <shuangpeng.kernel@gmail.com> wrote:
>>>
>>>> I hit the following report while testing current upstream kernel:
>>>>
>>>> KASAN: slab-use-after-free in _raw_spin_lock_irqsave from
>>>> hid-sensor-custom
>>>>
>>>> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
>>>>
>>>
>>> Is this correct? It seems to point to changes in HPFS.
>>>
>>
>> That commit was the linux.git HEAD where I reproduced the crash. I did not mean
>> to imply that the HPFS merge introduced the issue.
>>
>
> If you have (a lot of) time, it may be worth trying git bisect to get
> the exact commit. No worries if you don't of course, but it would be
> incredibly helpful to the HID folks.
>
Thanks for the suggestion.
Unfortunately, I don’t have enough time to run a bisect right now,
but I’ll keep it in mind and will follow up if I get a chance to look
into it later.
Best,
Shuangpeng
> --
> best regards,
> max
>
>
>
>>>>
>>>> The reproducer and .config files are here.
>>>> https://gist.github.com/shuangpengbai/d82ac0d19fda016e81d7fa1ab028d967
>>>>
>>>> I'm happy to test debug patches or provide additional information.
>>>>
>>>> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>>>>
>>>
>>> This bug report also seems to have nothing to do with IIO after
>>> investigating the call trace, seems more like for the HID/input folks
>>> than iio. HID folks, seems like it was caused here:
>>>
>>> [ 73.163547][ T8356] hid_sensor_custom_poll (include/linux/poll.h:45 drivers/hid/hid-sensor-custom.c:706)
>>>
>>> before _raw_spin_lock_irqsave() gets called and KASAN triggers the slab-use-after-free.
>>>
>>
>> Thanks for checking.
>>
>> I agree that this does not look like an IIO-specific issue from the trace. The crash
>> is reported from hid_sensor_custom_poll() in drivers/hid/hid-sensor-custom.c.
^ permalink raw reply
* [PATCH] Input: sur40: fix MAX_CONTACTS value based on PixelSense specification
From: Oliver @ 2026-06-14 23:08 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: kees, linux-input, linux-kernel, Oliver
The Samsung SUR40 with Microsoft PixelSense is offically specified to
support 52 simultaneuous touch contacts, not 64. The value of 64 was an
unverified guess as noted by the FIXME comment. Update MAX_CONTACTS to
match the documented hardware specification and remove the FIXME.
Signed-off-by: Oliver <oliverburns.kernel@gmail.com>
---
drivers/input/touchscreen/sur40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c
index fe63d53d56db..77ec2c94b91f 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -128,8 +128,8 @@ struct sur40_image_header {
/* polling interval (ms) */
#define POLL_INTERVAL 1
-/* maximum number of contacts FIXME: this is a guess? */
-#define MAX_CONTACTS 64
+/* maximum number of contacts */
+#define MAX_CONTACTS 52
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Input: sur40: fix MAX_CONTACTS value based on PixelSense specification
From: sashiko-bot @ 2026-06-14 23:26 UTC (permalink / raw)
To: Oliver; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260614230847.4938-1-oliverburns.kernel@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Synchronously freeing the driver state in `sur40_disconnect()` while the V4L2 device may still be open leads to use-after-free vulnerabilities.
- [High] The error path in `sur40_probe` incorrectly calls `input_free_device()` on a successfully registered input device instead of `input_unregister_device()`, leading to potential use-after-free and state corruption.
- [High] The input device is registered and exposed to userspace before the driver's private video queue and V4L2 components are fully initialized.
--
commit 36ed451619f33b71bb9cc6a733570423cba1565e
Author: Oliver <oliverburns.kernel@gmail.com>
Input: sur40: fix MAX_CONTACTS value based on PixelSense specification
This patch updates the maximum number of contacts for the Samsung SUR40
touchscreen to 52 to match the documented hardware specification. It also
removes an older FIXME comment that guessed the maximum contacts was 64.
> diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c
> index fe63d53d56db0..77ec2c94b91fd 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
[ ... ]
> @@ -128,8 +128,8 @@ struct sur40_image_header {
> /* polling interval (ms) */
> #define POLL_INTERVAL 1
>
> -/* maximum number of contacts FIXME: this is a guess? */
> -#define MAX_CONTACTS 64
> +/* maximum number of contacts */
> +#define MAX_CONTACTS 52
>
> /* control commands */
> #define SUR40_GET_VERSION 0xb0 /* 12 bytes string */
[Severity: High]
This isn't a bug introduced by this patch, but I noticed something in
sur40_probe(). The input device is registered and exposed to userspace
before the driver's private video queue and V4L2 components are fully
initialized:
drivers/input/touchscreen/sur40.c:sur40_probe() {
...
/* register the polled input device */
error = input_register_device(input);
if (error) {
dev_err(&interface->dev,
"Unable to register polled input device.");
goto err_free_buffer;
}
...
/* initialize the queue */
error = vb2_queue_init(&sur40->queue);
...
}
Does this leave a window where an open operation could trigger sur40_open()
and start the sur40_poll() worker thread? If the worker thread invokes
sur40_process_video() and checks vb2_start_streaming_called(&sur40->queue)
concurrently with the main thread's initialization, could this cause a data
race regression on partially initialized structures?
[Severity: High]
This is a pre-existing issue, but looking at the sur40_probe() error handling,
if a failure occurs after the input device is successfully registered, the
code jumps to error labels that fall through to err_free_input:
drivers/input/touchscreen/sur40.c:sur40_probe() {
...
err_unreg_video:
video_unregister_device(&sur40->vdev);
err_unreg_v4l2:
v4l2_device_unregister(&sur40->v4l2);
err_free_buffer:
kfree(sur40->bulk_in_buffer);
err_free_input:
input_free_device(input);
err_free_dev:
kfree(sur40);
return error;
}
Can calling input_free_device() on a successfully registered device lead
to state corruption? If a userspace process opens this lingering device node,
would the polling thread dereference the freed sur40 pointer and cause a
use-after-free regression on the error path? It seems like
input_unregister_device() should be used instead.
[Severity: Critical]
This is also a pre-existing issue, but I noticed sur40_disconnect()
synchronously frees the driver state while the V4L2 device may still be open:
drivers/input/touchscreen/sur40.c:sur40_disconnect() {
struct sur40_state *sur40 = usb_get_intfdata(interface);
v4l2_ctrl_handler_free(&sur40->hdl);
video_unregister_device(&sur40->vdev);
v4l2_device_unregister(&sur40->v4l2);
input_unregister_device(sur40->input);
kfree(sur40->bulk_in_buffer);
kfree(sur40);
...
}
Could this lead to a use-after-free regression? If userspace holds a
file descriptor open to the video device during a USB disconnect,
video_unregister_device() does not forcefully close the active file
descriptor. When userspace later calls ioctl(), poll(), or close() on the
descriptor, wouldn't the V4L2 core invoke file operations like
vb2_fop_release() which dereference the already freed sur40 memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614230847.4938-1-oliverburns.kernel@gmail.com?part=1
^ permalink raw reply
* [BUG] Input: rmi4: KASAN slab-use-after-free in v4l2_release
From: Shuangpeng Bai @ 2026-06-15 1:45 UTC (permalink / raw)
To: dmitry.torokhov, mchehab, linux-input, linux-media, linux-kernel
Hi input and media maintainers,
I hit the following report while testing current upstream kernel:
Input: rmi4: KASAN slab-use-after-free in v4l2_release
The issue was reproduced by holding an rmi4_f54 /dev/v4l-touch node open,
unbinding the rmi4_f54 function, and then closing the held fd.
I am not sure whether this is specific to rmi_f54 or a more generic V4L2
lifetime issue.
I reproduced this on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
To help trigger the bug more reliably, we applied a minimal diagnostic patch
that only adds delays and print statements.
The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/351f125869016d5ce915cbc113abb547
I'm happy to test debug patches or provide additional information.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
[ 87.788267][ T8430] BUG: KASAN: slab-use-after-free in v4l2_release (drivers/media/v4l2-core/v4l2-dev.c:466)
[ 87.790392][ T8430] Read of size 8 at addr ffff8881748dc588 by task rmi_f54_hold_cl/8430
[ 87.790944][ T8430]
[ 87.791114][ T8430] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 87.791116][ T8430] Call Trace:
[ 87.791119][ T8430] <TASK>
[ 87.791121][ T8430] dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 87.791125][ T8430] print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 87.791137][ T8430] kasan_report (mm/kasan/report.c:595)
[ 87.791143][ T8430] v4l2_release (drivers/media/v4l2-core/v4l2-dev.c:466)
[ 87.791146][ T8430] __fput (fs/file_table.c:510)
[ 87.791150][ T8430] fput_close_sync (fs/file_table.c:615)
[ 87.791695][ T8430] __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)
[ 87.791698][ T8430] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 87.791701][ T8430] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 87.791704][ T8430] RIP: 0033:0x7fe62d972c03
[ 87.791708][ T8430] Code: e9 37 ff ff ff e8 2d f9 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
[ 87.791710][ T8430] RSP: 002b:00007ffdc1dc6588 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[ 87.791715][ T8430] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fe62d972c03
[ 87.791717][ T8430] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
[ 87.791718][ T8430] RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe62da160c0
[ 87.791720][ T8430] R10: fffffffffffffc0d R11: 0000000000000246 R12: 0000000000000004
[ 87.791722][ T8430] R13: 00007ffdc1dc66d0 R14: 00007ffdc1dc65d0 R15: 0000000000000000
[ 87.791725][ T8430] </TASK>
[ 87.791727][ T8430]
[ 87.803468][ T8430] Freed by task 8430 on cpu 1 at 87.787459s:
[ 87.803881][ T8430] kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[ 87.804205][ T8430] kasan_save_free_info (mm/kasan/generic.c:584)
[ 87.804556][ T8430] __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[ 87.804885][ T8430] kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[ 87.805157][ T8430] devres_release_all (drivers/base/devres.c:50 drivers/base/devres.c:547 drivers/base/devres.c:576)
[ 87.805504][ T8430] device_release_driver_internal (drivers/base/dd.c:598 drivers/base/dd.c:1357 drivers/base/dd.c:1375)
[ 87.805929][ T8430] unbind_store (drivers/base/bus.c:244)
[ 87.806246][ T8430] kernfs_fop_write_iter (fs/kernfs/file.c:352)
[ 87.806616][ T8430] vfs_write (fs/read_write.c:595 fs/read_write.c:688)
[ 87.806914][ T8430] ksys_write (fs/read_write.c:740)
[ 87.807214][ T8430] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 87.807542][ T8430] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 87.807955][ T8430]
[ 87.808124][ T8430] The buggy address belongs to the object at ffff8881748dc000
[ 87.808124][ T8430] which belongs to the cache kmalloc-4k of size 4096
[ 87.809083][ T8430] The buggy address is located 1416 bytes inside of
[ 87.809083][ T8430] freed 4096-byte region [ffff8881748dc000, ffff8881748dd000)
[ 87.810030][ T8430]
Best,
Shuangpeng
^ permalink raw reply
* [BUG] Input: sur40: KASAN slab-use-after-free in v4l2_release
From: Shuangpeng Bai @ 2026-06-15 2:06 UTC (permalink / raw)
To: Dmitry Torokhov, Mauro Carvalho Chehab, linux-input, linux-media,
linux-kernel
Hi,
I hit the following KASAN report while testing current upstream kernel.
The issue was reproduced with the sur40 driver. The report shows the object
being freed from sur40_disconnect(), then v4l2_release() accesses it when the
held V4L2 fd is closed. I have not confirmed whether this is specific to sur40
or a more generic V4L2 lifetime issue.
This looks similar to the rmi4_f54 V4L2 fd lifetime report I sent earlier:
https://lore.kernel.org/all/178144969601.60470.13645789994911690209@gmail.com/
That report involved rmi4_f54; in this report the freeing path is
sur40_disconnect().
KASAN: slab-use-after-free in v4l2_release (sur40)
I reproduced this on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/40c7b5bde2a7b2ddf95981beaebc0eed
I'm happy to test debug patches or provide additional information.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
[ 323.412431][ T8724] BUG: KASAN: slab-use-after-free in v4l2_release (drivers/media/v4l2-core/v4l2-dev.c:466)
[ 323.414158][ T8724] Read of size 8 at addr ffff888120d94458 by task repro_sur40_v4l/8724
[ 323.415722][ T8724]
[ 323.416236][ T8724] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 323.416240][ T8724] Call Trace:
[ 323.416251][ T8724] <TASK>
[ 323.416256][ T8724] dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 323.416279][ T8724] print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 323.416357][ T8724] kasan_report (mm/kasan/report.c:595)
[ 323.416370][ T8724] v4l2_release (drivers/media/v4l2-core/v4l2-dev.c:466)
[ 323.416375][ T8724] __fput (fs/file_table.c:510)
[ 323.416398][ T8724] fput_close_sync (fs/file_table.c:615)
[ 323.416447][ T8724] __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)
[ 323.416469][ T8724] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 323.416491][ T8724] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 323.416497][ T8724] RIP: 0033:0x7fe066183c03
[ 323.416504][ T8724] Code: e9 37 ff ff ff e8 2d f9 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
[ 323.416509][ T8724] RSP: 002b:00007ffdf8e8ecf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[ 323.416524][ T8724] RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007fe066183c03
[ 323.416528][ T8724] RDX: 01dd73bc7995e62a RSI: 0000000000000000 RDI: 000000000000000b
[ 323.416531][ T8724] RBP: 0000000000000001 R08: 0000000000000009 R09: 0000000000000000
[ 323.416534][ T8724] R10: 00007fe066129dd0 R11: 0000000000000246 R12: 0000000000000001
[ 323.416537][ T8724] R13: 0000557a10ca7090 R14: 00007ffdf8e8eda0 R15: 0000000000000000
[ 323.416544][ T8724] </TASK>
[ 323.416546][ T8724]
[ 323.430976][ T8724] Freed by task 31 on cpu 1 at 322.408638s:
[ 323.431417][ T8724] kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[ 323.431795][ T8724] kasan_save_free_info (mm/kasan/generic.c:584)
[ 323.432193][ T8724] __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[ 323.432615][ T8724] kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[ 323.433289][ T8724] sur40_disconnect (drivers/input/touchscreen/sur40.c:832)
[ 323.433680][ T8724] usb_unbind_interface (drivers/usb/core/driver.c:458)
[ 323.434121][ T8724] device_release_driver_internal (drivers/base/dd.c:621 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
[ 323.434605][ T8724] bus_remove_device (drivers/base/bus.c:657)
[ 323.435042][ T8724] device_del (drivers/base/core.c:3895)
[ 323.435481][ T8724] usb_disable_device (drivers/usb/core/message.c:1478)
[ 323.436006][ T8724] usb_disconnect (drivers/usb/core/hub.c:2315)
[ 323.436489][ T8724] hub_event (drivers/usb/core/hub.c:5407 drivers/usb/core/hub.c:5707 drivers/usb/core/hub.c:5871 drivers/usb/core/hub.c:5953)
[ 323.436825][ T8724] process_scheduled_works (kernel/workqueue.c:3314 kernel/workqueue.c:3397)
[ 323.437403][ T8724] worker_thread (kernel/workqueue.c:3478)
[ 323.437873][ T8724] kthread (kernel/kthread.c:436)
[ 323.438298][ T8724] ret_from_fork (kernel/process.c:158)
[ 323.438778][ T8724] ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
[ 323.439277][ T8724]
[ 323.439513][ T8724] The buggy address belongs to the object at ffff888120d94000
[ 323.439513][ T8724] which belongs to the cache kmalloc-4k of size 4096
[ 323.440921][ T8724] The buggy address is located 1112 bytes inside of
[ 323.440921][ T8724] freed 4096-byte region [ffff888120d94000, ffff888120d95000)
[ 323.442314][ T8724]
Best,
Shuangpeng
^ permalink raw reply
* Re: [PATCH v2 4/4] Input: snvs_pwrkey - report press event in interrupt handler
From: Joy Zou @ 2026-06-15 3:52 UTC (permalink / raw)
To: Bough Chen
Cc: Joy Zou, Dmitry Torokhov, Frank Li, Peng Fan, Jacky Bai, Ye Li,
imx, linux-input, linux-kernel
In-Reply-To: <20260605065913.grovxx53yzvi6yxj@nxp.com>
On Fri, Jun 05, 2026 at 02:59:13PM +0800, Bough Chen wrote:
> On Thu, Jun 04, 2026 at 02:56:24PM +0800, Joy Zou wrote:
> > 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.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > ---
> > Changes for v2:
> > 1. Add a boolean variable suspended and PM callback functions to replace
> > the use of the is_suspended field per AI review comments.
> > 2. Move event report handle to else branch in suspended state, since the
> > pdata->minor_rev == 0 branch has no debounce detection per AI review
> > comments.
> > 3. Modify the commit message.
> > ---
> > drivers/input/keyboard/snvs_pwrkey.c | 35 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > index 4a1d04898482669894e9978014b62e4e9774b4e4..f212a6b26185d13e1af62728e7b2add5010adc5a 100644
> > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > @@ -39,6 +39,7 @@ struct pwrkey_drv_data {
> > int keycode;
> > int keystate; /* 1:pressed */
> > int wakeup;
> > + bool suspended; /* Track suspend state */
> > struct timer_list check_timer;
> > struct input_dev *input;
> > u8 minor_rev;
> > @@ -92,6 +93,15 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> > input_sync(input);
> > pm_relax(input->dev.parent);
> > } else {
> > + /*
> > + * Report key press events directly in interrupt handler to prevent event
> > + * loss during system suspend.
> > + */
> > + if (pdata->suspended) {
>
> Here, pdata->suspended should not be safe for SMP system, maybe to use atomic_read() to make the code more stronger.
Thanks for your comments! You're right that pdata->suspended needs protection.
However, AI review found there are the pdata->keystate that also need protection.
Instead of using atomic operations for individual fields, I think it would be
more maintainable to use a single lock to protect all related fields consistently.
>
> > + pdata->keystate = 1;
> > + input_report_key(input, pdata->keycode, 1);
> > + input_sync(input);
> > + }
> > mod_timer(&pdata->check_timer,
> > jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
>
> Here already report the key when pdata->suspend == true, seems do not need to trigger the timer again.
> Is it more reasonable to change like this?
> if (atomic_read(&pdata->suspended)) {
> ...
> } else {
> mode_timer()
> }
Have checked the interrupt handler only report directly press event, still need
to report release event in timer callback. So can't use the way.
BR
Joy Zou
>
> > }
> > @@ -219,6 +229,30 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
> > return 0;
> > }
> >
> > +static int __maybe_unused imx_snvs_pwrkey_suspend(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> > +
> > + pdata->suspended = true;
> > +
>
> atomic_set(&pdata->suspended, 1)
>
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused imx_snvs_pwrkey_resume(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> > +
> > + pdata->suspended = false;
> > +
>
> atomic_set(&pdata->suspended, 0);
>
> Regards
> Haibo Chen
> > + return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(imx_snvs_pwrkey_pm_ops,
> > + imx_snvs_pwrkey_suspend,
> > + imx_snvs_pwrkey_resume);
> > +
> > static const struct of_device_id imx_snvs_pwrkey_ids[] = {
> > { .compatible = "fsl,sec-v4.0-pwrkey" },
> > { /* sentinel */ }
> > @@ -229,6 +263,7 @@ static struct platform_driver imx_snvs_pwrkey_driver = {
> > .driver = {
> > .name = "snvs_pwrkey",
> > .of_match_table = imx_snvs_pwrkey_ids,
> > + .pm = &imx_snvs_pwrkey_pm_ops,
> > },
> > .probe = imx_snvs_pwrkey_probe,
> > };
> >
> > --
> > 2.50.1
> >
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-06-15 6:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n3Dw6Vtqqn8if=MYkBbYittXqsBKbDvrs1ntbD5Zn6iig@mail.gmail.com>
чт, 28 трав. 2026 р. о 08:38 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> вт, 12 трав. 2026 р. о 13:24 Svyatoslav Ryhel <clamor95@gmail.com> пише:
> >
> > From: Linus Walleij <linusw@kernel.org>
> >
> > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > motors for haptic feedback in mobile phones. Used in many mobile devices
> > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/input/misc/Kconfig | 12 +
> > drivers/input/misc/Makefile | 1 +
> > drivers/input/misc/isa1200.c | 524 +++++++++++++++++++++++++++++++++++
> > 3 files changed, 537 insertions(+)
> > create mode 100644 drivers/input/misc/isa1200.c
> >
>
> Hello Dmitry! Do I need to make any further adjustments to this driver?
Hello Dmitry! Do I need to make any further adjustments to this
driver? This driver is hanging in LKML for some time already without
responds from input maintainer. It is still relevant and I would like
it to move forward.
^ permalink raw reply
* Re: [PATCH v8 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: Svyatoslav Ryhel @ 2026-06-15 6:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, Svyatoslav Ryhel, devicetree,
linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-4-clamor95@gmail.com>
чт, 28 трав. 2026 р. о 08:32 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add input driver for ASUS Transformer dock keyboard and touchpad.
>
> Some keys in ASUS Dock report keycodes that don't make sense according to
> their position, this patch modifies the incoming data that is sent to
> serio to send proper scancodes.
>
> Co-developed-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/serio/Kconfig | 15 ++
> drivers/input/serio/Makefile | 1 +
> drivers/input/serio/asus-transformer-ec-kbc.c | 158 ++++++++++++++++++
> 3 files changed, 174 insertions(+)
> create mode 100644 drivers/input/serio/asus-transformer-ec-kbc.c
Hello Dmitry! May you please take a look and Ack it if you are fine
this this driver or tell what I should adjust? That would be very
helpful. Thank you.
^ permalink raw reply
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: Svyatoslav Ryhel @ 2026-06-15 6:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Michał Mirosław,
Ion Agorria, Svyatoslav Ryhel, Sebastian Reichel, Pavel Machek,
Lee Jones, Conor Dooley, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-5-clamor95@gmail.com>
чт, 28 трав. 2026 р. о 08:32 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add support for multimedia top button row of ASUS Transformer's Mobile
> Dock keyboard. Driver is made that function keys (F1-F12) are used by
> default which suits average Linux use better and with pressing
> ScreenLock + AltGr function keys layout is switched to multimedia keys.
> Since this only modifies codes sent by asus-ec-keys it doesn't affect
> normal keyboards at all.
>
> Co-developed-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/keyboard/Kconfig | 10 +
> drivers/input/keyboard/Makefile | 1 +
> .../input/keyboard/asus-transformer-ec-keys.c | 286 ++++++++++++++++++
> 3 files changed, 297 insertions(+)
> create mode 100644 drivers/input/keyboard/asus-transformer-ec-keys.c
>
Hello Dmitry! May you please take a look and Ack it if you are fine
this this driver or tell what I should adjust? That would be very
helpful. Thank you.
^ permalink raw reply
* Re: [PATCH v6 0/6] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-06-15 6:25 UTC (permalink / raw)
To: Lee Jones
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260527151432.GE671544@google.com>
ср, 27 трав. 2026 р. о 18:14 Lee Jones <lee@kernel.org> пише:
>
> On Wed, 20 May 2026, Svyatoslav Ryhel wrote:
>
> > The initial goal was only to add support for the CPCAP used in the Mot
> > Tegra20 board; however, since the documentation was already partially
> > converted, I decided to complete the conversion to schema too.
> >
> > The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
> > from TXT to YAML while preserving the original structure. Mot board
> > compatibility was added to the regulator and core schema. Since these
> > were one-line patches, they were not separated into dedicated commits;
> > however, the commit message notes this for both cases.
> >
> > Finally, the CPCAP MFD was slightly refactored to improve support for
> > multiple subcell compositions.
>
> Once you've fixed the DT issues that Rob pointed out, I'll merge the set.
Hello Lee! This patchset already contains fixes Rob pointed to. May
you please merge it?
> --
> Lee Jones
^ permalink raw reply
* [PATCH v7 0/9] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-15 7:16 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Julien Massot, Louis-Alexis Eyraud, Val Packett,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
The MediaTek MT6392 PMIC is usually found on devices powered by
the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
This series is mostly based around patches submitted a couple
years ago by Fabien Parent and not merged and from Val Packett's
submission from Jan 2025 that included extra cleanups, fixes, and a
new dtsi file similar to ones that exist for other PMICs. Some
comments weren't addressed and the series was ultimately not merged.
These patches enable four functions: keys, regulator, pinctrl and RTC.
Mono speaker amp will follow later as I need to work further on the
audio codec.
I added a handful of device tree improvements to fix some dtbs_check
errors, added support for the pinctrl device and addressed the comments
from last year's reviews.
Please note that patch 0006 and 0008 depend on patch 0005 as they need the
registers.h file, but belong to different driver areas. I'm not sure if
I'm supposed to squash them even if they belong to different driver
areas of if it's fine like this. Any advice is welcome.
The series has been tested on Xiaomi Mi Smart Clock X04G and on the
Lenovo Smart Clock 2 CD-24502F.
Changes in v7:
- Removed patch 0008 dependency on patch 0003.
- Reintroduced the regulator driver. In earlier revisions of this series,
it was proposed to remove the dedicated compatible for the regulator
device [3]. The driver does not use actually it, but it is not possible
at this time to remove it from the bindings since it's a required
property.
Making the regulator-required property conditional was NACKed in [5],
with the suggestion to create a separate binding altogether for devices
that do not require the compatible property. I tried implementing this,
but since the parent device needs to be declared as compatible with
mt6323, it leads to a warning in dt_binding_check since mt6323 would
be declared as a compatible in both mt6392 and mt6397.
In the end the only regulator driver from the mt6397 documentation that
still declares an of_match is mt6397-regulator and it does not seem
to be necessary, so it should be possible to remove it and make the
regulator compatible optional for all regulators, but that change would
probably deserve its own separate patch series.
Changes in v6 [6]:
- Dropped the regulators driver for the moment
- Explained the FCHR key name origin in the commit message
- Introduced the MFD_CELL_* macro in the sub-devices definitions.
A separate, independent commit introduced MFD_CELL_* to all the
subdevices in the mt6397-core.c file for consistency
- Replaced of_device_get_match_data with device_get_match_data
- Removed the mfd_match_data enum in favor of the preexisting
chip_id enum
- Adjusted the error message if the device is unsupported
Changes in v5 [5]:
- Double checked regulator driver with data sheet and Android sources.
The data sheet I have misses a lot of register descriptions, but
Android sources have been helpful to fill the gaps
- Reintroduced the required attribute for the regulator compatible
in the bindings
- Fixed the missing reference to the MT6392 schema
- Fixed casts/unused vars reported by kernel test robot
- Removed Reviewed-by tags from the regulator patches as they have been
modified in this version
Changes in v4 [4]:
- Dropped usage of the regulator compatible
- Fixed commit messages text to properly reference the target subsystem
- Added supply rails to the regulator
- Reworked the regulator schema and PMIC dtsi. Now all supplies are
documented and the schema no longer includes voltage information
- Removed redundant ldo- / buck- prefixes
- Renamed the pinfunc header to mediatek,mt6392-pinfunc.h
- Modified the MFD driver to use a simple identifier in the of_match
data properties
Changes in v3 [3]:
- Added pinctrl device
- Changed mt6397-rtc fallback to mt6323-rtc
- Added schema for regulators
- Fixed checkpatch issues
Changes in v2 [2]:
- Replaced explicit compatibles with fallbacks
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/cover.1771865014.git.l.scorcia@gmail.com/
[2] https://lore.kernel.org/linux-mediatek/20260306120521.163654-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260317184507.523060-1-l.scorcia@gmail.com/
[4] https://lore.kernel.org/linux-mediatek/20260330083429.359819-1-l.scorcia@gmail.com/
[5] https://lore.kernel.org/linux-mediatek/20260420213529.1645560-1-l.scorcia@gmail.com/
[6] https://lore.kernel.org/linux-mediatek/20260612200717.361018-1-l.scorcia@gmail.com/
Fabien Parent (3):
dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
mfd: mt6397: Add support for MT6392 PMIC
regulator: Add MediaTek MT6392 regulator
Luca Leonardo Scorcia (4):
dt-bindings: mfd: mt6397: Add MT6392 PMIC
regulator: dt-bindings: Add MediaTek MT6392 PMIC
mfd: mt6397: Use MFD_CELL_* to describe sub-devices
pinctrl: mediatek: mt6397: Add MediaTek MT6392
Val Packett (2):
input: keyboard: mtk-pmic-keys: Add MT6392 support
arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
.../bindings/input/mediatek,pmic-keys.yaml | 1 +
.../bindings/mfd/mediatek,mt6397.yaml | 9 +
.../regulator/mediatek,mt6392-regulator.yaml | 234 ++++++
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++
drivers/input/keyboard/mtk-pmic-keys.c | 17 +
drivers/mfd/mt6397-core.c | 295 ++++---
drivers/mfd/mt6397-irq.c | 8 +
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 +-
drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 ++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6392-regulator.c | 756 ++++++++++++++++++
.../regulator/mediatek,mt6392-regulator.h | 24 +
include/linux/mfd/mt6392/core.h | 43 +
include/linux/mfd/mt6392/registers.h | 488 +++++++++++
include/linux/mfd/mt6397/core.h | 1 +
include/linux/regulator/mt6392-regulator.h | 42 +
17 files changed, 1942 insertions(+), 162 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
create mode 100644 drivers/regulator/mt6392-regulator.c
create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
create mode 100644 include/linux/mfd/mt6392/core.h
create mode 100644 include/linux/mfd/mt6392/registers.h
create mode 100644 include/linux/regulator/mt6392-regulator.h
--
2.43.0
^ permalink raw reply
* [PATCH v7 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-15 7:16 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Julien Massot, Val Packett, Louis-Alexis Eyraud,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260615071836.362883-1-l.scorcia@gmail.com>
Describe the MT6392 PMIC and its RTC and regulator devices. This device
is mostly based on MT6323 with some similarities to MT6397 and is usually
found on boards using the MT8516/MT8167 SoC.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 3cbc0dc12c31..8b14956af4fc 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -40,6 +40,10 @@ properties:
- mediatek,mt6358
- mediatek,mt6359
- mediatek,mt6397
+ - items:
+ - enum:
+ - mediatek,mt6392
+ - const: mediatek,mt6323
- items:
- enum:
- mediatek,mt6366
@@ -72,6 +76,10 @@ properties:
- mediatek,mt6331-rtc
- mediatek,mt6358-rtc
- mediatek,mt6397-rtc
+ - items:
+ - enum:
+ - mediatek,mt6392-rtc
+ - const: mediatek,mt6323-rtc
- items:
- enum:
- mediatek,mt6359-rtc
@@ -99,6 +107,7 @@ properties:
- mediatek,mt6331-regulator
- mediatek,mt6358-regulator
- mediatek,mt6359-regulator
+ - mediatek,mt6392-regulator
- mediatek,mt6397-regulator
- items:
- enum:
--
2.43.0
^ permalink raw reply related
* [PATCH v7 2/9] dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
From: Luca Leonardo Scorcia @ 2026-06-15 7:16 UTC (permalink / raw)
To: linux-mediatek
Cc: 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, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Akari Tsuyukusa, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260615071836.362883-1-l.scorcia@gmail.com>
From: Fabien Parent <parent.f@gmail.com>
Add the binding documentation of mtk-pmic-keys for the MT6392 PMIC.
Signed-off-by: Fabien Parent <parent.f@gmail.com>
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
index 140a862ecfbe..ff720588128b 100644
--- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -31,6 +31,7 @@ properties:
- mediatek,mt6357-keys
- mediatek,mt6358-keys
- mediatek,mt6359-keys
+ - mediatek,mt6392-keys
- mediatek,mt6397-keys
- items:
- enum:
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox