* Re: [PATCH bpf-next v1 08/10] bpf: Add bpf_task_work_schedule_* kfuncs with KF_IMPLICIT_ARGS
From: Ihor Solodrai @ 2026-01-12 18:53 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Eduard Zingerman, Mykyta Yatsenko, Tejun Heo,
Alan Maguire, Benjamin Tissoires, Jiri Kosina, bpf, LKML,
open list:HID CORE LAYER, sched-ext
In-Reply-To: <f0e63b55-65c3-4367-b3da-275df18147a1@linux.dev>
On 1/9/26 1:56 PM, Ihor Solodrai wrote:
> On 1/9/26 1:49 PM, Alexei Starovoitov wrote:
>> On Fri, Jan 9, 2026 at 1:39 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>>
>>> [...]
>>>
>>>> I feel bpf_task_work_schedule_resume() is ok to break, since it's so new.
>>>> We can remove bpf_task_work_schedule_[resume|singal]_impl()
>>>> to avoid carrying forward forever.
>>>>
>>>> bpf_stream_vprintk_impl() is not that clear. I would remove it too.
>>>
>>> That leaves only bpf_wq_set_callback_impl(). Can we break that too?
>>
>> Sounds like Benjamin is ok removing it.
>> So I think we can indeed remove them all.
>>
>>> Then there won't be legacy cases at all. It was introduced in v6.16
>>> along the with __prog suffix [1][2].
>>>
>>> If we go this route, we could clean up __prog support/docs too.
>>>
>>> I think it's worth it to make an "all or nothing" decision here:
>>> either break all 4 existing kfuncs, or backwards-support all of them.
>>
>> I don't see why "all or nothing" is a good thing.
>> It won't be "all" anyway.
>> We have bpf_rbtree_add_impl(), bpf_list_push_front_impl(), etc.
>> And those we cannot remove. sched-ext is using them.
>> Another few categories are bpf_obj_new_impl(), bpf_obj_drop_impl().
>> There are not __prog type, but conceptually the same thing and
>> KF_IMPLICIT_ARGS should support them too eventually.
>
> I was thinking we could remove/simplify code relevant to backwards
> compat of existing _impl kfuncs. But you're right, if we start using
> implicit args for other types/kfuncs, the "legacy" case still has to
> work.
>
> Ok, in the next revision I'll remove all the __prog users, but leave
> the "legacy" case support in place for future use.
I just had an off-list chat with Andrii, and we agreed that leaving
the existing _impl kfuncs supported may be a good idea.
It doesn't cost us much: we keep the mechanism for legacy functions
anyways, so supporting bpf_wq_set_callback_impl() and co only requires
keeping definitions in the kernel.
The only benefit of *removing* these _impl functions is that we could
clean up __prog support.
But having backwards compat seems like a better deal.
What do you think?
>
>>
>>
>>> git tag --contains bc049387b41f | grep -v rc
>>> v6.16
>>> v6.17
>>> v6.18
>>>
>>> [1] https://lore.kernel.org/all/20250513142812.1021591-1-memxor@gmail.com/
>>> [2] https://lore.kernel.org/all/20240420-bpf_wq-v2-13-6c986a5a741f@kernel.org/
>>>
>>>
>
^ permalink raw reply
* Re: [PATCH v2 02/16] HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
From: Mark Pearson @ 2026-01-12 18:20 UTC (permalink / raw)
To: Derek J . Clark, Jiri Kosina
Cc: Benjamin Tissoires, Limonciello, Mario, Zhixin Zhang, Mia Shao,
Pierre-Loup A . Griffais, linux-input, linux-doc, linux-kernel
In-Reply-To: <6BB4F74A-F440-4F21-B094-62CFD18C599A@gmail.com>
On Mon, Jan 12, 2026, at 12:40 PM, Derek J. Clark wrote:
> On January 12, 2026 4:12:43 AM PST, Jiri Kosina <jikos@kernel.org> wrote:
>>On Mon, 29 Dec 2025, Derek J. Clark wrote:
>>
>>> Adds initial framework for a new HID driver, hid-lenovo-go, along with
>>> attributes that report the firmware and hardware version for each
>>> component of the HID device, of which there are 4 parts: The MCU, the
>>> transmission dongle, the left "handle" controller half, and the right
>>> "handle" controller half. Each of these devices are provided an attribute
>>> group to contain its device specific attributes. Additionally, the touchpad
>>> device attributes are logically separated from the other components in
>>> another attribute group.
>>>
>>> This driver primarily provides access to the configurable settings of the
>>> Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest
>>> firmware. As previously noted, the Legion Go controllers recently had a
>>> firmware update[1] which switched from the original "SepentiaUSB" protocol
>>> to a brand new protocol for the Go 2, primarily to ensure backwards and
>>> forwards compatibility between the Go and Go 2 devices. As part of that
>>> update the PIDs for the controllers were changed, so there is no risk of
>>> this driver attaching to controller firmware that it doesn't support.
>>>
>>> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
>>> ---
>>> MAINTAINERS | 6 +
>>> drivers/hid/Kconfig | 12 +
>>> drivers/hid/Makefile | 1 +
>>> drivers/hid/hid-ids.h | 3 +
>>> drivers/hid/hid-lenovo-go.c | 734 ++++++++++++++++++++++++++++++++++++
>>> 5 files changed, 756 insertions(+)
>>> create mode 100644 drivers/hid/hid-lenovo-go.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 9ed6d11a7746..b5ad29d24e3e 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -14135,6 +14135,12 @@ L: platform-driver-x86@vger.kernel.org
>>> S: Maintained
>>> F: drivers/platform/x86/lenovo/wmi-hotkey-utilities.c
>>>
>>> +LENOVO HID drivers
>>> +M: Derek J. Clark <derekjohn.clark@gmail.com>
>>> +L: linux-input@vger.kernel.org
>>> +S: Maintained
>>> +F: drivers/hid/hid-lenovo-go.c
>>
>>Hi Derek,
>>
>>thanks for working on this.
>>
>>I am now almost finished with reviewing this pile and am planning to queue
>>it in hid.git shortly, but I have a question regarding the MAINTAINERS
>>entry above.
>>
>>The title claims support for all of Lenovo HID, but there is much more to
>>it than drivers/hid/hid-lenovo-go.c, specifically in hid-lenovo.c.
>>
>>So either please make the title more specific (or claim the ownership of
>>the whole Lenovo HID landscape indeed, fine by me, but the please reflect
>>that in F: :) ).
>>
>>Thanks,
>>
>
> Hi Jiri
>
> Sure, I've debated using LENOVO LEGION GO HID drivers and LENOVO GO HID
> drivers. Do you have a preference? The other drivers are pretty old and
> I don't have any hardware that would use them so I'd prefer to keep
> them separate (though I'll acknowledge that they don't seem to have a
> MAINTAINERS entry)
>
I should probably take a better look at the lenovo-hid driver.
The platforms that it's supporting weren't in the Linux program, so it never crossed my path before - but looking ahead I think we may need to contribute some changes there (guessing a little, but I'll know in a few months time).
Jiri - as that driver is targeted for Thinkpads, I'm OK to take some responsibility for it if that is useful/helpful.
Mark
^ permalink raw reply
* Re: [PATCH v2 02/16] HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
From: Derek J. Clark @ 2026-01-12 17:40 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Mario Limonciello, Zhixin Zhang, Mia Shao,
Mark Pearson, Pierre-Loup A . Griffais, linux-input, linux-doc,
linux-kernel
In-Reply-To: <0on4p9s6-7512-9408-49no-3292o86113r3@xreary.bet>
On January 12, 2026 4:12:43 AM PST, Jiri Kosina <jikos@kernel.org> wrote:
>On Mon, 29 Dec 2025, Derek J. Clark wrote:
>
>> Adds initial framework for a new HID driver, hid-lenovo-go, along with
>> attributes that report the firmware and hardware version for each
>> component of the HID device, of which there are 4 parts: The MCU, the
>> transmission dongle, the left "handle" controller half, and the right
>> "handle" controller half. Each of these devices are provided an attribute
>> group to contain its device specific attributes. Additionally, the touchpad
>> device attributes are logically separated from the other components in
>> another attribute group.
>>
>> This driver primarily provides access to the configurable settings of the
>> Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest
>> firmware. As previously noted, the Legion Go controllers recently had a
>> firmware update[1] which switched from the original "SepentiaUSB" protocol
>> to a brand new protocol for the Go 2, primarily to ensure backwards and
>> forwards compatibility between the Go and Go 2 devices. As part of that
>> update the PIDs for the controllers were changed, so there is no risk of
>> this driver attaching to controller firmware that it doesn't support.
>>
>> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
>> ---
>> MAINTAINERS | 6 +
>> drivers/hid/Kconfig | 12 +
>> drivers/hid/Makefile | 1 +
>> drivers/hid/hid-ids.h | 3 +
>> drivers/hid/hid-lenovo-go.c | 734 ++++++++++++++++++++++++++++++++++++
>> 5 files changed, 756 insertions(+)
>> create mode 100644 drivers/hid/hid-lenovo-go.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9ed6d11a7746..b5ad29d24e3e 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14135,6 +14135,12 @@ L: platform-driver-x86@vger.kernel.org
>> S: Maintained
>> F: drivers/platform/x86/lenovo/wmi-hotkey-utilities.c
>>
>> +LENOVO HID drivers
>> +M: Derek J. Clark <derekjohn.clark@gmail.com>
>> +L: linux-input@vger.kernel.org
>> +S: Maintained
>> +F: drivers/hid/hid-lenovo-go.c
>
>Hi Derek,
>
>thanks for working on this.
>
>I am now almost finished with reviewing this pile and am planning to queue
>it in hid.git shortly, but I have a question regarding the MAINTAINERS
>entry above.
>
>The title claims support for all of Lenovo HID, but there is much more to
>it than drivers/hid/hid-lenovo-go.c, specifically in hid-lenovo.c.
>
>So either please make the title more specific (or claim the ownership of
>the whole Lenovo HID landscape indeed, fine by me, but the please reflect
>that in F: :) ).
>
>Thanks,
>
Hi Jiri
Sure, I've debated using LENOVO LEGION GO HID drivers and LENOVO GO HID drivers. Do you have a preference? The other drivers are pretty old and I don't have any hardware that would use them so I'd prefer to keep them separate (though I'll acknowledge that they don't seem to have a MAINTAINERS entry)
I also need to fix the ABI docs, I accidentally added an extra + character to every line in the patch for both. I'll update that too when I fix this.
Thanks,
Derek
^ permalink raw reply
* Re: [PATCH 09/12] HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
From: kernel test robot @ 2026-01-12 17:31 UTC (permalink / raw)
To: Bastien Nocera, linux-input
Cc: oe-kbuild-all, linux-kernel, Jiri Kosina, Benjamin Tissoires,
Bastien Nocera
In-Reply-To: <20260112105500.3664834-10-hadess@hadess.net>
Hi Bastien,
kernel test robot noticed the following build errors:
[auto build test ERROR on hid/for-next]
[also build test ERROR on linus/master v6.19-rc5 next-20260109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Bastien-Nocera/HID-hid-alps-Use-pm_ptr-instead-of-ifdef-CONFIG_PM/20260112-190559
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20260112105500.3664834-10-hadess%40hadess.net
patch subject: [PATCH 09/12] HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
config: parisc-defconfig (https://download.01.org/0day-ci/archive/20260113/202601130046.THZRFNIA-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601130046.THZRFNIA-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601130046.THZRFNIA-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:36,
from include/linux/random.h:7,
from include/linux/nodemask.h:94,
from include/linux/numa.h:6,
from include/linux/cpumask.h:15,
from include/linux/smp.h:13,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:63,
from include/linux/sched.h:37,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/hid/hid-sony.c:31:
>> drivers/hid/hid-sony.c:2402:36: error: 'sony_suspend' undeclared here (not in a function)
2402 | .suspend = pm_ptr(sony_suspend),
| ^~~~~~~~~~~~
include/linux/util_macros.h:136:44: note: in definition of macro 'PTR_IF'
136 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
| ^~~
drivers/hid/hid-sony.c:2402:29: note: in expansion of macro 'pm_ptr'
2402 | .suspend = pm_ptr(sony_suspend),
| ^~~~~~
>> drivers/hid/hid-sony.c:2403:36: error: 'sony_resume' undeclared here (not in a function); did you mean 'sony_remove'?
2403 | .resume = pm_ptr(sony_resume),
| ^~~~~~~~~~~
include/linux/util_macros.h:136:44: note: in definition of macro 'PTR_IF'
136 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
| ^~~
drivers/hid/hid-sony.c:2403:29: note: in expansion of macro 'pm_ptr'
2403 | .resume = pm_ptr(sony_resume),
| ^~~~~~
vim +/sony_suspend +2402 drivers/hid/hid-sony.c
2392
2393 static struct hid_driver sony_driver = {
2394 .name = "sony",
2395 .id_table = sony_devices,
2396 .input_mapping = sony_mapping,
2397 .input_configured = sony_input_configured,
2398 .probe = sony_probe,
2399 .remove = sony_remove,
2400 .report_fixup = sony_report_fixup,
2401 .raw_event = sony_raw_event,
> 2402 .suspend = pm_ptr(sony_suspend),
> 2403 .resume = pm_ptr(sony_resume),
2404 .reset_resume = pm_ptr(sony_resume),
2405 };
2406
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 00/12] HID: Use pm_*ptr instead of #ifdef CONFIG_PM*
From: Jiri Kosina @ 2026-01-12 17:03 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Bastien Nocera, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <raxul2tp5zvlzktqnspl5pdu6u4433zlyzduonxy2plyoehzov@7qb7ldg3gy6m>
On Mon, 12 Jan 2026, Benjamin Tissoires wrote:
> > > All those changes should be safe, as similar ones were done in other
> > > subsystems, but I'm uncertain about the surface changes.
> > >
> > > Bastien Nocera (12):
> > > HID: hid-alps: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: appletb-kbd: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: asus: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: lenovo: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: logitech-dj: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: nintendo: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: picolcd_core: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: hid-sensor-hub: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: uclogic: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: wacom: Use pm_ptr instead of #ifdef CONFIG_PM
> > > HID: surface: Use pm_ptr_sleep instead of #ifdef CONFIG_PM_SLEEP
> > >
> > > drivers/hid/hid-alps.c | 6 ++----
> > > drivers/hid/hid-appletb-kbd.c | 6 ++----
> > > drivers/hid/hid-asus.c | 6 ++----
> > > drivers/hid/hid-lenovo.c | 4 +---
> > > drivers/hid/hid-logitech-dj.c | 4 +---
> > > drivers/hid/hid-nintendo.c | 7 ++-----
> > > drivers/hid/hid-picolcd_core.c | 8 +++-----
> > > drivers/hid/hid-sensor-hub.c | 8 +++-----
> > > drivers/hid/hid-sony.c | 9 +++------
> > > drivers/hid/hid-uclogic-core.c | 6 ++----
> > > drivers/hid/surface-hid/surface_hid.c | 2 +-
> > > drivers/hid/surface-hid/surface_hid_core.c | 5 -----
> > > drivers/hid/surface-hid/surface_kbd.c | 2 +-
> > > drivers/hid/wacom_sys.c | 6 ++----
> > > 14 files changed, 25 insertions(+), 54 deletions(-)
> >
> > Thanks Bastien, this is now in hid.git#for-6.20/pm_ptr.
> >
>
> There is something wrong with the series:
> https://gitlab.freedesktop.org/bentiss/hid/-/jobs/90949365
Yeah, and 0day bot found another issue. Dropping for now, this needs more
polishing apparently :)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 12/12] HID: surface: Use pm_ptr_sleep instead of #ifdef CONFIG_PM_SLEEP
From: kernel test robot @ 2026-01-12 17:00 UTC (permalink / raw)
To: Bastien Nocera, linux-input
Cc: llvm, oe-kbuild-all, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Bastien Nocera
In-Reply-To: <20260112105500.3664834-13-hadess@hadess.net>
Hi Bastien,
kernel test robot noticed the following build errors:
[auto build test ERROR on hid/for-next]
[also build test ERROR on linus/master v6.19-rc5 next-20260109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Bastien-Nocera/HID-hid-alps-Use-pm_ptr-instead-of-ifdef-CONFIG_PM/20260112-190559
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20260112105500.3664834-13-hadess%40hadess.net
patch subject: [PATCH 12/12] HID: surface: Use pm_ptr_sleep instead of #ifdef CONFIG_PM_SLEEP
config: x86_64-buildonly-randconfig-006-20260112 (https://download.01.org/0day-ci/archive/20260113/202601130046.aUeJ5BLs-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601130046.aUeJ5BLs-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601130046.aUeJ5BLs-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/hid/surface-hid/surface_kbd.c:291:9: error: call to undeclared function 'pm_ptr_sleep'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
291 | .pm = pm_ptr_sleep(&surface_hid_pm_ops),
| ^
>> drivers/hid/surface-hid/surface_kbd.c:291:9: error: incompatible integer to pointer conversion initializing 'const struct dev_pm_ops *' with an expression of type 'int' [-Wint-conversion]
291 | .pm = pm_ptr_sleep(&surface_hid_pm_ops),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/hid/surface-hid/surface_kbd.c:291:9: error: initializer element is not a compile-time constant
291 | .pm = pm_ptr_sleep(&surface_hid_pm_ops),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
vim +/pm_ptr_sleep +291 drivers/hid/surface-hid/surface_kbd.c
284
285 static struct platform_driver surface_kbd_driver = {
286 .probe = surface_kbd_probe,
287 .remove = surface_kbd_remove,
288 .driver = {
289 .name = "surface_keyboard",
290 .acpi_match_table = surface_kbd_match,
> 291 .pm = pm_ptr_sleep(&surface_hid_pm_ops),
292 .probe_type = PROBE_PREFER_ASYNCHRONOUS,
293 },
294 };
295 module_platform_driver(surface_kbd_driver);
296
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 00/12] HID: Use pm_*ptr instead of #ifdef CONFIG_PM*
From: Benjamin Tissoires @ 2026-01-12 17:00 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Bastien Nocera, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <p75339q9-1r03-n389-92q7-7q9snq091p79@xreary.bet>
On Jan 12 2026, Jiri Kosina wrote:
> On Mon, 12 Jan 2026, Bastien Nocera wrote:
>
> > All those changes should be safe, as similar ones were done in other
> > subsystems, but I'm uncertain about the surface changes.
> >
> > Bastien Nocera (12):
> > HID: hid-alps: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: appletb-kbd: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: asus: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: lenovo: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: logitech-dj: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: nintendo: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: picolcd_core: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: hid-sensor-hub: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: uclogic: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: wacom: Use pm_ptr instead of #ifdef CONFIG_PM
> > HID: surface: Use pm_ptr_sleep instead of #ifdef CONFIG_PM_SLEEP
> >
> > drivers/hid/hid-alps.c | 6 ++----
> > drivers/hid/hid-appletb-kbd.c | 6 ++----
> > drivers/hid/hid-asus.c | 6 ++----
> > drivers/hid/hid-lenovo.c | 4 +---
> > drivers/hid/hid-logitech-dj.c | 4 +---
> > drivers/hid/hid-nintendo.c | 7 ++-----
> > drivers/hid/hid-picolcd_core.c | 8 +++-----
> > drivers/hid/hid-sensor-hub.c | 8 +++-----
> > drivers/hid/hid-sony.c | 9 +++------
> > drivers/hid/hid-uclogic-core.c | 6 ++----
> > drivers/hid/surface-hid/surface_hid.c | 2 +-
> > drivers/hid/surface-hid/surface_hid_core.c | 5 -----
> > drivers/hid/surface-hid/surface_kbd.c | 2 +-
> > drivers/hid/wacom_sys.c | 6 ++----
> > 14 files changed, 25 insertions(+), 54 deletions(-)
>
> Thanks Bastien, this is now in hid.git#for-6.20/pm_ptr.
>
There is something wrong with the series:
https://gitlab.freedesktop.org/bentiss/hid/-/jobs/90949365
```
In file included from ./include/linux/kernel.h:36,
from ./include/linux/random.h:7,
from ./include/linux/nodemask.h:94,
from ./include/linux/numa.h:6,
from ./include/linux/cpumask.h:15,
from ./arch/x86/include/asm/cpumask.h:7,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/tsc.h:11,
from ./arch/x86/include/asm/timex.h:6,
from ./include/linux/timex.h:67,
from ./include/linux/time32.h:13,
from ./include/linux/time.h:60,
from ./include/linux/stat.h:19,
from ./include/linux/module.h:13,
from drivers/hid/hid-lenovo.c:27:
drivers/hid/hid-lenovo.c:1573:32: error: 'lenovo_reset_resume' undeclared here (not in a function); did you mean 'hidinput_reset_resume'?
1573 | .reset_resume = pm_ptr(lenovo_reset_resume),
| ^~~~~~~~~~~~~~~~~~~
./include/linux/util_macros.h:136:44: note: in definition of macro 'PTR_IF'
136 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
| ^~~
drivers/hid/hid-lenovo.c:1573:25: note: in expansion of macro 'pm_ptr'
1573 | .reset_resume = pm_ptr(lenovo_reset_resume),
| ^~~~~~
make[4]: *** [scripts/Makefile.build:287: drivers/hid/hid-lenovo.o] Error 1
```
Bastien, are you sure that's the only change required?
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH bpf-next v1 05/10] selftests/bpf: Add tests for KF_IMPLICIT_ARGS
From: Andrii Nakryiko @ 2026-01-12 16:55 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Eduard Zingerman, Mykyta Yatsenko, Tejun Heo,
Alan Maguire, Benjamin Tissoires, Jiri Kosina, bpf, linux-kernel,
linux-input, sched-ext
In-Reply-To: <32fe65fa-ecfb-4cba-bd0c-61155bca637b@linux.dev>
On Fri, Jan 9, 2026 at 5:30 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 1/9/26 3:25 PM, Andrii Nakryiko wrote:
> > On Fri, Jan 9, 2026 at 10:49 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> >
> > [...]
> >
> >> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> >> index 1c41d03bd5a1..503451875d33 100644
> >> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> >> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> >> @@ -1136,6 +1136,10 @@ __bpf_kfunc int bpf_kfunc_st_ops_inc10(struct st_ops_args *args)
> >> __bpf_kfunc int bpf_kfunc_multi_st_ops_test_1(struct st_ops_args *args, u32 id);
> >> __bpf_kfunc int bpf_kfunc_multi_st_ops_test_1_impl(struct st_ops_args *args, void *aux_prog);
> >>
> >> +__bpf_kfunc int bpf_kfunc_implicit_arg(int a, struct bpf_prog_aux *aux);
> >> +__bpf_kfunc int bpf_kfunc_implicit_arg_legacy(int a, int b, struct bpf_prog_aux *aux);
> >> +__bpf_kfunc int bpf_kfunc_implicit_arg_legacy_impl(int a, int b, void *aux__prog);
> >> +
> >> BTF_KFUNCS_START(bpf_testmod_check_kfunc_ids)
> >> BTF_ID_FLAGS(func, bpf_testmod_test_mod_kfunc)
> >> BTF_ID_FLAGS(func, bpf_kfunc_call_test1)
> >> @@ -1178,6 +1182,9 @@ BTF_ID_FLAGS(func, bpf_kfunc_st_ops_test_pro_epilogue, KF_SLEEPABLE)
> >> BTF_ID_FLAGS(func, bpf_kfunc_st_ops_inc10)
> >> BTF_ID_FLAGS(func, bpf_kfunc_multi_st_ops_test_1)
> >> BTF_ID_FLAGS(func, bpf_kfunc_multi_st_ops_test_1_impl)
> >> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg, KF_IMPLICIT_ARGS)
> >> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg_legacy, KF_IMPLICIT_ARGS)
> >> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg_legacy_impl)
> >
> > (irrelevant, now that I saw patch #8 discussion, but for the future
> > the point will stand and we can decide how resolve_btfids handles this
> > upfront)
> >
> > I'm wondering, should we add KF_IMPLICIT_ARGS to legacy xxx_impl
> > kfuncs as well to explicitly mark them to resolve_btfids as legacy
> > implementations? And if we somehow find xxx_impl without it, then
> > resolve_btfids complains louds and fails, this should never happen?
>
> Eh... I don't like the idea of flagging both foo and foo_impl.
>
> If we use the same flag for legacy funcs, the flag becomes
> insufficient to determine whether a function is legacy or not: we also
> have to check the name (or something). This could be a different flag,
> but I don't like that either.
>
> For legacy kfuncs that we want to support, I don't think we have to
> enforce anything. We allow to use old API, and the new one if it's
> implemented.
>
> Are you suggesting to ban _impl suffix in names of new kfuncs?
> Fail build on accidental name collision?
This is super low probability, but yes, I was trying to avoid
accidental _impl-named functions to be reused. But as I said, I don't
believe this will happen in practice, so might as well just ignore
this, if you don't like KF_IMPLICIT_ARGS for legacy stuff.
>
> We could implement sanity checks like these as separate passes in
> resolve_btfids, for example.
>
> >
> >
> >
> >> BTF_KFUNCS_END(bpf_testmod_check_kfunc_ids)
> >>
> >> static int bpf_testmod_ops_init(struct btf *btf)
> >> @@ -1669,6 +1676,25 @@ int bpf_kfunc_multi_st_ops_test_1_impl(struct st_ops_args *args, void *aux__prog
> >> return ret;
> >> }
> >>
> >> +int bpf_kfunc_implicit_arg(int a, struct bpf_prog_aux *aux)
> >> +{
> >> + if (aux && a > 0)
> >> + return a;
> >> + return -EINVAL;
> >> +}
> >> +
> >> +int bpf_kfunc_implicit_arg_legacy(int a, int b, struct bpf_prog_aux *aux)
> >> +{
> >> + if (aux)
> >> + return a + b;
> >> + return -EINVAL;
> >> +}
> >> +
> >> +int bpf_kfunc_implicit_arg_legacy_impl(int a, int b, void *aux__prog)
> >> +{
> >> + return bpf_kfunc_implicit_arg_legacy(a, b, aux__prog);
> >> +}
> >> +
> >> static int multi_st_ops_reg(void *kdata, struct bpf_link *link)
> >> {
> >> struct bpf_testmod_multi_st_ops *st_ops =
> >> --
> >> 2.52.0
> >>
>
^ permalink raw reply
* Re: [PATCH bpf-next v1 04/10] resolve_btfids: Support for KF_IMPLICIT_ARGS
From: Andrii Nakryiko @ 2026-01-12 16:51 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Eduard Zingerman, Mykyta Yatsenko, Tejun Heo,
Alan Maguire, Benjamin Tissoires, Jiri Kosina, bpf, linux-kernel,
linux-input, sched-ext
In-Reply-To: <2ea17ba8-3248-4a01-8fed-183ce66aa39c@linux.dev>
On Fri, Jan 9, 2026 at 5:15 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 1/9/26 3:25 PM, Andrii Nakryiko wrote:
> > On Fri, Jan 9, 2026 at 10:49 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> >>
> >> Implement BTF modifications in resolve_btfids to support BPF kernel
> >> functions with implicit arguments.
> >>
> >> For a kfunc marked with KF_IMPLICIT_ARGS flag, a new function
> >> prototype is added to BTF that does not have implicit arguments. The
> >> kfunc's prototype is then updated to a new one in BTF. This prototype
> >> is the intended interface for the BPF programs.
> >>
> >> A <func_name>_impl function is added to BTF to make the original kfunc
> >> prototype searchable for the BPF verifier. If a <func_name>_impl
> >> function already exists in BTF, its interpreted as a legacy case, and
> >> this step is skipped.
> >>
> >> Whether an argument is implicit is determined by its type:
> >> currently only `struct bpf_prog_aux *` is supported.
> >>
> >> As a result, the BTF associated with kfunc is changed from
> >>
> >> __bpf_kfunc bpf_foo(int arg1, struct bpf_prog_aux *aux);
> >>
> >> into
> >>
> >> bpf_foo_impl(int arg1, struct bpf_prog_aux *aux);
> >> __bpf_kfunc bpf_foo(int arg1);
> >>
> >> For more context see previous discussions and patches [1][2].
> >>
> >> [1] https://lore.kernel.org/dwarves/ba1650aa-fafd-49a8-bea4-bdddee7c38c9@linux.dev/
> >> [2] https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/
> >>
> >> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> >> ---
> >> tools/bpf/resolve_btfids/main.c | 282 ++++++++++++++++++++++++++++++++
> >> 1 file changed, 282 insertions(+)
> >>
> >> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> >> index df39982f51df..b361e726fa36 100644
> >> --- a/tools/bpf/resolve_btfids/main.c
> >> +++ b/tools/bpf/resolve_btfids/main.c
> >> @@ -152,6 +152,18 @@ struct object {
> >> int nr_typedefs;
> >> };
> >>
> >> +#define KF_IMPLICIT_ARGS (1 << 16)
> >> +#define KF_IMPL_SUFFIX "_impl"
> >> +#define MAX_BPF_FUNC_REG_ARGS 5
> >> +#define MAX_KFUNCS 256
> >> +#define MAX_DECL_TAGS (MAX_KFUNCS * 4)
> >
> > can't we get that from include/linux/bpf.h? seems like
> > resolve_btfids's main.c include internal headers just fine, so why
> > duplicate definitions?
>
> Hi Andrii, thank you for a quick review.
>
> Including internal include/linux/btf.h directly doesn't work, which is
> probably expected.
>
> resolve_btfids is currently built with:
>
> HOSTCFLAGS_resolve_btfids += -g \
> -I$(srctree)/tools/include \
> -I$(srctree)/tools/include/uapi \
so I don't know if that will solve the issue, but I don't think it
makes sense to build resolve_btfids using tools' version of includes.
tools/include is mostly for perf's benefit (maybe so that they don't
accidentally take some kernel-internal dependency, not sure). But
resolve_btfids is built for the kernel during the kernel build, we
should have access to full kernel headers. Try changing this and see
if build errors go away?
> -I$(LIBBPF_INCLUDE) \
> -I$(SUBCMD_INCLUDE) \
> $(LIBELF_FLAGS) \
> -Wall -Werror
>
> If I add -I$(srctree)/include option and then
>
> #include <linux/btf.h>
>
> A bunch of build errors happen.
>
> AFAIU we'd have to create a stripped copy of relevant headers in
> tools/include first. Is that what you're suggesting?
see above, the opposite -- just use -I$(srctree)/include directly
[...]
> >> + addr = id->addr[0];
> >> + off = addr - obj->efile.idlist_addr;
> >> + set8 = data->d_buf + off;
> >> +
> >> + for (i = 0; i < set8->cnt; i++) {
> >> + if (set8->pairs[i].flags & flags) {
> >
> > invert condition and continue, reduce nesting?
> >
> >> + if (nr_kfuncs >= kfunc_ids_sz) {
> >
> > it's silly to set static limits like this: we are not in NMI, you have
> > memory allocator, use it
>
> I kinda like that btf2btf_context is stack allocated, but I see your
> point. It's not necessary to set hard limits in resolve_btfids.
>
I don't think we'll notice the performance difference. We had similar
statically-sized things for BTF processing in pahole, and very quickly
ran into limitations and had to change them to dynamically allocated.
Let's not do this again. realloc() is a bit more annoying to use, but
no big deal, it's C after all.
> >
> >> + pr_err("ERROR: resolve_btfids: too many kfuncs with flags %u - limit %d\n",
> >> + flags, kfunc_ids_sz);
> >> + return -E2BIG;
> >> + }
> >> + kfunc_ids[nr_kfuncs++] = set8->pairs[i].id;
[...]
> >> + err = btf__add_decl_tag(btf, tag_name, new_func_id, -1);
> >
> > decl_tag can apply to arguments as well (that -1 will be actually >=
> > 0), we should copy those as well, no?
>
> I think you're right. Technically decl_tags can point to parameters as
> well. Is this actually used in kernel BTF?
I don't remember, but it doesn't matter. We have to clone them as well.
>
> For the type tags we don't have to do anything though, because the
> param type should point to the top type tag, right?
Yeah, type tags are part of type chains, if we reuse types, we'll be
reusing type_tags.
>
> >
> >> + if (err < 0) {
> >> + pr_err("ERROR: resolve_btfids: failed to add decl tag %s for %s\n",
> >> + tag_name, tmp_name);
> >> + return -EINVAL;
> >> + }
> >> + }
> >> +
[...]
^ permalink raw reply
* Re: [PATCH] HID: sony: add support for bluetooth Rock Band 4 PS4 guitars
From: Jiri Kosina @ 2026-01-12 16:46 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260111210051.51743-2-rosalie@mailbox.org>
On Sun, 11 Jan 2026, Rosalie Wanders wrote:
> This commit adds support for the PDP Jaguar and MadCatz Stratocaster.
Queued in hid.git#for-6.20/sony, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 00/12] HID: Use pm_*ptr instead of #ifdef CONFIG_PM*
From: Jiri Kosina @ 2026-01-12 16:41 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20260112105500.3664834-1-hadess@hadess.net>
On Mon, 12 Jan 2026, Bastien Nocera wrote:
> All those changes should be safe, as similar ones were done in other
> subsystems, but I'm uncertain about the surface changes.
>
> Bastien Nocera (12):
> HID: hid-alps: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: appletb-kbd: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: asus: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: lenovo: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: logitech-dj: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: nintendo: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: picolcd_core: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: hid-sensor-hub: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: uclogic: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: wacom: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: surface: Use pm_ptr_sleep instead of #ifdef CONFIG_PM_SLEEP
>
> drivers/hid/hid-alps.c | 6 ++----
> drivers/hid/hid-appletb-kbd.c | 6 ++----
> drivers/hid/hid-asus.c | 6 ++----
> drivers/hid/hid-lenovo.c | 4 +---
> drivers/hid/hid-logitech-dj.c | 4 +---
> drivers/hid/hid-nintendo.c | 7 ++-----
> drivers/hid/hid-picolcd_core.c | 8 +++-----
> drivers/hid/hid-sensor-hub.c | 8 +++-----
> drivers/hid/hid-sony.c | 9 +++------
> drivers/hid/hid-uclogic-core.c | 6 ++----
> drivers/hid/surface-hid/surface_hid.c | 2 +-
> drivers/hid/surface-hid/surface_hid_core.c | 5 -----
> drivers/hid/surface-hid/surface_kbd.c | 2 +-
> drivers/hid/wacom_sys.c | 6 ++----
> 14 files changed, 25 insertions(+), 54 deletions(-)
Thanks Bastien, this is now in hid.git#for-6.20/pm_ptr.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Input: serio - complete sizeof(*pointer) conversions
From: Wentong Tian @ 2026-01-12 16:27 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: erick.archer, linux-input, linux-kernel, Wentong Tian
Complete the sizeof(*pointer) conversion for arc_ps2, altera_ps2, and
olpc_apsp drivers. This follows the cleanup initiated in commit
06b449d7f7c3 ("Input: serio - use sizeof(*pointer) instead of sizeof(type)).
Signed-off-by: Wentong Tian <tianwentong2000@gmail.com>
---
drivers/input/serio/altera_ps2.c | 2 +-
drivers/input/serio/arc_ps2.c | 3 +--
drivers/input/serio/olpc_apsp.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/altera_ps2.c b/drivers/input/serio/altera_ps2.c
index aa445b1941e9..761aaaa3e571 100644
--- a/drivers/input/serio/altera_ps2.c
+++ b/drivers/input/serio/altera_ps2.c
@@ -81,7 +81,7 @@ static int altera_ps2_probe(struct platform_device *pdev)
struct serio *serio;
int error, irq;
- ps2if = devm_kzalloc(&pdev->dev, sizeof(struct ps2if), GFP_KERNEL);
+ ps2if = devm_kzalloc(&pdev->dev, sizeof(*ps2if), GFP_KERNEL);
if (!ps2if)
return -ENOMEM;
diff --git a/drivers/input/serio/arc_ps2.c b/drivers/input/serio/arc_ps2.c
index e991c72296c9..29095d8804d2 100644
--- a/drivers/input/serio/arc_ps2.c
+++ b/drivers/input/serio/arc_ps2.c
@@ -189,8 +189,7 @@ static int arc_ps2_probe(struct platform_device *pdev)
if (irq < 0)
return -EINVAL;
- arc_ps2 = devm_kzalloc(&pdev->dev, sizeof(struct arc_ps2_data),
- GFP_KERNEL);
+ arc_ps2 = devm_kzalloc(&pdev->dev, sizeof(*arc_ps2), GFP_KERNEL);
if (!arc_ps2) {
dev_err(&pdev->dev, "out of memory\n");
return -ENOMEM;
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index a24324830021..c07fb8a1799d 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -171,7 +171,7 @@ static int olpc_apsp_probe(struct platform_device *pdev)
struct olpc_apsp *priv;
int error;
- priv = devm_kzalloc(&pdev->dev, sizeof(struct olpc_apsp), GFP_KERNEL);
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Input: pf1550 - cope for CONFIG_PM=n
From: Frank Li @ 2026-01-12 16:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Lee Jones, Samuel Kayode, Dmitry Torokhov, Sean Nyekjaer, imx,
linux-input
In-Reply-To: <20260112161401.3751275-2-u.kleine-koenig@baylibre.com>
On Mon, Jan 12, 2026 at 05:13:59PM +0100, Uwe Kleine-König wrote:
> This fixes the following build failure with CONFIG_PM disabled:
>
> drivers/input/misc/pf1550-onkey.c:154:12: error: ‘pf1550_onkey_resume’ defined but not used [-Werror=unused-function]
> 154 | static int pf1550_onkey_resume(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~
> drivers/input/misc/pf1550-onkey.c:133:12: error: ‘pf1550_onkey_suspend’ defined but not used [-Werror=unused-function]
> 133 | static int pf1550_onkey_suspend(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Fixes: 9acb215cbebd ("Input: pf1550 - add onkey support")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/input/misc/pf1550-onkey.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/pf1550-onkey.c b/drivers/input/misc/pf1550-onkey.c
> index 9be6377151cb..a636ceedfc04 100644
> --- a/drivers/input/misc/pf1550-onkey.c
> +++ b/drivers/input/misc/pf1550-onkey.c
> @@ -173,8 +173,8 @@ static int pf1550_onkey_resume(struct device *dev)
> return 0;
> }
>
> -static SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
> - pf1550_onkey_resume);
> +static DEFINE_SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
> + pf1550_onkey_resume);
>
> static const struct platform_device_id pf1550_onkey_id[] = {
> { "pf1550-onkey", },
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH] Input: pf1550 - cope for CONFIG_PM=n
From: Uwe Kleine-König @ 2026-01-12 16:13 UTC (permalink / raw)
To: Lee Jones
Cc: Samuel Kayode, Dmitry Torokhov, Frank Li, Sean Nyekjaer, imx,
linux-input
This fixes the following build failure with CONFIG_PM disabled:
drivers/input/misc/pf1550-onkey.c:154:12: error: ‘pf1550_onkey_resume’ defined but not used [-Werror=unused-function]
154 | static int pf1550_onkey_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~
drivers/input/misc/pf1550-onkey.c:133:12: error: ‘pf1550_onkey_suspend’ defined but not used [-Werror=unused-function]
133 | static int pf1550_onkey_suspend(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Fixes: 9acb215cbebd ("Input: pf1550 - add onkey support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/input/misc/pf1550-onkey.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/pf1550-onkey.c b/drivers/input/misc/pf1550-onkey.c
index 9be6377151cb..a636ceedfc04 100644
--- a/drivers/input/misc/pf1550-onkey.c
+++ b/drivers/input/misc/pf1550-onkey.c
@@ -173,8 +173,8 @@ static int pf1550_onkey_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
- pf1550_onkey_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(pf1550_onkey_pm_ops, pf1550_onkey_suspend,
+ pf1550_onkey_resume);
static const struct platform_device_id pf1550_onkey_id[] = {
{ "pf1550-onkey", },
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.47.3
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-6.12] HID: logitech: add HID++ support for Logitech MX Anywhere 3S
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Dennis Marttinen, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: Dennis Marttinen <twelho@welho.tech>
[ Upstream commit d7f6629bffdcb962d383ef8c9a30afef81e997fe ]
I've acquired a Logitech MX Anywhere 3S mouse, which supports HID++ over
Bluetooth. Adding its PID 0xb037 to the allowlist enables the additional
features, such as high-resolution scrolling. Tested working across multiple
machines, with a mix of Intel and Mediatek Bluetooth chips.
[jkosina@suse.com: standardize shortlog]
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of HID: logitech: add HID++ support for Logitech MX Anywhere
3S
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** "HID: logitech: add HID++ support for Logitech MX Anywhere
3S"
The commit message explains:
- Author acquired an MX Anywhere 3S mouse that supports HID++ over
Bluetooth
- Adding PID 0xb037 to the allowlist enables additional features (high-
resolution scrolling)
- Tested on multiple machines with Intel and Mediatek Bluetooth chips
- Has proper sign-offs from author and maintainer (Jiri Kosina)
No `Cc: stable` or `Fixes:` tags are present, but as noted, that's
expected for commits undergoing manual review.
### 2. CODE CHANGE ANALYSIS
The actual change is minimal:
```c
+ { /* MX Anywhere 3S mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb037) },
```
This adds exactly **2 lines** - one comment and one device ID entry to
the `hidpp_devices[]` table. Looking at the context, this table already
contains many similar Logitech Bluetooth device entries:
- MX Master (0xb012), MX Master 2S (0xb019), MX Master 3 (0xb023), MX
Master 3S (0xb034)
- MX Anywhere 3 (0xb025), MX Anywhere 3SB (0xb038)
- M720 Triathlon (0xb015), MX Ergo (0xb01d), MX Vertical (0xb020), etc.
The new entry follows the exact same pattern as all existing entries.
### 3. CLASSIFICATION
This is a **NEW DEVICE ID** addition - one of the explicitly allowed
exception categories for stable kernels:
> "Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers - These
are trivial one-line additions that enable hardware support"
Key points:
- The hid-logitech-hidpp driver already exists in stable kernels
- The HID++ protocol support is fully implemented
- Only the Bluetooth device ID 0xb037 is being added
- This is not a new driver or new functionality - it's enabling an
existing driver for new hardware
### 4. SCOPE AND RISK ASSESSMENT
**Risk: EXTREMELY LOW**
| Factor | Assessment |
|--------|------------|
| Lines changed | 2 |
| Files touched | 1 |
| Code logic changed | None |
| Complexity | Zero - pure data table entry |
| Subsystem maturity | Very mature (HID drivers) |
This cannot introduce regressions because:
- No code paths are modified
- No functions are changed
- Only users with this specific mouse over Bluetooth are affected
- If there were somehow an issue, it would only affect that specific
hardware
### 5. USER IMPACT
**Who benefits:** Users with Logitech MX Anywhere 3S mice using
Bluetooth connection
**Without this fix:** The mouse works via basic HID, but lacks:
- High-resolution scrolling
- Battery status reporting
- Other HID++ features that premium Logitech mice support
**Impact level:** The MX Anywhere 3S is a current-generation retail
product that users are actively purchasing. Stable kernel users expect
their hardware to work properly.
### 6. STABILITY INDICATORS
- ✅ Tested by author on multiple machines with different Bluetooth chips
- ✅ Reviewed and signed off by HID maintainer Jiri Kosina
- ✅ Pattern is identical to many existing, working entries
### 7. DEPENDENCY CHECK
**Dependencies:** None
This is a pure data addition. The driver framework already exists in all
stable kernels that have the hid-logitech-hidpp driver. No other commits
are required.
---
## Summary
This commit is a **textbook example of a stable-appropriate device ID
addition**:
1. ✅ **Trivial 2-line change** - Just a device ID added to an existing
table
2. ✅ **No code modifications** - Pure data entry
3. ✅ **Driver already exists** - hid-logitech-hidpp is well-established
in stable
4. ✅ **Follows existing pattern** - Identical format to dozens of other
entries
5. ✅ **Tested** - Verified on multiple hardware configurations
6. ✅ **Zero regression risk** - Only affects users with this specific
hardware
7. ✅ **Real user benefit** - Enables proper hardware support for
current-generation product
8. ✅ **No dependencies** - Can be cleanly cherry-picked to any stable
kernel
The stable kernel rules explicitly allow device ID additions because
they enable hardware support with virtually zero risk. This is precisely
what the "device ID exception" exists for.
**YES**
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index a88f2e5f791c6..9b612f62d0fba 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4661,6 +4661,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb025) },
{ /* MX Master 3S mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+ { /* MX Anywhere 3S mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb037) },
{ /* MX Anywhere 3SB mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-5.10] HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier QR30 (2d99:a101)
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Rodrigo Lugathe da Conceição Alves, Terry Junge,
Jiri Kosina, Sasha Levin, jikos, bentiss, linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: Rodrigo Lugathe da Conceição Alves <lugathe2@gmail.com>
[ Upstream commit 85a866809333cd2bf8ddac93d9a3e3ba8e4f807d ]
The USB speaker has a bug that causes it to reboot when changing the
brightness using the physical knob.
Add a new vendor and product ID entry in hid-ids.h, and register
the corresponding device in hid-quirks.c with the required quirk.
Signed-off-by: Rodrigo Lugathe da Conceição Alves <lugathe2@gmail.com>
Reviewed-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of Commit: HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier
QR30
### 1. COMMIT MESSAGE ANALYSIS
The commit message clearly states:
- **Problem:** USB speaker has a bug causing it to reboot when changing
brightness using the physical knob
- **Solution:** Apply `HID_QUIRK_ALWAYS_POLL` quirk to this device
- Has "Reviewed-by:" and "Signed-off-by:" from the HID maintainer (Jiri
Kosina)
### 2. CODE CHANGE ANALYSIS
The changes are minimal and straightforward:
**hid-ids.h:** Adds 2 new defines
```c
#define USB_VENDOR_ID_EDIFIER 0x2d99
#define USB_DEVICE_ID_EDIFIER_QR30 0xa101
```
**hid-quirks.c:** Adds 1 entry to the quirks table
```c
{ HID_USB_DEVICE(USB_VENDOR_ID_EDIFIER, USB_DEVICE_ID_EDIFIER_QR30),
HID_QUIRK_ALWAYS_POLL },
```
The `HID_QUIRK_ALWAYS_POLL` quirk is well-established and used by dozens
of other devices in this same file (Corsair, Dell, Elan, HP, etc.). It
forces continuous polling which prevents certain hardware misbehaviors.
### 3. CLASSIFICATION
This falls into the **"QUIRKS and WORKAROUNDS" exception category** that
is explicitly allowed in stable:
- Hardware-specific quirk for a buggy/non-compliant device
- Uses existing, well-tested quirk infrastructure
- Pattern matches many other similar entries already in stable trees
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed:** 3 lines added (2 defines + 1 quirk entry)
- **Files touched:** 2 (hid-ids.h, hid-quirks.c)
- **Risk level:** Extremely low
- **Blast radius:** Only affects users with this specific Edifier QR30
device
- **Regression potential:** Zero for other devices - the quirk entry is
device-specific by USB vendor/product ID
### 5. USER IMPACT
- **Severity:** Device rebooting is a significant user-visible bug
- **Affected users:** Anyone with an Edifier QR30 USB speaker
- **Fix quality:** Complete fix for the reported issue
### 6. STABILITY INDICATORS
- Reviewed by Terry Junge (HID reviewer)
- Signed off by Jiri Kosina (HID subsystem maintainer)
- The `HID_QUIRK_ALWAYS_POLL` mechanism is mature and stable
### 7. DEPENDENCY CHECK
- No dependencies on other commits
- The quirk infrastructure exists in all stable trees
- The change is self-contained
### Summary
This is a textbook example of a stable-worthy commit:
1. **Fixes a real bug:** Device rebooting when using physical controls
2. **Small and surgical:** Only 3 lines, no logic changes
3. **Uses existing infrastructure:** `HID_QUIRK_ALWAYS_POLL` is well-
established
4. **Device-specific:** Only affects this one USB speaker model
5. **Zero regression risk:** Cannot affect other devices
6. **Falls into explicit exception:** Device ID + quirk additions are
explicitly allowed in stable
This matches the pattern of hundreds of similar HID quirk entries that
have been backported to stable kernels. The fix is trivial, low-risk,
and solves a real user-facing problem.
**YES**
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3a22129fb7075..bec913a005a5d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -439,6 +439,9 @@
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002 0xc002
+#define USB_VENDOR_ID_EDIFIER 0x2d99
+#define USB_DEVICE_ID_EDIFIER_QR30 0xa101 /* EDIFIER Hal0 2.0 SE */
+
#define USB_VENDOR_ID_ELAN 0x04f3
#define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401
#define USB_DEVICE_ID_HP_X2 0x074d
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3cf7971d49743..d6e42125d9189 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -81,6 +81,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER), HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EDIFIER, USB_DEVICE_ID_EDIFIER_QR30), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, HID_ANY_ID), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II), HID_QUIRK_MULTI_INPUT },
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-5.10] HID: intel-ish-hid: Reset enum_devices_done before enumeration
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Zhang Lixu, Srinivas Pandruvada, Benjamin Tissoires, Sasha Levin,
jikos, linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: Zhang Lixu <lixu.zhang@intel.com>
[ Upstream commit 56e230723e3a818373bd62331bccb1c6d2b3881b ]
Some systems have enabled ISH without any sensors. In this case sending
HOSTIF_DM_ENUM_DEVICES results in 0 sensors. This triggers ISH hardware
reset on subsequent enumeration after S3/S4 resume.
The enum_devices_done flag was not reset before sending the
HOSTIF_DM_ENUM_DEVICES command. On subsequent enumeration calls (such as
after S3/S4 resume), this flag retains its previous true value, causing the
wait loop to be skipped and returning prematurely to hid_ishtp_cl_init().
If 0 HID devices are found, hid_ishtp_cl_init() skips getting HID device
descriptors and sets init_done to true. When the delayed enumeration
response arrives with init_done already true, the driver treats it as a bad
packet and triggers an ISH hardware reset.
Set enum_devices_done to false before sending the enumeration command,
consistent with similar functions like ishtp_get_hid_descriptor() and
ishtp_get_report_descriptor() which reset their respective flags.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of Commit: HID: intel-ish-hid: Reset enum_devices_done
before enumeration
### 1. COMMIT MESSAGE ANALYSIS
The commit message clearly describes a **bug in suspend/resume (S3/S4)
handling**:
- Systems with ISH enabled but no sensors return 0 devices from
HOSTIF_DM_ENUM_DEVICES
- The `enum_devices_done` flag wasn't reset before sending enumeration
commands
- On subsequent enumerations (after resume), the stale `true` value
causes the wait loop to be skipped
- This leads to a race where delayed responses are treated as bad
packets
- Result: **ISH hardware reset** during resume
Key indicators:
- "S3/S4 resume" - power management bug affecting real user workflows
- Clear explanation of the timing/race condition
- Acked-by Srinivas Pandruvada (Intel ISH maintainer)
### 2. CODE CHANGE ANALYSIS
The diff shows a **single line addition**:
```c
+ client_data->enum_devices_done = false;
```
Added immediately before the `HOSTIF_DM_ENUM_DEVICES` command is sent.
The logic:
- The function sends an enumeration request and waits for
`enum_devices_done` to become true
- Without resetting it first, a stale `true` value from a previous call
causes immediate exit from the wait loop
- This creates a race: the response arrives after `init_done` is already
set, triggering a hardware reset
The fix follows the **established pattern** in the same driver - the
commit message notes that `ishtp_get_hid_descriptor()` and
`ishtp_get_report_descriptor()` already reset their respective flags
similarly.
### 3. CLASSIFICATION
- **Bug fix**: Yes - fixes incorrect state handling causing hardware
reset
- **Feature addition**: No
- **API change**: No
- **Hardware quirk**: No - this is a driver logic bug, not a hardware
workaround
### 4. SCOPE AND RISK ASSESSMENT
| Metric | Value |
|--------|-------|
| Lines changed | 1 |
| Files touched | 1 |
| Complexity | Very low |
| Risk | Minimal |
The change:
- Sets a boolean flag to false before an operation that expects it to
transition to true
- Follows identical patterns elsewhere in the same file
- Cannot break any existing functionality that works correctly
- Isolated to Intel ISH subsystem
### 5. USER IMPACT
**Affected users:** Laptop users with Intel Sensor Hub hardware (common
in modern Intel laptops)
**Symptom:** ISH hardware reset during S3/S4 resume, which can cause:
- Delays in resume
- Sensor hub functionality issues after resume
- System instability during power transitions
**Severity:** Moderate-High - affects common laptop power management
workflows
### 6. STABILITY INDICATORS
- **Acked-by:** Srinivas Pandruvada (Intel ISH maintainer) - domain
expert approval
- **Signed-off-by:** Benjamin Tissoires (HID maintainer)
- Pattern-following fix consistent with other similar functions in the
driver
### 7. DEPENDENCY CHECK
This commit:
- Is self-contained with no dependencies
- Modifies code that has existed in stable trees for years
- The `enum_devices_done` flag, `client_data` structure, and
`ishtp_enum_enum_devices()` function are all well-established
---
## Summary
**What it fixes:** Race condition during S3/S4 resume where stale
boolean flag causes ISH hardware reset
**Why it matters:** Users with Intel Sensor Hub hardware experience
hardware reset/instability on resume from suspend/hibernate - a common
laptop workflow
**Stable criteria met:**
- ✅ Obviously correct (follows existing pattern in same driver)
- ✅ Fixes real bug (hardware reset during resume)
- ✅ Small and contained (1 line, 1 file)
- ✅ No new features
- ✅ No API changes
- ✅ Has maintainer acknowledgment
**Risk assessment:** Very low - single boolean assignment following
established pattern
**Benefit:** Fixes real user-facing bug affecting laptop power
management
This is an ideal stable candidate: a minimal, surgical fix for a real
bug affecting common hardware in a common usage scenario, with
maintainer review and following established driver patterns.
**YES**
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
index d8c3c54a8c0f2..537145ec50586 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -495,6 +495,7 @@ static int ishtp_enum_enum_devices(struct ishtp_cl *hid_ishtp_cl)
int rv;
/* Send HOSTIF_DM_ENUM_DEVICES */
+ client_data->enum_devices_done = false;
memset(&msg, 0, sizeof(struct hostif_msg));
msg.hdr.command = HOSTIF_DM_ENUM_DEVICES;
rv = ishtp_cl_send(hid_ishtp_cl, (unsigned char *)&msg,
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-5.15] HID: playstation: Center initial joystick axes to prevent spurious events
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Siarhei Vishniakou, Benjamin Tissoires, Sasha Levin,
roderick.colenbrander, jikos, linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: Siarhei Vishniakou <svv@google.com>
[ Upstream commit e9143268d259d98e111a649affa061acb8e13c5b ]
When a new PlayStation gamepad (DualShock 4 or DualSense) is initialized,
the input subsystem sets the default value for its absolute axes (e.g.,
ABS_X, ABS_Y) to 0.
However, the hardware's actual neutral/resting state for these joysticks
is 128 (0x80). This creates a mismatch.
When the first HID report arrives from the device, the driver sees the
resting value of 128. The kernel compares this to its initial state of 0
and incorrectly interprets this as a delta (0 -> 128). Consequently, it
generates EV_ABS events for this initial, non-existent movement.
This behavior can fail userspace 'sanity check' tests (e.g., in
Android CTS) that correctly assert no motion events should be generated
from a device that is already at rest.
This patch fixes the issue by explicitly setting the initial value of the
main joystick axes (e.g., ABS_X, ABS_Y, ABS_RX, ABS_RY) to 128 (0x80)
in the common ps_gamepad_create() function.
This aligns the kernel's initial state with the hardware's expected
neutral state, ensuring that the first report (at 128) produces no
delta and thus, no spurious event.
Signed-off-by: Siarhei Vishniakou <svv@google.com>
Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of Commit: "HID: playstation: Center initial joystick axes
to prevent spurious events"
### 1. COMMIT MESSAGE ANALYSIS
The commit describes a clear, specific bug:
- PlayStation gamepads (DualShock 4, DualSense) have joysticks that rest
at value 128 (0x80)
- The kernel initializes the axis value to 0 by default
- When the first HID report arrives with the resting value of 128, the
kernel interprets this as actual movement
- This generates spurious EV_ABS events for non-existent movement
- The problem causes Android CTS test failures and potentially confuses
userspace applications
The bug has user-visible impact ("Reported-by" pattern implied through
CTS test context).
### 2. CODE CHANGE ANALYSIS
**The fix is minimal and surgical:**
```c
gamepad->absinfo[ABS_X].value = 128;
gamepad->absinfo[ABS_Y].value = 128;
gamepad->absinfo[ABS_RX].value = 128;
gamepad->absinfo[ABS_RY].value = 128;
```
- 5 lines added (1 comment + 4 value assignments)
- Single file: `drivers/hid/hid-playstation.c`
- Single function: `ps_gamepad_create()`
- Only affects joystick axes (ABS_X, ABS_Y, ABS_RX, ABS_RY), correctly
leaves triggers (ABS_Z, ABS_RZ) at 0
**Technical correctness:** The fix is obviously correct. After
`input_set_abs_params()` sets up the axis with range 0-255, manually
setting `.value = 128` aligns the kernel's initial state with the
hardware's physical resting position at center (128).
### 3. CLASSIFICATION
- **Type:** Bug fix (not a feature)
- **Category:** Input device initialization fix
- **No new API or behavior change:** Just corrects initial state values
- **No new features:** Purely corrects existing incorrect behavior
### 4. SCOPE AND RISK ASSESSMENT
| Factor | Assessment |
|--------|------------|
| Lines changed | 5 (very small) |
| Files changed | 1 |
| Complexity | Trivial |
| Subsystem | HID - PlayStation driver (mature) |
| Risk of regression | Very low |
The change is confined to initialization code and cannot affect any
existing logic paths. Setting an initial value cannot break anything
because:
1. The value 128 is within the valid range (0-255)
2. The hardware reports 128 at rest anyway
3. This aligns kernel state with reality
### 5. USER IMPACT
**Who is affected:**
- All users of DualShock 4 and DualSense controllers
- Android users (CTS compliance)
- Applications that validate initial input state
**Severity:** Medium - Not a crash or data corruption, but:
- Causes spurious input events at device connect
- Breaks CTS conformance tests
- May confuse input-sensitive applications
### 6. STABILITY INDICATORS
- **Reviewed-by:** Benjamin Tissoires (HID maintainer) ✓
- **Signed-off-by:** Maintainer sign-off ✓
- The fix is simple enough to verify correctness by inspection
### 7. DEPENDENCY CHECK
- No dependencies on other commits
- `ps_gamepad_create()` has existed since the driver was introduced
- Uses standard input subsystem patterns (`absinfo[].value`)
- Should apply cleanly to any stable tree containing this driver
### STABLE KERNEL CRITERIA EVALUATION
| Criterion | Status |
|-----------|--------|
| Obviously correct and tested | ✓ Reviewed by maintainer |
| Fixes a real bug | ✓ Spurious input events |
| Important issue | ✓ Breaks CTS, affects popular hardware |
| Small and contained | ✓ 5 lines, 1 file |
| No new features | ✓ Pure correctness fix |
| No new APIs | ✓ |
### RISK VS BENEFIT
**Benefits:**
- Fixes spurious input events on popular consumer hardware
- Fixes Android CTS test failures
- Aligns kernel state with hardware reality
- Affects millions of PlayStation controller users
**Risks:**
- Essentially zero - the change is trivially correct
- No logic changes, just initialization values
### CONCLUSION
This commit is an excellent candidate for stable backporting:
1. **Fixes a real bug** that causes spurious input events and test
failures
2. **Small and surgical** - only 5 lines in one function
3. **Obviously correct** - aligns initial value with hardware's physical
state
4. **Low risk** - cannot introduce regressions
5. **Well-reviewed** - HID maintainer reviewed and signed off
6. **Widely applicable** - affects popular consumer hardware
(PlayStation controllers)
7. **No dependencies** - self-contained fix
The fix meets all stable kernel criteria: it's obviously correct, fixes
a real bug, is small in scope, and introduces no new features. The fact
that it fixes CTS compliance issues makes it particularly valuable for
Android device manufacturers using stable kernels.
**YES**
drivers/hid/hid-playstation.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 128aa6abd10be..e4dfcf26b04e7 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -753,11 +753,16 @@ ps_gamepad_create(struct hid_device *hdev,
if (IS_ERR(gamepad))
return ERR_CAST(gamepad);
+ /* Set initial resting state for joysticks to 128 (center) */
input_set_abs_params(gamepad, ABS_X, 0, 255, 0, 0);
+ gamepad->absinfo[ABS_X].value = 128;
input_set_abs_params(gamepad, ABS_Y, 0, 255, 0, 0);
+ gamepad->absinfo[ABS_Y].value = 128;
input_set_abs_params(gamepad, ABS_Z, 0, 255, 0, 0);
input_set_abs_params(gamepad, ABS_RX, 0, 255, 0, 0);
+ gamepad->absinfo[ABS_RX].value = 128;
input_set_abs_params(gamepad, ABS_RY, 0, 255, 0, 0);
+ gamepad->absinfo[ABS_RY].value = 128;
input_set_abs_params(gamepad, ABS_RZ, 0, 255, 0, 0);
input_set_abs_params(gamepad, ABS_HAT0X, -1, 1, 0, 0);
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-5.10] HID: multitouch: add MT_QUIRK_STICKY_FINGERS to MT_CLS_VTL
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: DaytonCL, Benjamin Tissoires, Benjamin Tissoires, Sasha Levin,
jikos, linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: DaytonCL <artem749507@gmail.com>
[ Upstream commit ff3f234ff1dcd6d626a989151db067a1b7f0f215 ]
Some VTL-class touchpads (e.g. TOPS0102:00 35CC:0104) intermittently
fail to release a finger contact. A previous slot remains logically
active, accompanied by stale BTN_TOOL_DOUBLETAP state, causing
gestures to stay latched and resulting in stuck two-finger
scrolling and false right-clicks.
Apply MT_QUIRK_STICKY_FINGERS to handle the unreleased contact correctly.
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1225
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: DaytonCL <artem749507@gmail.com>
Signed-off-by: DaytonCL <artem749507@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of HID Multitouch Quirk Addition
### 1. COMMIT MESSAGE ANALYSIS
The commit clearly describes a **real user-visible bug**:
- VTL-class touchpads (specifically TOPS0102:00 35CC:0104)
intermittently fail to release finger contacts
- This causes gestures to stay latched - stuck two-finger scrolling and
false right-clicks
- Links to a libinput bug report:
https://gitlab.freedesktop.org/libinput/libinput/-/issues/1225
- Has `Tested-by:` from the reporter and `Suggested-by:` from Benjamin
Tissoires (HID maintainer)
- Signed off by the maintainer (Benjamin Tissoires)
### 2. CODE CHANGE ANALYSIS
The change is **extremely minimal** - adding one line:
```c
MT_QUIRK_STICKY_FINGERS |
```
to the existing `MT_CLS_VTL` class definition. This enables an already-
existing quirk flag (`MT_QUIRK_STICKY_FINGERS`) for VTL-class devices.
The quirk mechanism handles cases where a touchpad firmware fails to
properly report when a finger has been lifted. Without it, the system
thinks the finger is still touching, causing "sticky" gestures. The
quirk infrastructure already exists and is well-tested - this commit
just enables it for another device class.
### 3. CLASSIFICATION
This falls squarely into the **QUIRKS and WORKAROUNDS exception
category**:
- Hardware-specific quirk for buggy/non-compliant devices
- The quirk code already exists in mainline - only enabling it for VTL
class
- Fixes real-world hardware behavior issues
This is NOT:
- A new feature or API
- A new driver
- Code refactoring
### 4. SCOPE AND RISK ASSESSMENT
| Factor | Assessment |
|--------|------------|
| Lines changed | 1 |
| Files touched | 1 |
| Complexity | Trivially low |
| Subsystem | HID multitouch (mature, stable) |
| Risk | Very low |
The worst case scenario: if the quirk somehow caused issues on a
specific VTL device, it would only affect that device class. But the
current behavior is already broken for affected users, so this is a
clear improvement.
### 5. USER IMPACT
- **Affected users**: Anyone with VTL-class touchpads
- **Symptoms**: Stuck two-finger scrolling, false right-clicks - these
are highly disruptive daily-use issues
- **Severity**: Medium-high for affected users (makes touchpad
unreliable)
- **Evidence of real impact**: Linked bug report from libinput tracker
### 6. STABILITY INDICATORS
- `Tested-by:` tag from the reporter who experienced the issue
- Suggested and signed off by HID subsystem maintainer
- The `MT_QUIRK_STICKY_FINGERS` quirk has existed since ~Linux 3.15
- The `MT_CLS_VTL` class has existed since ~Linux 4.13
- Well-established quirk pattern used by many other device classes
(FLATFROG, LG, ASUS, etc.)
### 7. DEPENDENCY CHECK
- **No dependencies** on other commits
- Both the quirk flag and VTL class exist in all recent stable trees
- Should apply cleanly without modification
### STABLE KERNEL RULES ASSESSMENT
| Criterion | Met? |
|-----------|------|
| Obviously correct and tested | ✅ Yes - trivial change, has Tested-by |
| Fixes a real bug | ✅ Yes - documented hardware issue with bug report |
| Important issue | ✅ Yes - stuck gestures/false clicks affect daily use
|
| Small and contained | ✅ Yes - 1 line in 1 file |
| No new features | ✅ Yes - uses existing quirk mechanism |
| Applies cleanly | ✅ Yes - no dependencies |
### CONCLUSION
This is an **ideal stable backport candidate**:
1. **Minimal risk**: Single-line addition of an existing, well-tested
quirk flag
2. **Real user benefit**: Fixes stuck gestures and false clicks on VTL
touchpads
3. **Proper testing**: Has Tested-by tag and maintainer approval
4. **Falls under hardware quirk exception**: Hardware quirks/workarounds
are explicitly allowed in stable even though they add code
5. **Self-contained**: No dependencies, applies cleanly to stable trees
The fix is small, surgical, obviously correct, and addresses a real
user-visible hardware issue. This is exactly the type of hardware quirk
addition that stable trees should accept.
**YES**
drivers/hid/hid-multitouch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 179dc316b4b51..a0c1ad5acb670 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -393,6 +393,7 @@ static const struct mt_class mt_classes[] = {
{ .name = MT_CLS_VTL,
.quirks = MT_QUIRK_ALWAYS_VALID |
MT_QUIRK_CONTACT_CNT_ACCURATE |
+ MT_QUIRK_STICKY_FINGERS |
MT_QUIRK_FORCE_GET_FEATURE,
},
{ .name = MT_CLS_GOOGLE,
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18-5.10] HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Chris Chiu, Benjamin Tissoires, Sasha Levin, jikos, linux-input
In-Reply-To: <20260112145840.724774-1-sashal@kernel.org>
From: Chris Chiu <chris.chiu@canonical.com>
[ Upstream commit c06bc3557542307b9658fbd43cc946a14250347b ]
Another Chicony Electronics HP 5MP Camera with USB ID 04F2:B882
reports a HID sensor interface that is not actually implemented.
Add the device to the HID ignore list so the bogus sensor is never
exposed to userspace. Then the system won't hang when runtime PM
tries to wake the unresponsive device.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Commit Analysis: HID Quirks for Chicony HP 5MP Camera
### 1. COMMIT MESSAGE ANALYSIS
The commit message is clear and explains:
- A specific Chicony HP 5MP Camera (USB ID 04F2:B882) reports a HID
sensor interface that **is not actually implemented**
- Without this fix, **the system hangs** when runtime PM tries to wake
the unresponsive device
- Solution: Add to `hid_ignore_list` so the bogus sensor is never
exposed to userspace
Key phrase: "the system won't hang" - this is a **system hang fix**.
### 2. CODE CHANGE ANALYSIS
The change is minimal and surgical:
**hid-ids.h:** Adds one new device ID define
```c
#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3 0xb882
```
**hid-quirks.c:** Adds device to the ignore list
```c
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) },
```
This follows an **already-established pattern** - there are already two
similar entries:
- `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA` (0xb824)
- `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2` (0xb82c)
### 3. CLASSIFICATION
This falls into **two explicit exception categories** that are allowed
in stable:
1. **Device ID addition:** Adding a USB ID to an existing driver's quirk
list
2. **Hardware quirk/workaround:** Fixing a broken device that falsely
advertises a non-functional HID sensor interface
### 4. SCOPE AND RISK ASSESSMENT
| Metric | Assessment |
|--------|------------|
| Lines changed | 2 |
| Files touched | 2 |
| Complexity | Trivial - just adding ID to a list |
| Risk level | **Extremely low** |
The change only affects this specific USB device (04F2:B882). No logic
changes, no control flow modifications. The `hid_ignore_list` mechanism
is mature and proven.
### 5. USER IMPACT
- **Severity:** HIGH - Prevents **system hangs** on affected HP laptops
- **Affected users:** Anyone with an HP laptop containing this specific
Chicony 5MP camera
- **Real-world evidence:** The author is from Canonical (Ubuntu),
suggesting this was discovered through real user bug reports
### 6. STABILITY INDICATORS
- Accepted by Benjamin Tissoires (HID maintainer)
- Uses identical mechanism to existing, proven entries
- Canonical developer submission suggests tested on real hardware
### 7. DEPENDENCY CHECK
**No dependencies.** The `hid_ignore_list` infrastructure exists in all
stable kernel versions. This is a completely standalone device ID
addition.
---
## Conclusion
This commit is a **textbook example** of what should be backported to
stable:
✅ **Fixes a real bug:** System hang during runtime PM suspend/resume
✅ **Fixes an important issue:** System hangs are severe user-facing bugs
✅ **Small and contained:** Only 2 lines, no logic changes
✅ **Obviously correct:** Follows exact pattern of existing similar
entries
✅ **Hardware quirk exception:** Explicitly allowed by stable kernel
rules
✅ **No dependencies:** Standalone addition
✅ **Zero risk:** Only affects one specific USB device ID
The bug is severe (system hang), the fix is trivial (add device to
ignore list), and the mechanism is well-proven with existing similar
entries. This is exactly what stable backports are for.
**YES**
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c4589075a5ed6..3a22129fb7075 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -317,6 +317,7 @@
#define USB_DEVICE_ID_CHICONY_ACER_SWITCH12 0x1421
#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA 0xb824
#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2 0xb82c
+#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3 0xb882
#define USB_VENDOR_ID_CHUNGHWAT 0x2247
#define USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH 0x0001
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index c89a015686c07..3cf7971d49743 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -769,6 +769,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: Elecom: Add support for ELECOM M-XT3DRBK (018C)
From: Sasha Levin @ 2026-01-12 14:58 UTC (permalink / raw)
To: patches, stable
Cc: Arnoud Willemsen, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input
From: Arnoud Willemsen <mail@lynthium.com>
[ Upstream commit 12adb969658ec39265eb8c7ea9e1856867fb9ceb ]
Wireless/new version of the Elecom trackball mouse M-XT3DRBK has a
product id that differs from the existing M-XT3DRBK.
The report descriptor format also seems to have changed and matches
other (newer?) models instead (except for six buttons instead of eight).
This patch follows the same format as the patch for the M-XT3URBK (018F)
by Naoki Ueki (Nov 3rd 2025) to enable the sixth mouse button.
dmesg output:
[ 292.074664] usb 1-2: new full-speed USB device number 7 using xhci_hcd
[ 292.218667] usb 1-2: New USB device found, idVendor=056e, idProduct=018c, bcdDevice= 1.00
[ 292.218676] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 292.218679] usb 1-2: Product: ELECOM TrackBall Mouse
[ 292.218681] usb 1-2: Manufacturer: ELECOM
usbhid-dump output:
001:006:000:DESCRIPTOR 1765072638.050578
05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
75 08 95 07 B1 02 C0
Signed-off-by: Arnoud Willemsen <mail@lynthium.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of HID: Elecom: Add support for ELECOM M-XT3DRBK (018C)
### 1. COMMIT MESSAGE ANALYSIS
The commit adds support for a new USB product ID (0x018c) for a wireless
variant of the ELECOM M-XT3DRBK trackball mouse. The message indicates:
- It's a wireless/new version of an existing supported device
- The report descriptor format differs from the older variant
- The patch enables the sixth mouse button
- dmesg output confirms the device identification
### 2. CODE CHANGE ANALYSIS
**hid-ids.h:**
- Renames `USB_DEVICE_ID_ELECOM_M_XT3DRBK` →
`USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC` (clarifying the existing ID)
- Adds new `USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C` = 0x018c
**hid-elecom.c:**
- Updates references to use the renamed constant `_00FC`
- Adds a new case in the switch statement for `_018C` calling
`mouse_button_fixup()` with parameters specific to this device's HID
report descriptor: `(22, 30, 24, 16, 6)`
- Adds the new device ID to `elecom_devices[]` table
**hid-quirks.c:**
- Updates reference to use renamed constant
- Adds new device ID to `hid_have_special_driver[]`
### 3. CLASSIFICATION
This is a **NEW DEVICE ID** addition to an existing driver - one of the
explicitly allowed categories for stable backports:
- The driver (hid-elecom) already exists in stable trees
- Only adding a USB product ID to enable new hardware
- Uses existing `mouse_button_fixup()` infrastructure
### 4. SCOPE AND RISK ASSESSMENT
- **Size:** ~15 lines added across 3 files
- **Complexity:** Very low - follows identical patterns to existing
devices
- **Risk:** Minimal - change is isolated to this specific USB device ID
- **Subsystem:** HID drivers are mature and this pattern is well-
established
### 5. USER IMPACT
- **Affected users:** Owners of wireless ELECOM M-XT3DRBK (018C)
trackball mouse
- **Without fix:** The sixth mouse button doesn't work
- **With fix:** Full hardware functionality enabled
- **Severity:** Functional hardware issue - extra button is non-
functional without this fix
### 6. STABILITY INDICATORS
- Signed off by Jiri Kosina (HID subsystem maintainer)
- Follows exact same pattern as other Elecom devices
- Includes device testing evidence (dmesg/usbhid-dump output)
### 7. DEPENDENCY CHECK
- No dependencies on other patches
- All required infrastructure (`mouse_button_fixup()`,
`elecom_report_fixup()`) exists in stable trees
- Self-contained change
### VERDICT
This commit is a textbook example of what **IS** appropriate for stable
backporting. It adds a new USB device ID to an existing driver to enable
hardware support - explicitly allowed under stable rules. The change is:
- Small and surgical
- Low risk (isolated to specific hardware)
- Uses existing patterns and infrastructure
- Enables real hardware to work correctly
- Has no behavioral changes to existing code paths
The only modification beyond adding the new ID is renaming the existing
`USB_DEVICE_ID_ELECOM_M_XT3DRBK` to
`USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC` for clarity, which is a harmless
naming change that doesn't affect functionality.
**YES**
drivers/hid/hid-elecom.c | 15 +++++++++++++--
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/hid-quirks.c | 3 ++-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-elecom.c b/drivers/hid/hid-elecom.c
index 981d1b6e96589..2003d2dcda7cc 100644
--- a/drivers/hid/hid-elecom.c
+++ b/drivers/hid/hid-elecom.c
@@ -77,7 +77,7 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
break;
case USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB:
case USB_DEVICE_ID_ELECOM_M_XT3URBK_018F:
- case USB_DEVICE_ID_ELECOM_M_XT3DRBK:
+ case USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC:
case USB_DEVICE_ID_ELECOM_M_XT4DRBK:
/*
* Report descriptor format:
@@ -102,6 +102,16 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
*/
mouse_button_fixup(hdev, rdesc, *rsize, 12, 30, 14, 20, 8);
break;
+ case USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C:
+ /*
+ * Report descriptor format:
+ * 22: button bit count
+ * 30: padding bit count
+ * 24: button report size
+ * 16: button usage maximum
+ */
+ mouse_button_fixup(hdev, rdesc, *rsize, 22, 30, 24, 16, 6);
+ break;
case USB_DEVICE_ID_ELECOM_M_DT2DRBK:
case USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C:
/*
@@ -122,7 +132,8 @@ static const struct hid_device_id elecom_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20DLBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
- { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index bec913a005a5d..b75d9d2f4dc73 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -455,7 +455,8 @@
#define USB_DEVICE_ID_ELECOM_M_XGL20DLBK 0x00e6
#define USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB 0x00fb
#define USB_DEVICE_ID_ELECOM_M_XT3URBK_018F 0x018f
-#define USB_DEVICE_ID_ELECOM_M_XT3DRBK 0x00fc
+#define USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC 0x00fc
+#define USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C 0x018c
#define USB_DEVICE_ID_ELECOM_M_XT4DRBK 0x00fd
#define USB_DEVICE_ID_ELECOM_M_DT1URBK 0x00fe
#define USB_DEVICE_ID_ELECOM_M_DT1DRBK 0x00ff
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index d6e42125d9189..e823661389016 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -413,7 +413,8 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20DLBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
- { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
--
2.51.0
^ permalink raw reply related
* Subscribe Linux-input
From: Paul MORRIS @ 2026-01-12 13:49 UTC (permalink / raw)
To: linux-input, majordomo
In-Reply-To: <5EB0F81A-202E-4FBC-9018-326E896D286C.ref@aol.com>
Subscribe Linux-input
Regards
^ permalink raw reply
* Re: [PATCH v2 4/4] HID: steelseries: Add support for Arctis headset lineup
From: Bastien Nocera @ 2026-01-12 13:09 UTC (permalink / raw)
To: Sriman Achanta, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260112041941.40531-5-srimanachanta@gmail.com>
On Sun, 2026-01-11 at 23:19 -0500, Sriman Achanta wrote:
> Add full support for the SteelSeries Arctis wireless gaming headset
> lineup, extending the driver from basic support for 2 models (Arctis
> 1
> and 9) to comprehensive support for 25+ models across all Arctis
> generations.
>
> This is a major restructure of the hid-steelseries driver that
> replaces
> the previous minimal implementation with a unified, capability-based
> architecture.
This patch needs to be split up, at the very least it needs new
features to be split up from any other refactoring that might be needed
to support features with each new feature getting its own commit.
As mentioned in the earlier patch, sidetone control, chatmix level, mic
level, volume limiter and bluetooth call volume all should be
implemented as ALSA mixers/switches so they can be toggled with stock
tools and presented in a uniform way up the stack (Pipewire/Pulseaudio
and desktop environments).
An additional comments inline.
> <snip>
> -/* Fixed report descriptor for Steelseries SRW-S1 wheel controller
> - *
> - * The original descriptor hides the sensitivity and assists dials
> - * a custom vendor usage page. This inserts a patch to make them
> - * appear in the 'Generic Desktop' usage.
> - */
> -
> +/* Fixed report descriptor for Steelseries SRW-S1 wheel controller
> */
There's really no need to reindent this array.
> static const __u8 steelseries_srws1_rdesc_fixed[] = {
> -0x05, 0x01, /* Usage Page (Desktop) */
> -0x09, 0x08, /* Usage (MultiAxis), Changed */
> -0xA1, 0x01, /* Collection (Application), */
> -0xA1, 0x02, /* Collection (Logical), */
> -0x95, 0x01, /* Report Count (1), */
> -0x05, 0x01, /* Changed Usage Page (Desktop), */
> -0x09, 0x30, /* Changed Usage (X), */
> -0x16, 0xF8, 0xF8, /* Logical Minimum (-1800), */
> -0x26, 0x08, 0x07, /* Logical Maximum (1800), */
> -0x65, 0x14, /* Unit (Degrees), */
> -0x55, 0x0F, /* Unit Exponent (15), */
> -0x75, 0x10, /* Report Size (16), */
> -0x81, 0x02, /* Input (Variable), */
> -0x09, 0x31, /* Changed Usage (Y), */
> -0x15, 0x00, /* Logical Minimum (0), */
> -0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
> -0x75, 0x0C, /* Report Size (12), */
> -0x81, 0x02, /* Input (Variable), */
> -0x09, 0x32, /* Changed Usage (Z), */
> -0x15, 0x00, /* Logical Minimum (0), */
> -0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
> -0x75, 0x0C, /* Report Size (12), */
> -0x81, 0x02, /* Input (Variable), */
> -0x05, 0x01, /* Usage Page (Desktop), */
> -0x09, 0x39, /* Usage (Hat Switch), */
> -0x25, 0x07, /* Logical Maximum (7), */
> -0x35, 0x00, /* Physical Minimum (0), */
> -0x46, 0x3B, 0x01, /* Physical Maximum (315), */
> -0x65, 0x14, /* Unit (Degrees), */
> -0x75, 0x04, /* Report Size (4), */
> -0x95, 0x01, /* Report Count (1), */
> -0x81, 0x02, /* Input (Variable), */
> -0x25, 0x01, /* Logical Maximum (1), */
> -0x45, 0x01, /* Physical Maximum (1), */
> -0x65, 0x00, /* Unit, */
> -0x75, 0x01, /* Report Size (1), */
> -0x95, 0x03, /* Report Count (3), */
> -0x81, 0x01, /* Input (Constant), */
> -0x05, 0x09, /* Usage Page (Button), */
> -0x19, 0x01, /* Usage Minimum (01h), */
> -0x29, 0x11, /* Usage Maximum (11h), */
> -0x95, 0x11, /* Report Count (17), */
> -0x81, 0x02, /* Input (Variable), */
> - /* ---- Dial patch starts here ---- */
> -0x05, 0x01, /* Usage Page (Desktop), */
> -0x09, 0x33, /* Usage (RX), */
> -0x75, 0x04, /* Report Size (4), */
> -0x95, 0x02, /* Report Count (2), */
> -0x15, 0x00, /* Logical Minimum (0), */
> -0x25, 0x0b, /* Logical Maximum (b), */
> -0x81, 0x02, /* Input (Variable), */
> -0x09, 0x35, /* Usage (RZ), */
> -0x75, 0x04, /* Report Size (4), */
> -0x95, 0x01, /* Report Count (1), */
> -0x25, 0x03, /* Logical Maximum (3), */
> -0x81, 0x02, /* Input (Variable), */
> - /* ---- Dial patch ends here ---- */
> -0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
> -0x09, 0x01, /* Usage (01h), */
> -0x75, 0x04, /* Changed Report Size (4), */
> -0x95, 0x0D, /* Changed Report Count (13), */
> -0x81, 0x02, /* Input (Variable), */
> -0xC0, /* End Collection, */
> -0xA1, 0x02, /* Collection (Logical), */
> -0x09, 0x02, /* Usage (02h), */
> -0x75, 0x08, /* Report Size (8), */
> -0x95, 0x10, /* Report Count (16), */
> -0x91, 0x02, /* Output (Variable), */
> -0xC0, /* End Collection, */
> -0xC0 /* End Collection */
> + 0x05, 0x01, /* Usage Page (Desktop) */
> + 0x09, 0x08, /* Usage (MultiAxis), Changed */
> + 0xA1, 0x01, /* Collection (Application), */
> + 0xA1, 0x02, /* Collection (Logical), */
> + 0x95, 0x01, /* Report Count (1), */
> + 0x05, 0x01, /* Changed Usage Page (Desktop), */
> + 0x09, 0x30, /* Changed Usage (X), */
> + 0x16, 0xF8, 0xF8, /* Logical Minimum (-1800), */
> + 0x26, 0x08, 0x07, /* Logical Maximum (1800), */
> + 0x65, 0x14, /* Unit (Degrees), */
> + 0x55, 0x0F, /* Unit Exponent (15), */
> + 0x75, 0x10, /* Report Size (16), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0x09, 0x31, /* Changed Usage (Y), */
> + 0x15, 0x00, /* Logical Minimum (0), */
> + 0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
> + 0x75, 0x0C, /* Report Size (12), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0x09, 0x32, /* Changed Usage (Z), */
> + 0x15, 0x00, /* Logical Minimum (0), */
> + 0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
> + 0x75, 0x0C, /* Report Size (12), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0x05, 0x01, /* Usage Page (Desktop), */
> + 0x09, 0x39, /* Usage (Hat Switch), */
> + 0x25, 0x07, /* Logical Maximum (7), */
> + 0x35, 0x00, /* Physical Minimum (0), */
> + 0x46, 0x3B, 0x01, /* Physical Maximum (315), */
> + 0x65, 0x14, /* Unit (Degrees), */
> + 0x75, 0x04, /* Report Size (4), */
> + 0x95, 0x01, /* Report Count (1), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0x25, 0x01, /* Logical Maximum (1), */
> + 0x45, 0x01, /* Physical Maximum (1), */
> + 0x65, 0x00, /* Unit, */
> + 0x75, 0x01, /* Report Size (1), */
> + 0x95, 0x03, /* Report Count (3), */
> + 0x81, 0x01, /* Input (Constant), */
> + 0x05, 0x09, /* Usage Page (Button), */
> + 0x19, 0x01, /* Usage Minimum (01h), */
> + 0x29, 0x11, /* Usage Maximum (11h), */
> + 0x95, 0x11, /* Report Count (17), */
> + 0x81, 0x02, /* Input (Variable), */
> + /* ---- Dial patch starts here ---- */
> + 0x05, 0x01, /* Usage Page (Desktop), */
> + 0x09, 0x33, /* Usage (RX), */
> + 0x75, 0x04, /* Report Size (4), */
> + 0x95, 0x02, /* Report Count (2), */
> + 0x15, 0x00, /* Logical Minimum (0), */
> + 0x25, 0x0b, /* Logical Maximum (b), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0x09, 0x35, /* Usage (RZ), */
> + 0x75, 0x04, /* Report Size (4), */
> + 0x95, 0x01, /* Report Count (1), */
> + 0x25, 0x03, /* Logical Maximum (3), */
> + 0x81, 0x02, /* Input (Variable), */
> + /* ---- Dial patch ends here ---- */
> + 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
> + 0x09, 0x01, /* Usage (01h), */
> + 0x75, 0x04, /* Changed Report Size (4), */
> + 0x95, 0x0D, /* Changed Report Count (13), */
> + 0x81, 0x02, /* Input (Variable), */
> + 0xC0, /* End Collection, */
> + 0xA1, 0x02, /* Collection (Logical), */
> + 0x09, 0x02, /* Usage (02h), */
> + 0x75, 0x08, /* Report Size (8), */
> + 0x95, 0x10, /* Report Count (16), */
> + 0x91, 0x02, /* Output (Variable), */
> + 0xC0, /* End Collection, */
> + 0xC0 /* End Collection */
> };
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: hid-ids: Add SteelSeries Arctis headset device IDs
From: Bastien Nocera @ 2026-01-12 13:08 UTC (permalink / raw)
To: Sriman Achanta, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260112041941.40531-2-srimanachanta@gmail.com>
On Sun, 2026-01-11 at 23:19 -0500, Sriman Achanta wrote:
> Add USB device IDs for the complete SteelSeries Arctis headset
> lineup,
> including:
> - Arctis 1, 1 Wireless, 7, 7P, 7X variants
> - Arctis 7+ series (PS5, Xbox, Destiny editions)
> - Arctis 9 Wireless
> - Arctis Pro Wireless
> - Arctis Nova 3, 3P, 3X
> - Arctis Nova 5, 5X
> - Arctis Nova 7 series (multiple variants and special editions)
> - Arctis Nova Pro Wireless and Pro X
>
> This also fixes the existing ARCTIS_1 ID to use the correct product
> ID
> (0x12b3 instead of 0x12b6, which is actually the Arctis 1 Xbox
> variant).
"This also fixes" usually is a good way to tell you that this should
have been a separate patch.
It would be useful if you could change the indentation in a first
patch, "fix" the USB ID in a second patch, and add new IDs in a third
patch. Note that in your second patch, you'll need to change the source
code to use that new identifier otherwise you'll be breaking my headset
:)
Please make sure to CC: me on future patchsets you send.
>
> These IDs will be used by the updated hid-steelseries driver to
> provide
> battery monitoring, sidetone control, and other device-specific
> features
> for these wireless gaming headsets.
>
> Signed-off-by: Sriman Achanta <srimanachanta@gmail.com>
> ---
> drivers/hid/hid-ids.h | 33 +++++++++++++++++++++++++++++----
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index d31711f1aaec..f4f91fb4c2b9 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -1303,10 +1303,35 @@
> #define USB_DEVICE_ID_STEAM_CONTROLLER_WIRELESS 0x1142
> #define USB_DEVICE_ID_STEAM_DECK 0x1205
>
> -#define USB_VENDOR_ID_STEELSERIES 0x1038
> -#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_VENDOR_ID_STEELSERIES 0x1038
> +#define
> USB_DEVICE_ID_STEELSERIES_SRWS1 0x1410
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_1 0x12b3
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_1_X 0x12b6
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_7 0x1260
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_7_P 0x12d5
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_7_X 0x12d7
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_7_GEN2 0x12ad
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_7_PLUS 0x220e
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_7_PLUS_P 0x2212
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_7_PLUS_X 0x2216
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_7_PLUS_DESTINY 0x2236
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_9 0x12c2
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_PRO 0x1290
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_3 0x12ec
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_3_P 0x2269
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_3_X 0x226d
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_5 0x2232
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_5_X 0x2253
> +#define
> USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7 0x2202
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_X 0x2206
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_P 0x220a
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_X_REV2 0x2258
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_DIABLO 0x223a
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_WOW 0x227a
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_GEN2 0x227e
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_7_X_GEN2 0x229e
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_PRO 0x12e0
> +#define USB_DEVICE_ID_STEELSERIES_ARCTIS_NOVA_PRO_X 0x12e5
>
> #define USB_VENDOR_ID_SUN 0x0430
> #define USB_DEVICE_ID_RARITAN_KVM_DONGLE 0xcdab
^ permalink raw reply
* Re: [PATCH v2 3/4] Documentation: ABI: Document SteelSeries headset sysfs attributes
From: Bastien Nocera @ 2026-01-12 13:08 UTC (permalink / raw)
To: Sriman Achanta, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260112041941.40531-4-srimanachanta@gmail.com>
On Sun, 2026-01-11 at 23:19 -0500, Sriman Achanta wrote:
> Replace the SRW-S1 specific documentation with comprehensive
> documentation for the hid-steelseries driver covering both the legacy
> SRW-S1 wheel and the modern Arctis headset lineup.
Renaming the sysfs-driver-hid-srws1 should be done separately from
adding new contents.
This patch should also come after the feature gets added.
>
> New sysfs attributes documented:
> - sidetone_level: Control microphone monitoring volume
This should be an ALSA mixer, not a sysfs file.
> - inactive_time: Auto-sleep timeout configuration
> - chatmix_level: Game/Chat audio balance (read-only)
Ditto for an ALSA mixer.
> - mic_mute_led_brightness: Microphone mute LED brightness control
This probably needs to be a standard LED device.
> - mic_volume: Internal microphone gain control
Ditto for an ALSA mixer.
> - volume_limiter: EU hearing protection volume limiter
Ditto for an ALSA switch.
> - bluetooth_on_power: Bluetooth auto-enable on power-on
> - bluetooth_call_vol: Bluetooth call audio attenuation settings
Ditto for an ALSA mixer.
>
> The SRW-S1 LED documentation is preserved and moved into the new
> unified
> documentation file.
>
> Signed-off-by: Sriman Achanta <srimanachanta@gmail.com>
> ---
> .../ABI/testing/sysfs-driver-hid-srws1 | 21 ---
> .../ABI/testing/sysfs-driver-hid-steelseries | 131
> ++++++++++++++++++
> 2 files changed, 131 insertions(+), 21 deletions(-)
> delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-srws1
> create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-
> steelseries
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-hid-srws1
> b/Documentation/ABI/testing/sysfs-driver-hid-srws1
> deleted file mode 100644
> index d0eba70c7d40..000000000000
> --- a/Documentation/ABI/testing/sysfs-driver-hid-srws1
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -What: /sys/class/leds/SRWS1::<serial>::RPM1
> -What: /sys/class/leds/SRWS1::<serial>::RPM2
> -What: /sys/class/leds/SRWS1::<serial>::RPM3
> -What: /sys/class/leds/SRWS1::<serial>::RPM4
> -What: /sys/class/leds/SRWS1::<serial>::RPM5
> -What: /sys/class/leds/SRWS1::<serial>::RPM6
> -What: /sys/class/leds/SRWS1::<serial>::RPM7
> -What: /sys/class/leds/SRWS1::<serial>::RPM8
> -What: /sys/class/leds/SRWS1::<serial>::RPM9
> -What: /sys/class/leds/SRWS1::<serial>::RPM10
> -What: /sys/class/leds/SRWS1::<serial>::RPM11
> -What: /sys/class/leds/SRWS1::<serial>::RPM12
> -What: /sys/class/leds/SRWS1::<serial>::RPM13
> -What: /sys/class/leds/SRWS1::<serial>::RPM14
> -What: /sys/class/leds/SRWS1::<serial>::RPM15
> -What: /sys/class/leds/SRWS1::<serial>::RPMALL
> -Date: Jan 2013
> -KernelVersion: 3.9
> -Contact: Simon Wood <simon@mungewell.org>
> -Description: Provides a control for turning on/off the LEDs which
> form
> - an RPM meter on the front of the controller
> diff --git a/Documentation/ABI/testing/sysfs-driver-hid-steelseries
> b/Documentation/ABI/testing/sysfs-driver-hid-steelseries
> new file mode 100644
> index 000000000000..751cf01ceda3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-hid-steelseries
> @@ -0,0 +1,131 @@
> +What: /sys/class/leds/SRWS1::<serial>::RPM1
> +What: /sys/class/leds/SRWS1::<serial>::RPM2
> +What: /sys/class/leds/SRWS1::<serial>::RPM3
> +What: /sys/class/leds/SRWS1::<serial>::RPM4
> +What: /sys/class/leds/SRWS1::<serial>::RPM5
> +What: /sys/class/leds/SRWS1::<serial>::RPM6
> +What: /sys/class/leds/SRWS1::<serial>::RPM7
> +What: /sys/class/leds/SRWS1::<serial>::RPM8
> +What: /sys/class/leds/SRWS1::<serial>::RPM9
> +What: /sys/class/leds/SRWS1::<serial>::RPM10
> +What: /sys/class/leds/SRWS1::<serial>::RPM11
> +What: /sys/class/leds/SRWS1::<serial>::RPM12
> +What: /sys/class/leds/SRWS1::<serial>::RPM13
> +What: /sys/class/leds/SRWS1::<serial>::RPM14
> +What: /sys/class/leds/SRWS1::<serial>::RPM15
> +What: /sys/class/leds/SRWS1::<serial>::RPMALL
> +Date: Jan 2013
> +KernelVersion: 3.9
> +Contact: Simon Wood <simon@mungewell.org>
> +Description: Provides a control for turning on/off the LEDs which
> form
> + an RPM meter on the front of the controller
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/sidetone_le
> vel
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Controls the sidetone (microphone monitoring) volume
> level.
> + This determines how much of the microphone input is
> fed back into
> + the headset speakers.
> +
> + Range: 0-128 (mapped internally to device-specific
> values).
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/inactive_ti
> me
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Sets the time in minutes before the headset
> automatically enters
> + standby/sleep mode when no audio is playing.
> +
> + Range: 0-90 (minutes).
> + Some devices (e.g., Arctis 1/7X) map this to
> specific presets.
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/chatmix_lev
> el
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Reports the current balance between Game and Chat
> audio channels
> + (ChatMix). This value changes when the physical
> ChatMix dial
> + on the headset is adjusted.
> +
> + Range: 0-128
> + 0 = 100% Chat / 0% Game
> + 64 = 50% Chat / 50% Game (Balanced)
> + 128 = 0% Chat / 100% Game
> +
> + Access: Read
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/mic_mute_le
> d_brightness
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Controls the brightness of the LED on the microphone
> boom that
> + indicates when the microphone is muted.
> +
> + Range: 0-3 (off, low, medium, high) for most
> devices.
> + 0-10 for newer Nova series devices.
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/mic_volume
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Controls the internal microphone gain/volume of the
> headset.
> + This is distinct from the OS input volume.
> +
> + Range: 0-128 (mapped internally to device-specific
> values).
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/volume_limi
> ter
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Enables or disables the EU volume limiter (hearing
> protection).
> + When enabled, the maximum output volume is capped.
> +
> + Values:
> + 0 = Disabled
> + 1 = Enabled
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/bluetooth_o
> n_power
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Configures whether the Bluetooth radio automatically
> turns on
> + when the headset is powered on.
> +
> + Values:
> + 0 = Bluetooth must be turned on manually
> + 1 = Bluetooth turns on automatically with headset
> +
> + Access: Write
> +
> +What: /sys/class/hid/drivers/steelseries/<dev>/bluetooth_c
> all_vol
> +Date: January 2025
> +KernelVersion: 6.19
> +Contact: Sriman Achanta <srimanachanta@gmail.com>
> +Description:
> + Configures how the 2.4GHz Game/Chat audio is
> attenuated when
> + a Bluetooth call is active.
> +
> + Values:
> + 0 = No attenuation (mix both equally)
> + 1 = Attenuate Game audio by -12dB
> + 2 = Mute Game audio completely
> +
> + Access: Write
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox