* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Michal Simek @ 2026-06-02 8:34 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-input, Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <CAKxU2N-M+vDeDKtYa6=M-4kazOUrGTrwJfHoF6Z+od1OZ-VBpw@mail.gmail.com>
On 6/2/26 10:27, Rosen Penev wrote:
> On Mon, Jun 1, 2026 at 11:23 PM Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 6/2/26 05:59, Rosen Penev wrote:
>>> Mechanical conversion of the ppc4xx-specific accessors to the generic
>>> portable helpers.
>>>
>>> Allows enabling COMPILE_TEST for extra compile coverage.
>>>
>>> Assisted-by: opencode:big-pickle
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>> drivers/input/serio/Kconfig | 2 +-
>>> drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
>>
>> I don't think that anybody is really using this driver and would be better to
>> just remove it.
>> If not, no issue with that changes.
> I have no problem with removing.
Can you please send a patch for it?
Thanks,
Michal
^ permalink raw reply
* RE: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: Xu, Even @ 2026-06-02 8:47 UTC (permalink / raw)
To: d3z, Sun, Xinpeng, jikos@kernel.org, bentiss@kernel.org
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
abhishektamboli9@gmail.com, sakari.ailus@linux.intel.com
In-Reply-To: <20260601213047.115271-1-d3z.the.dev@gmail.com>
Hi, Danny,
Nice to meet you!
Thank you very much for your testing and description detail.
According to current situation you described on Surface Pro 10, there are two issues we need to identify separately:
1. Touch IC was powered off
According to your description, Touch IC power off can be confirmed.
In this case, only reset_tic() call is needed for touch IC recovery.
2. THC was power gated
THC power gated is another story, generally speaking, if device doesn't go into PM_SUSPEND_MEM, THC shouldn't be power gated. If so, other API calls to recovery THC state maybe unnecessary.
We need to identify this case.
So can you help do a test: just only add reset_tic(), to check if touch device can recovery during suspend/resume.
Then we can identify if THC was power gated.
Thanks!
Best Regards,
Even Xu
> -----Original Message-----
> From: d3z <d3z.the.dev@gmail.com>
> Sent: Tuesday, June 2, 2026 5:31 AM
> To: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <xinpeng.sun@intel.com>;
> jikos@kernel.org; bentiss@kernel.org
> Cc: Danny D . <d3z.the.dev@gmail.com>; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; abhishektamboli9@gmail.com;
> sakari.ailus@linux.intel.com
> Subject: Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system
> resume
>
> From: Danny D. <d3z.the.dev@gmail.com>
>
> Hi Even,
>
> Thanks for the quick reply and for sharing your patch.
>
> First, the missing piece from your mail: my name is Danny D.
> (d3z.the.dev@gmail.com) - please use it for any Signed-off-by/Reported-
> by/Tested-by.
>
> One note on the starting assumption, though: in its current configuration this
> Surface Pro 10 doesn't go to S3 at all. /sys/power/mem_sleep only offers s2idle:
>
> $ cat /sys/power/mem_sleep
> [s2idle]
>
> There's no "deep" entry to select here, so every suspend goes through s2idle and
> never reaches PM_SUSPEND_MEM. The touch IC still loses power across that
> s2idle suspend - the same as over hibernation - which is what gives the "recv
> failed: -11" on resume.
>
> That's the catch with the attached patch: it gates the THC reconfigure on
>
> if (last_suspend_state == PM_SUSPEND_MEM)
>
> i.e. S3 only. On this machine that branch never runs, so it wouldn't bring the
> touchscreen back here. Happy to apply it and confirm on the device, but from the
> code path alone it can't help while we're s2idle-only.
>
> What I did instead was key off whether the device actually kept power rather
> than the suspend type: run the full reset only when the device isn't a wake source
> (device_may_wakeup() == false), mirroring quickspi_restore().
> A wake-enabled device stays on the light path so wake-on-touch is preserved;
> one that lost power goes through reset_tic() re-enumeration. That fires on both
> s2idle and S3, which is what makes it work on the SP10.
>
> I've tested this on the Surface Pro 10 across many s2idle suspend/resume cycles -
> touch and pen both keep working - and just posted a v2 that adds the
> device_may_wakeup() gate.
>
> Could we converge on the wakeup-based condition? I'm glad to test any revision
> of your patch on the hardware, and equally glad for you to carry the fix with my
> Signed-off-by/Tested-by once it handles the s2idle case.
>
> Thanks,
> Danny
^ permalink raw reply
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-02 8:51 UTC (permalink / raw)
To: Michal Simek
Cc: linux-input, Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <b9e06f81-2b18-4cc3-8974-6df9063b02cf@amd.com>
On Tue, Jun 2, 2026 at 1:34 AM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/2/26 10:27, Rosen Penev wrote:
> > On Mon, Jun 1, 2026 at 11:23 PM Michal Simek <michal.simek@amd.com> wrote:
> >>
> >>
> >>
> >> On 6/2/26 05:59, Rosen Penev wrote:
> >>> Mechanical conversion of the ppc4xx-specific accessors to the generic
> >>> portable helpers.
> >>>
> >>> Allows enabling COMPILE_TEST for extra compile coverage.
> >>>
> >>> Assisted-by: opencode:big-pickle
> >>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>> ---
> >>> drivers/input/serio/Kconfig | 2 +-
> >>> drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
> >>
> >> I don't think that anybody is really using this driver and would be better to
> >> just remove it.
> >> If not, no issue with that changes.
> > I have no problem with removing.
>
> Can you please send a patch for it?
Out of curiosity, I made a deep research AI prompt. Last known user it
gave me was from 2012. Github code search however gave me a user from
5 or 6 years ago.
https://github.com/danielkasza/9444/blob/master/firmware/xilinx-fpga/genesys2.dts
Maybe someone knows more.
>
> Thanks,
> Michal
^ permalink raw reply
* [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: steven @ 2026-06-02 9:55 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Chen-Yu Tsai, linux-input, linux-kernel, Steven Feng
From: Steven Feng <steven@joint-cloud.com>
Add power button support for the AXP313A PMIC. The AXP313A uses
the same register layout and timing parameters as the AXP20X,
so we can reuse the existing axp20x_info structure.
Signed-off-by: Steven Feng <steven@joint-cloud.com>
---
drivers/input/misc/axp20x-pek.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 24f9e9d893de..d4e2fc9a937f 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
.name = "axp221-pek",
.driver_data = (kernel_ulong_t)&axp221_info,
},
+ {
+ .name = "axp313a-pek",
+ .driver_data = (kernel_ulong_t)&axp20x_info,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: sashiko-bot @ 2026-06-02 10:10 UTC (permalink / raw)
To: steven; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <tencent_5F1FF80489E702360F352F889570656BF608@qq.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Sysfs attributes 'startup' and 'shutdown' are unconditionally broken for the newly added AXP313A device due to out-of-bounds regmap access.
Pre-existing issues:
- [High] Unconditional manipulation of uninitialized IRQ 0 during system suspend and resume when input device registration is bypassed.
--
commit 689d64caa4b9f21a0926e40a611d5111bfe37d22
Author: Steven Feng <steven@joint-cloud.com>
Input: axp20x-pek - add support for AXP313A variant
This commit adds power button support for the AXP313A PMIC. It reuses the
existing axp20x_info structure, noting that the AXP313A shares the same
register layout and timing parameters as the AXP20X.
> diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
> index 24f9e9d893de3..d4e2fc9a937ff 100644
> --- a/drivers/input/misc/axp20x-pek.c
> +++ b/drivers/input/misc/axp20x-pek.c
> @@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
> .name = "axp221-pek",
> .driver_data = (kernel_ulong_t)&axp221_info,
> },
> + {
> + .name = "axp313a-pek",
> + .driver_data = (kernel_ulong_t)&axp20x_info,
[Severity: Medium]
Will reusing axp20x_info for the AXP313A break the sysfs attributes?
The axp20x_info struct exposes the startup and shutdown sysfs attributes.
When these are accessed, the driver reads or updates AXP20X_PEK_KEY (0x36):
drivers/input/misc/axp20x-pek.c:axp20x_show_attr() {
...
ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
...
}
However, the AXP313A regmap configuration restricts max_register to 0x21
(AXP313A_IRQ_STATE). Won't the regmap core reject accesses to 0x36 with
-EINVAL, making these sysfs attributes non-functional for this device?
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
[Severity: High]
This is a pre-existing issue, but could the suspend and resume handlers crash
the system if input device registration is skipped?
In axp20x_pek_suspend() and axp20x_pek_resume(), the driver unconditionally
calls disable_irq() and enable_irq():
drivers/input/misc/axp20x-pek.c:axp20x_pek_suspend() {
...
if (device_may_wakeup(dev)) {
...
} else {
disable_irq(axp20x_pek->irq_dbf);
disable_irq(axp20x_pek->irq_dbr);
}
...
}
If axp20x_pek_should_register_input() returns false (for instance, on x86
systems where ACPI handles the power button), the IRQs are never initialized
and remain 0.
Does calling disable_irq(0) disable the system timer interrupt on x86,
potentially causing a system hang or panic during the suspend cycle?
--
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_5F1FF80489E702360F352F889570656BF608@qq.com?part=1
^ permalink raw reply
* [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 10:24 UTC (permalink / raw)
To: regressions; +Cc: linux-input, linux-kernel, linux-bluetooth
Hitting this repeatedly with v7.1-rc6. Do not have time right now to
bisect it (and there are two other regressions at the same time).
Symptom is unable to use the Bluetooth keyboard.
It *seems* to be related to the Bluetooth keyboard - trying to shutdown
hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
and then fails to power-off (see end of log extracts).
I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
adapter nor the keyboard are Samsung but maybe some change related to
that is causing this.
Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
Jun 02 09:25:54 sunny kernel: Call Trace:
Jun 02 09:25:54 sunny kernel: <TASK>
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
Jun 02 09:25:54 sunny kernel: 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>
Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
Jun 02 09:25:54 sunny kernel: </TASK>
Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Thorsten Leemhuis @ 2026-06-02 10:54 UTC (permalink / raw)
To: Tj, regressions; +Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <ah6vRH9J9LSvnKWW@mail.iam.tj>
On 6/2/26 12:24, Tj wrote:
> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
> bisect it (and there are two other regressions at the same time).
Again, not my area of expertise, but this looks somewhat similar (but
also somewhat different!) to this recent regression report from Rafael:
https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
Rafael (CCed) sent a fix for it already applied:
HID: Input: Add battery list cleanup with devm action
https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
Might be worth trying.
Ciao, Thorsten
> Symptom is unable to use the Bluetooth keyboard.
>
> It *seems* to be related to the Bluetooth keyboard - trying to shutdown
> hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
> and then fails to power-off (see end of log extracts).
>
> I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
> adapter nor the keyboard are Samsung but maybe some change related to
> that is causing this.
>
> Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
> Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
> Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
> Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
> Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
> Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
> Jun 02 09:25:54 sunny kernel: Call Trace:
> Jun 02 09:25:54 sunny kernel: <TASK>
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
> Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
> Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
> Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
> Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
> Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
> Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
> Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
> Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
> Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
> Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
> Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
> Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
> Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
> Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
> Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
> Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
> Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
> Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
> Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
> Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
> Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
> Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
> Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
> Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
> Jun 02 09:25:54 sunny kernel: 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>
> Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
> Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
> Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
> Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
> Jun 02 09:25:54 sunny kernel: </TASK>
> Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
> Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
> Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
> Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
>
> Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
> Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
> Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
> Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
>
>
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 11:07 UTC (permalink / raw)
To: Thorsten Leemhuis, regressions
Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
Thanks once again! That does look likely. Added this and the amdgpu
patch and doing a build now. Will report back for both if any progress,
On 02/06/2026 10:54, Thorsten Leemhuis wrote:
> On 6/2/26 12:24, Tj wrote:
>> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
>> bisect it (and there are two other regressions at the same time).
> Again, not my area of expertise, but this looks somewhat similar (but
> also somewhat different!) to this recent regression report from Rafael:
> https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
>
> Rafael (CCed) sent a fix for it already applied:
> HID: Input: Add battery list cleanup with devm action
> https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
>
> Might be worth trying.
>
> Ciao, Thorsten
>
>> Symptom is unable to use the Bluetooth keyboard.
>>
>> It *seems* to be related to the Bluetooth keyboard - trying to shutdown
>> hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
>> and then fails to power-off (see end of log extracts).
>>
>> I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
>> adapter nor the keyboard are Samsung but maybe some change related to
>> that is causing this.
>>
>> Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
>> Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
>> Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
>> Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
>> Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
>> Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>> Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
>> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
>> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
>> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
>> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
>> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
>> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
>> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
>> Jun 02 09:25:54 sunny kernel: Call Trace:
>> Jun 02 09:25:54 sunny kernel: <TASK>
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
>> Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
>> Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
>> Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
>> Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
>> Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
>> Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
>> Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
>> Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
>> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
>> Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
>> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
>> Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
>> Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
>> Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
>> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
>> Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
>> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
>> Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
>> Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
>> Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
>> Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
>> Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
>> Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
>> Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
>> Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
>> Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
>> Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
>> Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>> Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
>> Jun 02 09:25:54 sunny kernel: 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>
>> Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
>> Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
>> Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
>> Jun 02 09:25:54 sunny kernel: </TASK>
>> Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
>> Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
>> Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
>> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
>> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
>> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
>> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
>> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
>> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
>> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
>> Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
>>
>> Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
>> Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
>> Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
>> Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
>> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
>> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
>>
>>
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 11:25 UTC (permalink / raw)
To: Thorsten Leemhuis, regressions
Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
v7.1-rc6 + "HID: Input: Add battery list cleanup with devm action"
confirmed fixes the hidinput/bluetooth issues. Thank-you.
On 02/06/2026 10:54, Thorsten Leemhuis wrote:
> On 6/2/26 12:24, Tj wrote:
>> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
>> bisect it (and there are two other regressions at the same time).
> Again, not my area of expertise, but this looks somewhat similar (but
> also somewhat different!) to this recent regression report from Rafael:
> https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
>
> Rafael (CCed) sent a fix for it already applied:
> HID: Input: Add battery list cleanup with devm action
> https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Rafael Passos @ 2026-06-02 12:39 UTC (permalink / raw)
To: regressions; +Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
I'm really happy it helped!
Cheers!
Rafael Passos,
Software Engineer
São Paulo, Brasil
^ permalink raw reply
* Re: [PATCH 00/11] HID: storing pointers in 'hid_device_id::driver_data'
From: Pawel Zalewski @ 2026-06-02 13:57 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Ping Cheng, Jason Gerecke, linux-kernel, linux-input,
Christian A. Ehrhardt, Christian A. Ehrhardt
In-Reply-To: <ahhjTbG0Ye-mP9WY@beelink>
> Agree, we need both.
Great, I will implement this in v2.
> I'd drop patches 1-4. I don't see the point of just rewriting the list
> of hid_device_id if we ensure we have just one type.
These patches really just enforce the use of a named initializer for
the `driver_data` field
in the lists and do not change the actual compiled binary. So, the
change applied is purely
cosmetic, and the modules touched there don't use `driver_data` as a
pointer anyway.
I do think that making the code more readable has merit (if it comes
with no risk).
> I need to have a closer look at 5-8 TBH.
Thanks.
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: d3z @ 2026-06-02 15:13 UTC (permalink / raw)
To: even.xu, xinpeng.sun, jikos, bentiss
Cc: Danny D ., linux-input, linux-kernel, abhishektamboli9,
sakari.ailus
In-Reply-To: <IA1PR11MB60985A7B3D9EA4583C2DDBF7F4122@IA1PR11MB6098.namprd11.prod.outlook.com>
From: Danny D. <d3z.the.dev@gmail.com>
Hi Even,
Good way to split it - "touch IC off" vs "THC power-gated" - so I ran the
reset_tic()-only test you asked for.
I added just reset_tic() to a pristine quickspi_resume(), with none of the
THC reconfig (no thc_spi_*_config, no thc_ltr_*). On the Surface Pro 10,
after an s2idle suspend/resume, the touchscreen does NOT come back - so
reset_tic() alone isn't enough here.
The interesting bit is why. The one new line on resume is:
intel_quickspi 0000:00:10.0: THC interrupt already unquiesce
That's reset_tic() -> thc_interrupt_quiesce(dev, false) finding
DEVINT_QUIESCE_EN already clear - even though quickspi_suspend() set it in
suspend. thc_regmap is REGCACHE_NONE, so that's the real register, not a
cached value. So the THC port-control state we wrote in suspend is gone
after resume.
That's your second case: the THC itself loses its register context across
s2idle, without ever hitting PM_SUSPEND_MEM. reset_tic()'s SPI exchange
then runs against a THC whose I/O address and read/write config are wiped,
so the reset never completes. Reprogramming those first (like
quickspi_restore(), and like v2 on the no-wake path) is what brings touch
and pen back.
So on the SP10 both are needed - reset the touch IC AND reconfigure the
THC - the full reconfigure looks necessary here.
One note on the log: there's no fresh "Wait RESET_RESPONSE timeout" line
this cycle, but that path is dev_err_once() and the box had ~12h uptime, so
an earlier cycle likely already consumed it.
Thanks,
Danny
^ permalink raw reply
* [PATCH] Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)
From: Zeyu WANG @ 2026-06-02 17:09 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input
The Lenovo Yoga Air 14 (83QK) laptop keyboard becomes unresponsive
after the standard atkbd init sequence. Controlled testing on the
actual hardware shows the F5 (ATKBD_CMD_RESET_DIS / deactivate)
command specifically corrupts the EC state, causing zero IRQ1
interrupts after init.
Skipping only the deactivate command (while keeping F4 ENABLE)
resolves the issue completely: both keystroke input and CapsLock
LED toggle work correctly. The reverse test - skipping only F4
while keeping F5 - makes the problem worse (zero keystroke
interrupts), confirming F5 is the sole culprit.
Add a DMI quirk entry for LENOVO/83QK using the existing
atkbd_deactivate_fixup callback, consistent with the existing
entries for LG Electronics and HONOR FMB-P that address the
same EC F5 deactivate issue.
Signed-off-by: Zeyu WANG <zeyu.thomas.wang@gmail.com>
---
drivers/input/keyboard/atkbd.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index c8ad55f..217e66e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -1923,6 +1923,14 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
},
.callback = atkbd_deactivate_fixup,
},
+ {
+ /* Lenovo Yoga Air 14 (83QK) */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "83QK"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v8] HID: steelseries: Add MSI Raider A18 HX A9WJG RGB support
From: David Glushkov @ 2026-06-02 18:57 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input, linux-kernel, kernel test robot
In-Reply-To: <20260531215204.172030-1-david.glushkov@sntiq.com>
The MSI Raider A18 HX A9WJG exposes two internal SteelSeries USB HID
devices for RGB lighting: KLC (1038:1122) for the keyboard and ALC
(1038:1161) for the lightbar/logo zones.
Add DMI-gated support for these devices and expose them as multicolor
LED class devices. The driver sends the same HID class SET_REPORT
control transfer as the tested userspace implementation for this
machine and writes a uniform RGB value to all known keyboard keys or
ALC zones.
The ALC payload uses sparse LED IDs on this chassis: 0x00, 0x01,
0x02 and 0x05 are physical zones, while 0x03 and 0x04 do not appear
to map to physical LEDs. Unused payload LED ID slots are initialized
to 0xff so they are ignored by the controller instead of defaulting
to LED ID 0x00.
Limit RGB support to USB interface 0 and the tested DMI system because
the KLC product ID is shared across MSI laptop designs and the key
layout mapping is model-specific. If the DMI or interface check does
not match, keep the device bound as a regular HID device instead of
failing probe.
Tested on MSI Raider A18 HX A9WJG. Both internal SteelSeries ALC
(1038:1161) and KLC (1038:1122) HID devices bind on interface 0 and
create steelseries::lightbar and steelseries::kbd_backlight. Setting
multi_intensity and brightness changes the keyboard and lightbar
colors.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606010709.X0QYNjFZ-lkp@intel.com/
Signed-off-by: David Glushkov <david.glushkov@sntiq.com>
---
v8:
- Use only the confirmed physical ALC LED IDs: 0x00, 0x01,
0x02 and 0x05.
- Initialize unused MSI RGB payload LED IDs to 0xff before filling
active entries, so sparse ALC layouts do not leave trailing slots as
LED ID 0x00 and accidentally override Lightbar 1.
- Use named defines for the MSI RGB opcode/modes/wValue and document
the 524-byte report layout.
- Parenthesise the headset quirk-mask test in steelseries_probe().
- Use devm_mutex_init() for rgb_lock so it is destroyed after the LED
class device is unregistered, instead of mutex_init() plus a manual
mutex_destroy() in steelseries_remove().
v7:
- Use smp_store_release()/smp_load_acquire() when publishing and reading
battery_registered, so raw_event cannot observe the flag before the
delayed work initialization is visible.
v6:
- Fix W=1 build warning when CONFIG_LEDS_CLASS_MULTICOLOR is disabled by
moving steelseries_hid_to_usb_dev() into the multicolor LED code path.
v5:
- Drop pm_ret handling and ignore PM_HINT_NORMAL cleanup errors.
- Fix LED registration error handling to clean up rgb_buf on failure.
- Fix trailing whitespaces and formatting style nits.
- Update commit message to accurately reflect the DMI fallback behavior.
v4:
- Fix literal \n typo in C code.
- Remove unused steelseries_msi_rgb_free_buf from #else block.
- Do not fail probe on unsupported DMI/interface; clear MSI RGB quirk and
continue normal HID initialization.
- Do not fail probe when RGB LED registration fails; keep the HID device usable
without RGB LED support.
- Add explicit linux/slab.h include for kzalloc/kfree.
v3:
- Fix build failure (added missing err_close label to steelseries_probe).
- Fix DMA API violation (use kzalloc instead of devm_kzalloc for usb transfer buffer).
- Fix C syntax declaration-after-statement warning.
- Fix type confusion for SRWS1 (add early check in raw_event before hid_get_drvdata).
- Fix delayed_work crash (add battery_registered flag).
v2:
- Fixed unsafe to_usb_interface cast by checking hid_is_usb() first.
- Fixed uninitialized delayed_work warning by restricting cancel_delayed_work_sync to headset devices.
- Fixed error path leaks in probe (hid_hw_stop / hid_hw_close).
- Added hid_hw_power PM wrappers around direct usb_control_msg transfers.
---
drivers/hid/hid-ids.h | 2 +
drivers/hid/hid-steelseries.c | 310 +++++++++++++++++++++++++++++++++-
2 files changed, 303 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4657d96fb..4af4397b8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1367,6 +1367,8 @@
#define USB_DEVICE_ID_STEELSERIES_SRWS1 0x1410
#define USB_DEVICE_ID_STEELSERIES_ARCTIS_1 0x12b6
#define USB_DEVICE_ID_STEELSERIES_ARCTIS_9 0x12c2
+#define USB_DEVICE_ID_STEELSERIES_MSI_KLC 0x1122
+#define USB_DEVICE_ID_STEELSERIES_MSI_ALC 0x1161
#define USB_VENDOR_ID_SUN 0x0430
#define USB_DEVICE_ID_RARITAN_KVM_DONGLE 0xcdab
diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
index f98435631..01121739e 100644
--- a/drivers/hid/hid-steelseries.c
+++ b/drivers/hid/hid-steelseries.c
@@ -10,16 +10,30 @@
*/
#include <linux/device.h>
+#include <linux/dmi.h>
#include <linux/hid.h>
#include <linux/module.h>
#include <linux/usb.h>
#include <linux/leds.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/slab.h>
#include "hid-ids.h"
#define STEELSERIES_SRWS1 BIT(0)
#define STEELSERIES_ARCTIS_1 BIT(1)
#define STEELSERIES_ARCTIS_9 BIT(2)
+#define STEELSERIES_MSI_RGB BIT(3)
+
+#define STEELSERIES_MSI_RGB_WVALUE 0x0300 /* Feature report, ID 0 */
+#define STEELSERIES_MSI_RGB_REPORT_LEN 524
+#define STEELSERIES_MSI_RGB_OPCODE 0x0c
+#define STEELSERIES_MSI_RGB_KLC_MODE 0x66
+#define STEELSERIES_MSI_RGB_ALC_MODE 0x06
+
+#define STEELSERIES_HAS_LEDS_MULTICOLOR \
+ (IS_BUILTIN(CONFIG_LEDS_CLASS_MULTICOLOR) || \
+ (IS_MODULE(CONFIG_LEDS_CLASS_MULTICOLOR) && IS_MODULE(CONFIG_HID_STEELSERIES)))
struct steelseries_device {
struct hid_device *hdev;
@@ -34,6 +48,14 @@ struct steelseries_device {
uint8_t battery_capacity;
bool headset_connected;
bool battery_charging;
+ bool battery_registered;
+
+#if STEELSERIES_HAS_LEDS_MULTICOLOR
+ struct led_classdev_mc mc_cdev;
+ struct mc_subled subled_info[3];
+ struct mutex rgb_lock; /* protects rgb_buf */
+ u8 *rgb_buf;
+#endif
};
#if IS_BUILTIN(CONFIG_LEDS_CLASS) || \
@@ -510,6 +532,8 @@ static int steelseries_headset_battery_register(struct steelseries_device *sd)
power_supply_powers(sd->battery, &sd->hdev->dev);
INIT_DELAYED_WORK(&sd->battery_work, steelseries_headset_battery_timer_tick);
+ /* Pairs with smp_load_acquire() in raw_event and remove paths */
+ smp_store_release(&sd->battery_registered, true);
steelseries_headset_fetch_battery(sd->hdev);
if (sd->quirks & STEELSERIES_ARCTIS_9) {
@@ -528,6 +552,222 @@ static bool steelseries_is_vendor_usage_page(struct hid_device *hdev, uint8_t us
hdev->rdesc[2] == 0xff;
}
+static const struct dmi_system_id steelseries_msi_rgb_dmi_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International Co., Ltd."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Raider A18 HX A9WJG"),
+ DMI_MATCH(DMI_BOARD_NAME, "MS-182L"),
+ },
+ },
+ { }
+};
+
+static struct usb_interface *steelseries_hid_to_usb_intf(struct hid_device *hdev)
+{
+ if (!hid_is_usb(hdev))
+ return NULL;
+
+ return to_usb_interface(hdev->dev.parent);
+}
+
+static bool steelseries_msi_rgb_is_interface0(struct hid_device *hdev)
+{
+ struct usb_interface *intf = steelseries_hid_to_usb_intf(hdev);
+ struct usb_device *udev;
+
+ if (!intf)
+ return false;
+
+ udev = interface_to_usbdev(intf);
+
+ return intf == usb_ifnum_to_if(udev, 0);
+}
+
+#if STEELSERIES_HAS_LEDS_MULTICOLOR
+
+static struct usb_device *steelseries_hid_to_usb_dev(struct hid_device *hdev)
+{
+ struct usb_interface *intf = steelseries_hid_to_usb_intf(hdev);
+
+ if (!intf)
+ return NULL;
+
+ return interface_to_usbdev(intf);
+}
+
+static int steelseries_msi_rgb_set_blocking(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(led_cdev);
+ struct steelseries_device *sd = container_of(mc_cdev,
+ struct steelseries_device,
+ mc_cdev);
+ struct hid_device *hdev = sd->hdev;
+ struct usb_device *udev = steelseries_hid_to_usb_dev(hdev);
+ int i, ret;
+ u8 r, g, b;
+
+ static const u8 keys[] = {
+ 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b,
+ 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13,
+ 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b,
+ 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+ 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+ 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x33, 0x34,
+ 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c,
+ 0x3d, 0x3e, 0x3f, 0x40, 0x41, 0x42, 0x43, 0x44,
+ 0x45, 0x46, 0x47, 0x49, 0x4b, 0x4c, 0x4e, 0x4f,
+ 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57,
+ 0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x66, 0xe0, 0xe1,
+ 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xf0
+ };
+ static const u8 alc_zones[] = { 0x00, 0x01, 0x02, 0x05 };
+
+ if (!udev)
+ return -ENODEV;
+
+ mutex_lock(&sd->rgb_lock);
+
+ led_mc_calc_color_components(mc_cdev, brightness);
+
+ r = mc_cdev->subled_info[0].brightness;
+ g = mc_cdev->subled_info[1].brightness;
+ b = mc_cdev->subled_info[2].brightness;
+
+ /*
+ * Report layout (524 bytes):
+ * Byte 0: Opcode (0x0c)
+ * Byte 1: 0x00
+ * Byte 2: Mode (0x66 for Keyboard, 0x06 for Lightbar)
+ * Byte 3: 0x00
+ * Bytes 4+: 4-byte chunks per LED (Index, R, G, B)
+ */
+ memset(sd->rgb_buf, 0, STEELSERIES_MSI_RGB_REPORT_LEN);
+ sd->rgb_buf[0] = STEELSERIES_MSI_RGB_OPCODE;
+ sd->rgb_buf[1] = 0x00;
+ sd->rgb_buf[3] = 0x00;
+
+ for (i = 0; i < (STEELSERIES_MSI_RGB_REPORT_LEN - 4) / 4; i++)
+ sd->rgb_buf[4 + i * 4] = 0xff;
+
+ if (hdev->product == USB_DEVICE_ID_STEELSERIES_MSI_KLC) {
+ sd->rgb_buf[2] = STEELSERIES_MSI_RGB_KLC_MODE;
+ for (i = 0; i < ARRAY_SIZE(keys); i++) {
+ sd->rgb_buf[4 + i * 4] = keys[i];
+ sd->rgb_buf[5 + i * 4] = r;
+ sd->rgb_buf[6 + i * 4] = g;
+ sd->rgb_buf[7 + i * 4] = b;
+ }
+ } else {
+ sd->rgb_buf[2] = STEELSERIES_MSI_RGB_ALC_MODE;
+ for (i = 0; i < ARRAY_SIZE(alc_zones); i++) {
+ sd->rgb_buf[4 + i * 4] = alc_zones[i];
+ sd->rgb_buf[5 + i * 4] = r;
+ sd->rgb_buf[6 + i * 4] = g;
+ sd->rgb_buf[7 + i * 4] = b;
+ }
+ }
+
+ /*
+ * Send the vendor report verbatim with usb_control_msg(): byte 0 is a
+ * protocol opcode (0x0c), not a HID report ID, and the controller
+ * expects it under report ID 0 (wValue 0x0300). hid_hw_raw_request()
+ * would write the report number into byte 0, so the direct control
+ * transfer is used to keep the payload byte-identical to the tested
+ * userspace implementation.
+ */
+ ret = hid_hw_power(hdev, PM_HINT_FULLON);
+ if (ret < 0)
+ goto out_unlock;
+
+ ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ HID_REQ_SET_REPORT,
+ USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ STEELSERIES_MSI_RGB_WVALUE, 0,
+ sd->rgb_buf, STEELSERIES_MSI_RGB_REPORT_LEN,
+ USB_CTRL_SET_TIMEOUT);
+
+ hid_hw_power(hdev, PM_HINT_NORMAL);
+
+out_unlock:
+ mutex_unlock(&sd->rgb_lock);
+ return ret < 0 ? ret : 0;
+}
+
+static void steelseries_msi_rgb_free_buf(void *data)
+{
+ kfree(data);
+}
+
+static int steelseries_msi_rgb_register(struct steelseries_device *sd)
+{
+ struct hid_device *hdev = sd->hdev;
+ struct led_classdev *led_cdev;
+ int ret;
+
+ sd->rgb_buf = kzalloc(STEELSERIES_MSI_RGB_REPORT_LEN, GFP_KERNEL);
+ if (!sd->rgb_buf)
+ return -ENOMEM;
+
+ ret = devm_add_action_or_reset(&hdev->dev,
+ steelseries_msi_rgb_free_buf,
+ sd->rgb_buf);
+ if (ret) {
+ sd->rgb_buf = NULL;
+ return ret;
+ }
+
+ ret = devm_mutex_init(&hdev->dev, &sd->rgb_lock);
+ if (ret) {
+ devm_remove_action(&hdev->dev, steelseries_msi_rgb_free_buf,
+ sd->rgb_buf);
+ kfree(sd->rgb_buf);
+ sd->rgb_buf = NULL;
+ return ret;
+ }
+
+ sd->subled_info[0].color_index = LED_COLOR_ID_RED;
+ sd->subled_info[1].color_index = LED_COLOR_ID_GREEN;
+ sd->subled_info[2].color_index = LED_COLOR_ID_BLUE;
+ sd->subled_info[0].intensity = 255;
+ sd->subled_info[1].intensity = 255;
+ sd->subled_info[2].intensity = 255;
+ sd->subled_info[0].channel = 0;
+ sd->subled_info[1].channel = 1;
+ sd->subled_info[2].channel = 2;
+
+ sd->mc_cdev.subled_info = sd->subled_info;
+ sd->mc_cdev.num_colors = 3;
+
+ led_cdev = &sd->mc_cdev.led_cdev;
+ if (hdev->product == USB_DEVICE_ID_STEELSERIES_MSI_KLC)
+ led_cdev->name = "steelseries::kbd_backlight";
+ else
+ led_cdev->name = "steelseries::lightbar";
+
+ led_cdev->max_brightness = 255;
+ led_cdev->brightness_set_blocking = steelseries_msi_rgb_set_blocking;
+
+ ret = devm_led_classdev_multicolor_register(&hdev->dev, &sd->mc_cdev);
+ if (ret) {
+ devm_remove_action(&hdev->dev, steelseries_msi_rgb_free_buf,
+ sd->rgb_buf);
+ kfree(sd->rgb_buf);
+ sd->rgb_buf = NULL;
+ return ret;
+ }
+
+ return 0;
+}
+#else
+static int steelseries_msi_rgb_register(struct steelseries_device *sd)
+{
+ return -ENODEV;
+}
+#endif
+
static int steelseries_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
struct steelseries_device *sd;
@@ -549,6 +789,14 @@ static int steelseries_probe(struct hid_device *hdev, const struct hid_device_id
sd->hdev = hdev;
sd->quirks = id->driver_data;
+ if (sd->quirks & STEELSERIES_MSI_RGB) {
+ if (!dmi_check_system(steelseries_msi_rgb_dmi_table) ||
+ !steelseries_msi_rgb_is_interface0(hdev)) {
+ hid_dbg(hdev, "MSI RGB quirk not applicable, using generic HID path\n");
+ sd->quirks &= ~STEELSERIES_MSI_RGB;
+ }
+ }
+
ret = hid_parse(hdev);
if (ret)
return ret;
@@ -565,12 +813,28 @@ static int steelseries_probe(struct hid_device *hdev, const struct hid_device_id
ret = hid_hw_open(hdev);
if (ret)
- return ret;
+ goto err_stop;
+
+ if (sd->quirks & STEELSERIES_MSI_RGB) {
+ ret = steelseries_msi_rgb_register(sd);
+ if (ret) {
+ hid_warn(hdev,
+ "Failed to register MSI RGB LEDs: %d, continuing without RGB support\n",
+ ret);
+ sd->quirks &= ~STEELSERIES_MSI_RGB;
+ }
+ return 0;
+ }
- if (steelseries_headset_battery_register(sd) < 0)
+ if ((sd->quirks & (STEELSERIES_ARCTIS_1 | STEELSERIES_ARCTIS_9)) &&
+ steelseries_headset_battery_register(sd) < 0)
hid_err(sd->hdev,
"Failed to register battery for headset\n");
+ return 0;
+
+err_stop:
+ hid_hw_stop(hdev);
return ret;
}
@@ -588,12 +852,16 @@ static void steelseries_remove(struct hid_device *hdev)
}
sd = hid_get_drvdata(hdev);
+ if (!sd)
+ return;
spin_lock_irqsave(&sd->lock, flags);
sd->removed = true;
spin_unlock_irqrestore(&sd->lock, flags);
- cancel_delayed_work_sync(&sd->battery_work);
+ /* Pairs with smp_store_release() in steelseries_headset_battery_register() */
+ if (smp_load_acquire(&sd->battery_registered))
+ cancel_delayed_work_sync(&sd->battery_work);
hid_hw_close(hdev);
hid_hw_stop(hdev);
@@ -624,20 +892,34 @@ static uint8_t steelseries_headset_map_capacity(uint8_t capacity, uint8_t min_in
return (capacity - min_in) * 100 / (max_in - min_in);
}
+static bool steelseries_is_headset(struct hid_device *hdev)
+{
+ return hdev->product == USB_DEVICE_ID_STEELSERIES_ARCTIS_1 ||
+ hdev->product == USB_DEVICE_ID_STEELSERIES_ARCTIS_9;
+}
+
static int steelseries_headset_raw_event(struct hid_device *hdev,
struct hid_report *report, u8 *read_buf,
int size)
{
- struct steelseries_device *sd = hid_get_drvdata(hdev);
- int capacity = sd->battery_capacity;
- bool connected = sd->headset_connected;
- bool charging = sd->battery_charging;
+ struct steelseries_device *sd;
+ int capacity;
+ bool connected;
+ bool charging;
unsigned long flags;
- /* Not a headset */
- if (hdev->product == USB_DEVICE_ID_STEELSERIES_SRWS1)
+ if (!steelseries_is_headset(hdev))
return 0;
+ sd = hid_get_drvdata(hdev);
+ /* Pairs with smp_store_release() in steelseries_headset_battery_register() */
+ if (!sd || !smp_load_acquire(&sd->battery_registered))
+ return 0;
+
+ capacity = sd->battery_capacity;
+ connected = sd->headset_connected;
+ charging = sd->battery_charging;
+
if (hdev->product == USB_DEVICE_ID_STEELSERIES_ARCTIS_1) {
hid_dbg(sd->hdev,
"Parsing raw event for Arctis 1 headset (%*ph)\n", size, read_buf);
@@ -732,6 +1014,16 @@ static const struct hid_device_id steelseries_devices[] = {
HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_ARCTIS_9),
.driver_data = STEELSERIES_ARCTIS_9 },
+#if STEELSERIES_HAS_LEDS_MULTICOLOR
+ { /* MSI Raider A18 KLC */
+ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_MSI_KLC),
+ .driver_data = STEELSERIES_MSI_RGB },
+
+ { /* MSI Raider A18 ALC */
+ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_MSI_ALC),
+ .driver_data = STEELSERIES_MSI_RGB },
+#endif
+
{ }
};
MODULE_DEVICE_TABLE(hid, steelseries_devices);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/9] MT6365 PMIC support cleanup
From: Rob Herring @ 2026-06-02 19:58 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, kernel, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, linux-input,
linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
On Wed, Apr 29, 2026 at 11:44:13AM +0200, Louis-Alexis Eyraud wrote:
> Several Mediatek and Radxa boards, based on MT8370, MT8390 or MT8395
> SoC, integrate the MT6365 PMIC, that is a MT6359P variant:
> - Mediatek Genio 1200-EVK
> - Mediatek Genio 700-EVK
> - Mediatek Genio 510-EVK
> - Radxa NIO-12L
> It is compatible with the MT6359 PMIC.
>
> But both MT6365 PMIC support and compatibility were never expressed in
> the dt-bindings and there is no MT6365 include file as well.
> So, since these board support was introduced, their devicetrees use the
> mt6359 include file to enable this PMIC support.
>
> The goal of this series is to clean this support by adding the missing
> compatible strings for this MFD main and subdevices in the dt-bindings,
> and add a include for MT6365 definitions to replace the MT6359 include
> in these board devicetrees and for future ones (like Genio 520/720
> EVKs).
>
> The series is based on linux-next tree (tag: next-20260428) and has
> been tested on Mediatek Genio 510, 700 and 1200-EVK boards.
>
> ---
> Louis-Alexis Eyraud (9):
> dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
> dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
> dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
> dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
Applied these 2 to fix warnings in linux-next.
Angelo, Apply the binding changes along with the .dts changes if they
haven't been picked up yet.
Once again, Mediatek warnings are moving in the wrong direction. :(
Rob
> arm64: dts: mediatek: mt6359: use proper compatible for rtc
> arm64: dts: mediatek: add MT6365 PMIC include
> arm64: dts: mediatek: mt8390-genio-common: use MT6365 PMIC definitions
> arm64: dts: mediatek: mt8395-genio-common: use MT6365 PMIC definitions
> arm64: dts: mediatek: mt8395-radxa-nio-12l: use MT6365 PMIC definitions
^ permalink raw reply
* Re: [PATCH] Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)
From: Dmitry Torokhov @ 2026-06-02 23:32 UTC (permalink / raw)
To: Zeyu WANG; +Cc: linux-input
In-Reply-To: <20260602170909.14725-1-zeyu.thomas.wang@gmail.com>
On Wed, Jun 03, 2026 at 01:09:09AM +0800, Zeyu WANG wrote:
> The Lenovo Yoga Air 14 (83QK) laptop keyboard becomes unresponsive
> after the standard atkbd init sequence. Controlled testing on the
> actual hardware shows the F5 (ATKBD_CMD_RESET_DIS / deactivate)
> command specifically corrupts the EC state, causing zero IRQ1
> interrupts after init.
>
> Skipping only the deactivate command (while keeping F4 ENABLE)
> resolves the issue completely: both keystroke input and CapsLock
> LED toggle work correctly. The reverse test - skipping only F4
> while keeping F5 - makes the problem worse (zero keystroke
> interrupts), confirming F5 is the sole culprit.
>
> Add a DMI quirk entry for LENOVO/83QK using the existing
> atkbd_deactivate_fixup callback, consistent with the existing
> entries for LG Electronics and HONOR FMB-P that address the
> same EC F5 deactivate issue.
>
> Signed-off-by: Zeyu WANG <zeyu.thomas.wang@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 00/36] HID: iio: basic clean up and introduce devm_ API for HID sensors
From: Andy Shevchenko @ 2026-06-03 0:01 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Sanjay Chitroda, jikos, srinivas.pandruvada, dlechner, nuno.sa,
andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260526165639.42d6e98e@jic23-huawei>
On Tue, May 26, 2026 at 04:56:51PM +0100, Jonathan Cameron wrote:
> On Mon, 25 May 2026 00:50:23 +0530
> Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
> > Key highlights:
> > - 0000-0024: General cleanup and kernel few coding style fixes across HID IIO drivers
> > - 0025: Remove unused iio_dev argument from HID IIO sensor helper
> > - 0026: Introduce devm_hid_sensor_setup_trigger() device-managed API
> > - 0027-0036: Convert HID IIO sensor drivers to use the new devm-based trigger setup
> >
> > changes in v4:
> > - Extend the series to cover remaining HID IIO drivers with devm API usage
> > - Reorder patches to place cleanup and warning fix at beginning and,
> > devm-related changes toward the end based on feedback from David
> > - v3 series -> https://lore.kernel.org/all/20260509101040.791404-1-sanjayembedded@gmail.com/
> > changes in v3:
> > - Added cleanup and prepratory changes before adding devm_ API
> > conversion based on self review: 0002, 0004, 0006, 0007 and 0008
> > - Address andy's review comment on commit message and coding style
> > - v2 series -> https://lore.kernel.org/all/20260429175918.2541914-1-sanjayembedded@gmail.com/
> > changes in v2:
> > - Following input from Jonathan and Andy, squash initial patch v1
> > series in single change as individual change should not break anything
> > - Add devm API support and two driver using the same
> > - v1 series -> https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@gmail.com/
> >
> > Testing:
> > - Compiled with W=1 for each patch in series
> > - Build-tested on QEMU x86_64
> >
> > P.S.
> > - Sashiko reported an issue in a different driver and noted that it is not
> > introduced by this series. I have taken this feedback into account and
> > will address the actual issue in a separate series focus on that driver.
> > - Once this series is merged into the IIO tree, a number of HID IIO
> > drivers will become available to fully converted to devm API usage.
> > - The changes are organized across drivers to keep similar modifications
> > grouped together for consistency, making the series easier to review,
> > rather than grouping all changes per driver.
> >
> The series is mostly fine, though not sure what happened with how you sent
> it as I have it in seperate threads of 10 patches at a time. If you are having
> email troubles with big series, use b4 to send them instead (instructions on kernel.org)
I'm also confused. Fix your email and then come with better series chaining.
> My main concern is this is a lot of churn on a critical driver. I'd like therefore
> to be able to see the full benefit of those devm patches rather than get us
> part way as this does.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] Input: synaptics - retry SMBus intertouch setup when companion is not ready
From: Raphaël Larocque @ 2026-06-03 0:20 UTC (permalink / raw)
To: linux-input; +Cc: dmitry.torokhov, kees, linux-kernel, Raphaël Larocque
On some machines (here: Lenovo ThinkPad T440p 20AWS0H800),
the SMBus companion device is not ready
by the time psmouse probes the Synaptics touchpad
during early boot. synaptics_setup_intertouch() returns -EAGAIN in
this situation, but synaptics_init() previously treated this the same
as any other error and fell through immediately to PS/2 mode. As a
result, the touchpad and TrackPoint were unresponsive for several
minutes after a cold boot, until an internal reconnect cycle (which
already carries retry logic in synaptics_reconnect()) eventually
succeeded.
Fix this by adding an exponential back-off retry loop in synaptics_init()
when synaptics_setup_intertouch() returns -EAGAIN: clean up the failed
state, sleep for 500 ms on the first attempt doubling each time up to
4000 ms, then retry. The worst-case added latency at boot is ~7.5 s
(500 + 1000 + 2000 + 4000 ms), and only for hardware that actually
reports SYN_CAP_INTERTOUCH. The pattern mirrors what
synaptics_reconnect() already does after resume.
Tested-by: Raphaël Larocque <rlarocque@disroot.org>
Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
---
drivers/input/mouse/synaptics.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c70502e24031..5c1bfff2b16c 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1918,6 +1918,23 @@ int synaptics_init(struct psmouse *psmouse)
}
error = synaptics_setup_intertouch(psmouse, &info, true);
+ if (error == -EAGAIN) {
+ /*
+ * On some systems (e.g. ThinkPad T440p) the SMBus
+ * companion device is not yet ready at boot time.
+ * Clean up and retry with exponential back-off,
+ * mirroring synaptics_reconnect().
+ */
+ unsigned int delay = 500;
+
+ do {
+ psmouse_smbus_cleanup(psmouse);
+ msleep(delay);
+ error = synaptics_setup_intertouch(psmouse, &info, true);
+ delay *= 2;
+ } while (error == -EAGAIN && delay <= 4000);
+ }
+
if (!error)
return PSMOUSE_SYNAPTICS_SMBUS;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Input: synaptics - retry SMBus intertouch setup when companion is not ready
From: Dmitry Torokhov @ 2026-06-03 1:00 UTC (permalink / raw)
To: Raphaël Larocque; +Cc: linux-input, kees, linux-kernel
In-Reply-To: <20260603002046.10697-1-rlarocque@disroot.org>
Hi Raphaël,
On Tue, Jun 02, 2026 at 08:20:46PM -0400, Raphaël Larocque wrote:
> On some machines (here: Lenovo ThinkPad T440p 20AWS0H800),
> the SMBus companion device is not ready
> by the time psmouse probes the Synaptics touchpad
> during early boot. synaptics_setup_intertouch() returns -EAGAIN in
> this situation, but synaptics_init() previously treated this the same
> as any other error and fell through immediately to PS/2 mode. As a
> result, the touchpad and TrackPoint were unresponsive for several
> minutes after a cold boot, until an internal reconnect cycle (which
> already carries retry logic in synaptics_reconnect()) eventually
> succeeded.
>
> Fix this by adding an exponential back-off retry loop in synaptics_init()
> when synaptics_setup_intertouch() returns -EAGAIN: clean up the failed
> state, sleep for 500 ms on the first attempt doubling each time up to
> 4000 ms, then retry. The worst-case added latency at boot is ~7.5 s
> (500 + 1000 + 2000 + 4000 ms), and only for hardware that actually
> reports SYN_CAP_INTERTOUCH. The pattern mirrors what
> synaptics_reconnect() already does after resume.
>
> Tested-by: Raphaël Larocque <rlarocque@disroot.org>
> Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
> ---
> drivers/input/mouse/synaptics.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index c70502e24031..5c1bfff2b16c 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1918,6 +1918,23 @@ int synaptics_init(struct psmouse *psmouse)
> }
>
> error = synaptics_setup_intertouch(psmouse, &info, true);
> + if (error == -EAGAIN) {
> + /*
> + * On some systems (e.g. ThinkPad T440p) the SMBus
> + * companion device is not yet ready at boot time.
> + * Clean up and retry with exponential back-off,
> + * mirroring synaptics_reconnect().
> + */
> + unsigned int delay = 500;
> +
> + do {
> + psmouse_smbus_cleanup(psmouse);
> + msleep(delay);
> + error = synaptics_setup_intertouch(psmouse, &info, true);
> + delay *= 2;
> + } while (error == -EAGAIN && delay <= 4000);
> + }
> +
The idea here is that if adapter/device is not ready we leave enuough
"breadcumbs" for it to recognize when SMBus companion appears and
complete the initialization without repeatedly cleaning up and retrying
initialization anew.
Could you enable logging and see where the logic fails for you? I am not
too keen on simply adding up to 8 seconds delay to the boot time.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: steven @ 2026-06-03 1:38 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: wens, linux-input, linux-kernel, steven
Add power button support for the AXP313A PMIC. The AXP313A does not
have the PEK_KEY register (0x36) used to configure startup and shutdown
timings, unlike AXP20X and AXP221. Create a dedicated axp313a_info
configuration with NULL time tables to prevent regmap out-of-bounds
access.
The sysfs attributes (startup/shutdown) will return -EOPNOTSUPP when
accessed on AXP313A devices.
Signed-off-by: steven <steven@joint-cloud.com>
---
Changes in v2:
- Fixed regmap out-of-bounds access issue reported by Sashiko AI
- Created dedicated axp313a_info with NULL time tables
- Added NULL pointer checks to prevent crashes
- AXP313A lacks PEK_KEY (0x36) per datasheet verification
- Power button still functional using hardware default timings
v1: https://lore.kernel.org/all/tencent_5F1FF80489E702360F352F889570656BF608@qq.com/
---
drivers/input/misc/axp20x-pek.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index d4e2fc9a937f..de43eef0c0ea 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -85,6 +85,13 @@ static const struct axp20x_info axp221_info = {
.shutdown_mask = AXP20X_PEK_SHUTDOWN_MASK,
};
+static const struct axp20x_info axp313a_info = {
+ .startup_time = NULL,
+ .startup_mask = 0,
+ .shutdown_time = NULL,
+ .shutdown_mask = 0,
+};
+
static ssize_t axp20x_show_attr(struct device *dev,
const struct axp20x_time *time,
unsigned int mask, char *buf)
@@ -93,6 +100,9 @@ static ssize_t axp20x_show_attr(struct device *dev,
unsigned int val;
int ret, i;
+ if (!time)
+ return -EOPNOTSUPP;
+
ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
if (ret != 0)
return ret;
@@ -137,6 +147,9 @@ static ssize_t axp20x_store_attr(struct device *dev,
unsigned int val, idx = 0;
unsigned int best_err = UINT_MAX;
+ if (!time)
+ return -EOPNOTSUPP;
+
ret = kstrtouint(buf, 10, &val);
if (ret)
return ret;
@@ -395,7 +408,7 @@ static const struct platform_device_id axp_pek_id_match[] = {
},
{
.name = "axp313a-pek",
- .driver_data = (kernel_ulong_t)&axp20x_info,
+ .driver_data = (kernel_ulong_t)&axp313a_info,
},
{ /* sentinel */ }
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: Dmitry Torokhov @ 2026-06-03 2:25 UTC (permalink / raw)
To: steven; +Cc: wens, linux-input, linux-kernel
In-Reply-To: <tencent_48A497E0CA81323CFB6C7CB84428019A8707@qq.com>
On Wed, Jun 03, 2026 at 09:38:54AM +0800, steven wrote:
> Add power button support for the AXP313A PMIC. The AXP313A does not
> have the PEK_KEY register (0x36) used to configure startup and shutdown
> timings, unlike AXP20X and AXP221. Create a dedicated axp313a_info
> configuration with NULL time tables to prevent regmap out-of-bounds
> access.
>
> The sysfs attributes (startup/shutdown) will return -EOPNOTSUPP when
> accessed on AXP313A devices.
>
> Signed-off-by: steven <steven@joint-cloud.com>
> ---
> Changes in v2:
> - Fixed regmap out-of-bounds access issue reported by Sashiko AI
> - Created dedicated axp313a_info with NULL time tables
> - Added NULL pointer checks to prevent crashes
> - AXP313A lacks PEK_KEY (0x36) per datasheet verification
> - Power button still functional using hardware default timings
>
> v1: https://lore.kernel.org/all/tencent_5F1FF80489E702360F352F889570656BF608@qq.com/
> ---
> drivers/input/misc/axp20x-pek.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
> index d4e2fc9a937f..de43eef0c0ea 100644
> --- a/drivers/input/misc/axp20x-pek.c
> +++ b/drivers/input/misc/axp20x-pek.c
> @@ -85,6 +85,13 @@ static const struct axp20x_info axp221_info = {
> .shutdown_mask = AXP20X_PEK_SHUTDOWN_MASK,
> };
>
> +static const struct axp20x_info axp313a_info = {
> + .startup_time = NULL,
> + .startup_mask = 0,
> + .shutdown_time = NULL,
> + .shutdown_mask = 0,
> +};
> +
> static ssize_t axp20x_show_attr(struct device *dev,
> const struct axp20x_time *time,
> unsigned int mask, char *buf)
> @@ -93,6 +100,9 @@ static ssize_t axp20x_show_attr(struct device *dev,
> unsigned int val;
> int ret, i;
>
> + if (!time)
> + return -EOPNOTSUPP;
Use is_visible to control whether attributes are accessible.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v10 1/4] HID: hid-msi: Add MSI Claw configuration driver
From: Derek John Clark @ 2026-06-03 2:32 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Pierre-Loup A . Griffais,
Denis Benato, Zhouwang Huang, linux-input, linux-doc,
linux-kernel
In-Reply-To: <ahnYeAbzO5K3feRn@google.com>
On Fri, May 29, 2026 at 11:29 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, May 28, 2026 at 11:34:18PM -0700, Derek John Clark wrote:
> > On Wed, May 27, 2026 at 10:32 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > Hi Derek,
> > >
> > > On Wed, May 27, 2026 at 10:21:19PM +0000, Derek J. Clark wrote:
> > > > Adds configuration HID driver for the MSI Claw series of handheld PC's.
> > > > In this initial patch add the initial driver outline and attributes for
> > > > changing the gamepad mode, M-key behavior, and add a WO reset function.
> > > >
> > > > Sending the SWITCH_MODE and RESET commands causes a USB disconnect in
> > > > the device. The completion will therefore never get hit and would trigger
> > > > an -EIO. To avoid showing the user an error for every write to these
> > > > attrs a bypass for the completion handling is introduced when timeout ==
> > > > 0.
> > > >
> > > > The initial version of this patch was written by Denis Benato, which
> > > > contained the initial reverse-engineering and implementation for the
> > > > gamepad mode switching. This work was later expanded by Zhouwang Huang
> > > > to include more gamepad modes. Finally, I refactored the drivers data
> > > > in/out flow and overall format to conform to kernel driver best
> > > > practices and style guides. Claude was used as an initial reviewer of
> > > > this patch.
> > >
> > > I wonder why do you need to roll asynchronous probing and asynchronous
> > > resume by hand? This I think complicates the driver greatly and forces
> > > you to use a ton of works, spinlocks, and checks.
> > >
> > > Thanks.
> > >
> >
> > Hi Dmitry,
> >
> > I suppose being asked this means my cover letter and commit
> > descriptions need some additional context. The MCU in these Claw
> > devices is quite temperamental. There are a few specific issues that
> > cause the need for multiple work queues, a serialization mutex, and
> > subsequently spinlocks to prevent stale data reads.
> >
> > 1.) The MCU will halt function if it receives any output reports
> > before ~500MS after probe or resume. This can either manifest as the
> > device never responding to a command, or it can cause the entire
> > system to become unstable and reboot. This creates the need for
> > cfg_setup to query the MCU and then add the gamepad attrs, led_mc
> > device, and rgb attrs. As a side effect, because a system could
> > technically be suspended during that 500ms delay, there exists the
> > need to re-queue the work if it was never triggered, hence the resume
> > queue.
> > 2.) The MCU will not always respond in order if two or more output
> > reports are sent within a few ms of each other. Since many of the
> > commands use a generic "ACK", or share an "ACK" type but don't provide
> > specific context about what sub-function called them, we could
> > potentially have cross talk where data is saved in the wrong attribute
> > or errors propagate because of a missed message. To get around this
> > serialization issue we hold a mutex through a completion triggered in
> > raw_event and, for most events, save a state machine on what command
> > is expected and what sub-command was the initiator. (I.E. profile
> > events handle the M1, M2, RGB, Left rumble, and right rumble). Since
> > the state machine is accessed on both sides, we need spinlocks
> > guarding the reads. This essentially serializes the data and makes it
> > predictable. Using this pattern I haven't had any issues reading from
> > or writing to the MCU.
> > 3.) Some commands will never return their "ACK" while a completion is
> > held, so we have a workaround to basically ignore them and hope the
> > command worked. This is only needed for SYNC_TO_ROM, from which we
> > don't need to set anything on its "ACK", and switching the gamepad
> > mode, which causes USB disconnect/reconnect and the driver fully
> > reloads, so we'll never be able to read it anyway.
> > 4.) The RGB work queue is used to free the userspace write while the
> > completion is held. I found that use without it could stall userspace
> > quite significantly if it has multiple writes back to back. I
> > experienced this using Steam's customization menu, which sends a
> > single write for every increment of its color and brightness sliders.
> > when traversing the full length of the slider it is possible to have
> > effects changing for nearly a minute after stopping. With the queue,
> > only the most recent write is eventually sent to the MCU. This issue
> > also affects the Go 2 driver as well, though not to the same extent,
> > but for which I'll be adding a similar de-bounce queue soon. Go S is
> > also technically affected by this bug, but that returns quickly enough
> > that it isn't really feasible to trigger the bug with much frequency.
> > I'll still fix that one as well though.
> >
> > TBH I'm not "happy" with the complexity of the driver, but I don't see
> > a reasonable alternative. If you have any specific suggestions that I
> > could try that might simplify it, I'd be more than happy to give it a
> > shot. That being said, I'm not very optimistic about it. Development
> > on this device has been like wrestling a bear.
>
> Thank you for this detailed explanation. I would like to concentrate on
> the #1 first. What happens in the driver is you are essentially rolling
> asynchronous probing and asynchronous suspend/resume in the driver
> itself, and end up fighting with the kernel and the driver core
> specifically.
>
> As far as suspend/resume goes: HID subsystem already enables
> asynchronous resume handling (checkout the call to
> device_enable_async_suspend() in
> drivers/hid/hid-core.c::hid_allocate_device()). Therefore I think you
> just need to stick the necessary delay in your resume method() and call
> it a day.
>
> For the probing I would look into annotating the driver as
> PROBE_PREFER_ASYNCHRONOUS and relying on that. Again, if you stick the
> required delay in probe then sysfs attributes will not be created too
> early, same for the rest of concerns with the device being exposed to
> userspace before it is ready to handle requests.
Hi Dmitry,
I've done a bit of a deep dive into this to try and get it to work
without work queues while using PROBE_PREFER_ASYNCHRONOUS and regular
sleeps. While it does simplify the driver, I can't get it to function
properly. No matter how long I wait the probe fails with an -EBUSY as
raw_event never fires during the probe context, and my completion
handler times out. The most likely explanation I have found is that
the MCU must require all interfaces to be fully bound before it will
respond to interrupt URB completions (vice needing to sleep for 500ms
for the MCU to be ready as I previously thought). During probe the
driver core holds the parent USB device lock for the duration of each
interface's probe. Since the other interfaces cannot start binding as
they are blocked waiting for the parent lock, and the MCU is waiting
for them to bind before responding, no ACK arrives within the timeout
window and the probe fails. The other interfaces only begin probing
after the config interface probe returns and releases the parent lock,
as confirmed by dmesg timestamps. When using the work_queue method all
interfaces have finished probing, so the MCU is responding to
interrupt URB completions and everything works.
> If there are issues with HID subsystem honoring
> PROBE_PREFER_ASYNCHRONOUS I would look into fixing the subsystem rather
> than try to work around it in the driver.
Since a lock is held on the parent while each interface is attached,
and USB devices have multiple interfaces, this happens synchronously
even in "async" context. The HID core calls driver_attach, which
detects the async flag and calls __driver_attach_async_helper, which
then calls driver_probe_device after locking the parent.
From drivers/base/dd.c:
static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
{
struct device *dev = _dev;
const struct device_driver *drv;
int ret;
__device_driver_lock(dev, dev->parent);
drv = dev->p->async_driver;
dev->p->async_driver = NULL;
ret = driver_probe_device(drv, dev);
__device_driver_unlock(dev, dev->parent);
dev_dbg(dev, "driver %s async attach completed: %d\n", drv->name, ret);
put_device(dev);
}
...
* driver_probe_device - attempt to bind device & driver together
...
* This function must be called with @dev lock held. When called for a
* USB interface, @dev->parent lock must be held as well.
One possible solution might be to add a way to match on
bInterfaceNumber in hid_device_id and allow the interfaces I don't
care about to stay bound to hid_generic. Another would be to
parallelize the interface probing. I'm not sure about the feasibility
of either approach since they would have significant changes and broad
implications for all USB/USBHID drivers. I also don't know if that
would even solve the problem.
Thanks,
Derek
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: Steven Feng @ 2026-06-03 2:59 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: wens, linux-input, linux-kernel, Steven Feng
In-Reply-To: <ZoMD9s0Xs_VBzIKC@google.com>
Add power button support for the AXP313A PMIC. The AXP313A does not
have the PEK_KEY register (0x36) used to configure startup and shutdown
timings, unlike AXP20X and AXP221. Create a dedicated axp313a_info
configuration with NULL time tables to prevent regmap out-of-bounds
access.
For AXP313A, the sysfs attributes (startup/shutdown) are hidden using
the is_visible callback, as they are not supported by the hardware.
Signed-off-by: Steven Feng <steven@joint-cloud.com>
---
Changes in v3:
- Use is_visible to hide attributes instead of returning -EOPNOTSUPP
- Corrected author name from "steven" to "Steven Feng"
Changes in v2:
- Fixed regmap out-of-bounds access issue reported by Sashiko AI
- Created dedicated axp313a_info with NULL time tables
- Added NULL pointer checks to prevent crashes
- AXP313A lacks PEK_KEY (0x36) per datasheet verification
- Power button still functional using hardware default timings
v2: https://lore.kernel.org/all/tencent_48A497E0CA81323CFB6C7CB84428019A8707@qq.com/
v1: https://lore.kernel.org/all/tencent_5F1FF80489E702360F352F889570656BF608@qq.com/
---
drivers/input/misc/axp20x-pek.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index d4e2fc9a937f..964b39817af9 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -85,6 +85,13 @@ static const struct axp20x_info axp221_info = {
.shutdown_mask = AXP20X_PEK_SHUTDOWN_MASK,
};
+static const struct axp20x_info axp313a_info = {
+ .startup_time = NULL,
+ .startup_mask = 0,
+ .shutdown_time = NULL,
+ .shutdown_mask = 0,
+};
+
static ssize_t axp20x_show_attr(struct device *dev,
const struct axp20x_time *time,
unsigned int mask, char *buf)
@@ -193,7 +200,28 @@ static struct attribute *axp20x_attrs[] = {
&dev_attr_shutdown.attr,
NULL,
};
-ATTRIBUTE_GROUPS(axp20x);
+
+static umode_t axp20x_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+
+ if (!axp20x_pek->info->startup_time)
+ return 0;
+
+ return attr->mode;
+}
+
+static const struct attribute_group axp20x_group = {
+ .attrs = axp20x_attrs,
+ .is_visible = axp20x_attr_is_visible,
+};
+
+static const struct attribute_group *axp20x_groups[] = {
+ &axp20x_group,
+ NULL,
+};
static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
{
@@ -395,7 +423,7 @@ static const struct platform_device_id axp_pek_id_match[] = {
},
{
.name = "axp313a-pek",
- .driver_data = (kernel_ulong_t)&axp20x_info,
+ .driver_data = (kernel_ulong_t)&axp313a_info,
},
{ /* sentinel */ }
};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/2] arm64: dts: qcom: glymur-crd: Add touchscreen node for ft3d81
From: Pradyot Kumar Nayak @ 2026-06-03 3:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov,
Abel Vesa
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Pradyot Kumar Nayak
The touchscreen module on Glymur/Mahua CRDs is a ft3d81 chip which, while
hardware-compatible with the ft8112 (same I2C-HID protocol, same
power-on/reset sequencing), requires the reset-gpios line to be
explicitly wired up in the DT. Without it the reset line remains
permanently asserted after a suspend/resume cycle and all subsequent
I2C transactions fail with -ENXIO.
V2 incorrectly used the generic hid-over-i2c binding. V3
takes a cleaner approach: extend the chip-specific focaltech,ft8112
binding to cover the ft3d81 (they share the same driver) and switch
the glymur-crd node to that binding. This removes the dependency on
the hid-over-i2c properties (hid-descr-addr) and aligns the supply
property names (vcc33-supply / vccio-supply) with the binding schema.
v1: https://lore.kernel.org/linux-arm-msm/20260522-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-v1-1-c7653924acdc@oss.qualcomm.com/
Changes in v1:
- Initial submission: add reset-gpios to touchscreen node in glymur-crd.dtsi
v2: https://lore.kernel.org/linux-arm-msm/20260523-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-v2-0-5c333051e5bb@oss.qualcomm.com/
Changes in v2:
- Add dt-bindings patch to document reset-gpios in hid-over-i2c schema
(flagged by dtbs_check on v1)
- No change to the DTS patch itself
Changes in v3:
- Drop prerequisite-message-id; series is now self-contained
- Patch 1 (new): add focaltech,ft3d81 to the focaltech,ft8112
binding compatible enum
- Patch 2: Added focaltech,ft3d81 Dt suuport which is hardware-compatible with the ft8112
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
---
Pradyot Kumar Nayak (2):
dt-bindings: input: focaltech,ft8112: Add focaltech,ft3d81 compatible
arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support
Documentation/devicetree/bindings/input/focaltech,ft8112.yaml | 9 +++++++--
arch/arm64/boot/dts/qcom/glymur-crd.dts | 9 +++++----
2 files changed, 12 insertions(+), 6 deletions(-)
---
base-commit: 08484c504b55a98bd100527fbe10a3caf55ff3ff
change-id: 20260523-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen
Best regards,
--
Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: input: focaltech,ft8112: Add focaltech,ft3d81 compatible
From: Pradyot Kumar Nayak @ 2026-06-03 3:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov,
Abel Vesa
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Pradyot Kumar Nayak
In-Reply-To: <20260603-arm64-dts-glymur-crd-add-reset-gpio-to-v3-0-3453ef577bcf@oss.qualcomm.com>
The Focaltech ft3d81 is fully compatible with the ft8112 i.e.
it uses the same I2C-HID protocol and the same power-on/reset sequencing,
DT nodes for boards carrying an ft3d81,can therefore bind to the existing
ft8112 driver without any additional changes.
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
---
Documentation/devicetree/bindings/input/focaltech,ft8112.yaml | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml b/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
index 197f30b14d45..5ffa1246aba1 100644
--- a/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
+++ b/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
@@ -18,8 +18,13 @@ allOf:
properties:
compatible:
- enum:
- - focaltech,ft8112
+ oneOf:
+ - items:
+ - enum:
+ - focaltech,ft3d81
+ - const: focaltech,ft8112
+ - enum:
+ - focaltech,ft8112
reg:
maxItems: 1
--
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