* Re: [PATCH] input: cpcap-pwrbutton: remove initial kernel-doc notation
From: Mattijs Korpershoek @ 2023-01-24 9:47 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Sebastian Reichel, Dmitry Torokhov, linux-input
In-Reply-To: <20230113063831.16469-1-rdunlap@infradead.org>
On Thu, Jan 12, 2023 at 22:38, Randy Dunlap <rdunlap@infradead.org> wrote:
> Change the beginning "/**" in the file to "/*" since it is not a
> kernel-doc comment. This prevents a kernel-doc warning:
>
> drivers/input/misc/cpcap-pwrbutton.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
> * CPCAP Power Button Input Driver
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> ---
> drivers/input/misc/cpcap-pwrbutton.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -- a/drivers/input/misc/cpcap-pwrbutton.c b/drivers/input/misc/cpcap-pwrbutton.c
> --- a/drivers/input/misc/cpcap-pwrbutton.c
> +++ b/drivers/input/misc/cpcap-pwrbutton.c
> @@ -1,4 +1,4 @@
> -/**
> +/*
> * CPCAP Power Button Input Driver
> *
> * Copyright (C) 2017 Sebastian Reichel <sre@kernel.org>
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4: use correct function name in kernel-doc
From: Mattijs Korpershoek @ 2023-01-24 9:38 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel; +Cc: Randy Dunlap, Dmitry Torokhov, linux-input
In-Reply-To: <20230113063841.17191-1-rdunlap@infradead.org>
On Thu, Jan 12, 2023 at 22:38, Randy Dunlap <rdunlap@infradead.org> wrote:
> Use the correct function name in kernel-doc notation to prevent a warning:
>
> drivers/input/rmi4/rmi_bus.c:300: warning: expecting prototype for rmi_register_function_handler(). Prototype was for __rmi_register_function_handler() instead
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> ---
> drivers/input/rmi4/rmi_bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -- a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
> --- a/drivers/input/rmi4/rmi_bus.c
> +++ b/drivers/input/rmi4/rmi_bus.c
> @@ -285,7 +285,7 @@ void rmi_unregister_function(struct rmi_
> }
>
> /**
> - * rmi_register_function_handler - register a handler for an RMI function
> + * __rmi_register_function_handler - register a handler for an RMI function
> * @handler: RMI handler that should be registered.
> * @owner: pointer to module that implements the handler
> * @mod_name: name of the module implementing the handler
^ permalink raw reply
* [syzbot] KASAN: use-after-free Read in hiddev_disconnect (5)
From: syzbot @ 2023-01-24 9:29 UTC (permalink / raw)
To: benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 081edded9b38 Merge tag 'zonefs-6.2-rc5' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1305a9b1480000
kernel config: https://syzkaller.appspot.com/x/.config?x=899d86a7610a0ea0
dashboard link: https://syzkaller.appspot.com/bug?extid=063c07e14d0399971c93
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b3f03c5cb208/disk-081edded.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ea56a8e575ac/vmlinux-081edded.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8a717b26e391/bzImage-081edded.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+063c07e14d0399971c93@syzkaller.appspotmail.com
usb 6-1: USB disconnect, device number 35
==================================================================
BUG: KASAN: use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:85 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x265/0x2b0 kernel/locking/spinlock_debug.c:114
Read of size 4 at addr ffff88804225cc1c by task kworker/0:20/21099
CPU: 0 PID: 21099 Comm: kworker/0:20 Not tainted 6.2.0-rc4-syzkaller-00069-g081edded9b38 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:306 [inline]
print_report+0x15e/0x45d mm/kasan/report.c:417
kasan_report+0xbf/0x1f0 mm/kasan/report.c:517
debug_spin_lock_before kernel/locking/spinlock_debug.c:85 [inline]
do_raw_spin_lock+0x265/0x2b0 kernel/locking/spinlock_debug.c:114
__mutex_unlock_slowpath+0x18e/0x5e0 kernel/locking/mutex.c:932
hiddev_disconnect+0x158/0x1c0 drivers/hid/usbhid/hiddev.c:940
hid_disconnect+0xb8/0x1b0 drivers/hid/hid-core.c:2257
hid_hw_stop drivers/hid/hid-core.c:2302 [inline]
hid_device_remove+0x161/0x200 drivers/hid/hid-core.c:2634
device_remove+0xc8/0x170 drivers/base/dd.c:548
__device_release_driver drivers/base/dd.c:1253 [inline]
device_release_driver_internal+0x4a5/0x700 drivers/base/dd.c:1279
bus_remove_device+0x2e7/0x5a0 drivers/base/bus.c:529
device_del+0x4f7/0xc80 drivers/base/core.c:3666
hid_remove_device drivers/hid/hid-core.c:2803 [inline]
hid_destroy_device+0xe5/0x150 drivers/hid/hid-core.c:2822
usbhid_disconnect+0xa3/0xe0 drivers/hid/usbhid/hid-core.c:1451
usb_unbind_interface+0x1dc/0x8e0 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:550 [inline]
device_remove+0x11f/0x170 drivers/base/dd.c:542
__device_release_driver drivers/base/dd.c:1253 [inline]
device_release_driver_internal+0x4a5/0x700 drivers/base/dd.c:1279
bus_remove_device+0x2e7/0x5a0 drivers/base/bus.c:529
device_del+0x4f7/0xc80 drivers/base/core.c:3666
usb_disable_device+0x35a/0x7b0 drivers/usb/core/message.c:1420
usb_disconnect.cold+0x259/0x6ed drivers/usb/core/hub.c:2235
hub_port_connect drivers/usb/core/hub.c:5244 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5549 [inline]
port_event drivers/usb/core/hub.c:5709 [inline]
hub_event+0x1fb5/0x4810 drivers/usb/core/hub.c:5791
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>
Allocated by task 20984:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
____kasan_kmalloc mm/kasan/common.c:371 [inline]
____kasan_kmalloc mm/kasan/common.c:330 [inline]
__kasan_kmalloc+0xa5/0xb0 mm/kasan/common.c:380
kmalloc include/linux/slab.h:580 [inline]
kzalloc include/linux/slab.h:720 [inline]
hiddev_connect+0x24a/0x5c0 drivers/hid/usbhid/hiddev.c:893
hid_connect+0x271/0x17c0 drivers/hid/hid-core.c:2174
hid_hw_start drivers/hid/hid-core.c:2282 [inline]
hid_hw_start+0xa6/0x130 drivers/hid/hid-core.c:2273
plantronics_probe+0x304/0x3e0 drivers/hid/hid-plantronics.c:191
hid_device_probe+0x29a/0x3c0 drivers/hid/hid-core.c:2603
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
__device_attach+0x1e4/0x530 drivers/base/dd.c:1008
bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
device_add+0xbd9/0x1e90 drivers/base/core.c:3479
hid_add_device+0x377/0xa20 drivers/hid/hid-core.c:2755
usbhid_probe+0xbae/0x1030 drivers/hid/usbhid/hid-core.c:1424
usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
__device_attach+0x1e4/0x530 drivers/base/dd.c:1008
bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
device_add+0xbd9/0x1e90 drivers/base/core.c:3479
usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2171
usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
__device_attach+0x1e4/0x530 drivers/base/dd.c:1008
bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
device_add+0xbd9/0x1e90 drivers/base/core.c:3479
usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573
hub_port_connect drivers/usb/core/hub.c:5405 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5549 [inline]
port_event drivers/usb/core/hub.c:5709 [inline]
hub_event+0x2d5c/0x4810 drivers/usb/core/hub.c:5791
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
Freed by task 21404:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:518
____kasan_slab_free mm/kasan/common.c:236 [inline]
____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
kasan_slab_free include/linux/kasan.h:177 [inline]
slab_free_hook mm/slub.c:1781 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
slab_free mm/slub.c:3787 [inline]
__kmem_cache_free+0xaf/0x3b0 mm/slub.c:3800
hiddev_release+0x406/0x520 drivers/hid/usbhid/hiddev.c:232
__fput+0x27c/0xa90 fs/file_table.c:320
task_work_run+0x16f/0x270 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x23c/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Last potentially related work creation:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
__kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:488
insert_work+0x48/0x350 kernel/workqueue.c:1358
__queue_work+0x693/0x13b0 kernel/workqueue.c:1517
call_timer_fn+0x1da/0x7c0 kernel/time/timer.c:1700
expire_timers+0xbb/0x5c0 kernel/time/timer.c:1746
__run_timers kernel/time/timer.c:2022 [inline]
__run_timers kernel/time/timer.c:1995 [inline]
run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
__do_softirq+0x1fb/0xadc kernel/softirq.c:571
Second to last potentially related work creation:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
__kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:488
insert_work+0x48/0x350 kernel/workqueue.c:1358
__queue_work+0x693/0x13b0 kernel/workqueue.c:1517
call_timer_fn+0x1da/0x7c0 kernel/time/timer.c:1700
expire_timers+0xbb/0x5c0 kernel/time/timer.c:1746
__run_timers kernel/time/timer.c:2022 [inline]
__run_timers kernel/time/timer.c:1995 [inline]
run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
__do_softirq+0x1fb/0xadc kernel/softirq.c:571
The buggy address belongs to the object at ffff88804225cc00
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 28 bytes inside of
512-byte region [ffff88804225cc00, ffff88804225ce00)
The buggy address belongs to the physical page:
page:ffffea0001089700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4225c
head:ffffea0001089700 order:2 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffff888012441c80 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5115, tgid 5115 (syz-executor.3), ts 148294241180, free_ts 13478414814
prep_new_page mm/page_alloc.c:2531 [inline]
get_page_from_freelist+0x119c/0x2ce0 mm/page_alloc.c:4283
__alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5549
alloc_pages+0x1aa/0x270 mm/mempolicy.c:2286
alloc_slab_page mm/slub.c:1851 [inline]
allocate_slab+0x25f/0x350 mm/slub.c:1998
new_slab mm/slub.c:2051 [inline]
___slab_alloc+0xa91/0x1400 mm/slub.c:3193
__slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
__slab_alloc_node mm/slub.c:3345 [inline]
slab_alloc_node mm/slub.c:3442 [inline]
__kmem_cache_alloc_node+0x1a4/0x430 mm/slub.c:3491
kmalloc_trace+0x26/0x60 mm/slab_common.c:1062
kmalloc include/linux/slab.h:580 [inline]
kzalloc include/linux/slab.h:720 [inline]
__devlink_health_reporter_create+0x91/0x2f0 net/core/devlink.c:7763
devlink_health_reporter_create+0xa8/0x1e0 net/core/devlink.c:7835
nsim_dev_health_init+0x99/0x3b0 drivers/net/netdevsim/health.c:243
nsim_drv_probe+0xc78/0x1320 drivers/net/netdevsim/dev.c:1587
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1446 [inline]
free_pcp_prepare+0x65c/0xc00 mm/page_alloc.c:1496
free_unref_page_prepare mm/page_alloc.c:3369 [inline]
free_unref_page+0x1d/0x490 mm/page_alloc.c:3464
free_contig_range+0xb5/0x180 mm/page_alloc.c:9485
destroy_args+0xa8/0x64c mm/debug_vm_pgtable.c:998
debug_vm_pgtable+0x28de/0x296f mm/debug_vm_pgtable.c:1318
do_one_initcall+0x141/0x790 init/main.c:1306
do_initcall_level init/main.c:1379 [inline]
do_initcalls init/main.c:1395 [inline]
do_basic_setup init/main.c:1414 [inline]
kernel_init_freeable+0x6f9/0x782 init/main.c:1634
kernel_init+0x1e/0x1d0 init/main.c:1522
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
Memory state around the buggy address:
ffff88804225cb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88804225cb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88804225cc00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88804225cc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88804225cd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH] Input: xpad - add 8BitDo Pro 2 Wired Controller support
From: Mattijs Korpershoek @ 2023-01-24 9:26 UTC (permalink / raw)
To: John Butler, dmitry.torokhov; +Cc: John Butler, linux-input
In-Reply-To: <20230124005206.80706-1-radon86dev@gmail.com>
On Tue, Jan 24, 2023 at 00:52, John Butler <radon86dev@gmail.com> wrote:
> Add VID and PID to the xpad_device table to allow driver
> to use the 8BitDo Pro 2 Wired Controller, which is
> XTYPE_XBOX360 compatible by default.
>
> Signed-off-by: John Butler <radon86dev@gmail.com>
> Cc: linux-input@vger.kernel.org
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> ---
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 2959d80f7fdb..f642ec8e92dd 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -359,6 +359,7 @@ static const struct xpad_device {
> { 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
> { 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
> { 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
> + { 0x2dc8, 0x3106, "8BitDo Pro 2 Wired Controller", 0, XTYPE_XBOX360 },
> { 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
> { 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
> { 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
> @@ -492,6 +493,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
> XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */
> XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
> + XPAD_XBOX360_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller */
> XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
> XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
> XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
> --
> 2.39.1
^ permalink raw reply
* Re: [PATCH 1/3] Input: ads7846 - don't report pressure for ads7845
From: Luca Ellero @ 2023-01-24 8:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Luca Ellero, dmitry.torokhov, daniel, m.felsch, u.kleine-koenig,
mkl, miquel.raynal, imre.deak, linux-input, linux-kernel
In-Reply-To: <Y858otTEDM1ugI0k@smile.fi.intel.com>
On 23/01/2023 13:25, Andy Shevchenko wrote:
> The Fixes tag in accordance with the documentation should refer to the commit
> in the Git history which brought the problem (regression).
>
>> It's more like this driver has never been tested with ADS7845.
>> Maybe the patches should be considered as a new implementation instead than
>> a bug fix?
> If it's indeed from day 1, then the initial commit can be considered as Fixes
> tag, but I leave it to maintainer to decide.
Hi Andy,
thank you for your reply.
OK, I will add the initial commit as Fixes: tag and resend all the series.
Regards
Luca Ellero
^ permalink raw reply
* Re: [PATCH] cros_ec_keyb: Add 3 buttons for monitor function
From: Dmitry Torokhov @ 2023-01-24 6:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Joe Wu, LKML, Xiang wangx, Stephen Boyd, Prashant Malani,
linux-input, chrome-platform, Benson Leung, Gustavo A . R . Silva,
Guenter Roeck, Douglas Anderson, Daisuke Nojiri, Derek Huang,
Dustin L . Howett, Joe Wu, Furquan Shaikh, Jonathan Cameron,
Lee Jones, Tzung-Bi Shih
In-Reply-To: <Y8uTt3zXgGPmevkb@kroah.com>
On Sat, Jan 21, 2023 at 08:26:47AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 20, 2023 at 09:24:18AM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 20, 2023 at 12:26:04PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote:
> > > > Add 3 extra buttons: 'brightness up', 'brightness down'
> > > > and 'screen lock' to support monitor manipulating function.
> > > >
> > > > Signed-off-by: Joe Wu <joewu@msi.com>
> > >
> > > From: line does not match the signed-off-by (and is an invalid email
> > > address...)
> >
> > What do you mean "it's an invalid email address"? You can definitely
> > send emails there... I prefer people not to use Google partner domain
> > accounts in the hope that their employment might outlast their
> > involvement in Google projects, but that is it.
>
> I was told that this was not a valid email address to send and receive
> emails from, and was only an email alias given to companies to interact
> with Google through their gerrit systems. If that is incorrect, I'll
> not complain about this anymore, but someone needs to please verify this
> for me before I do so :)
Not solely for gerrit, there are other systems at Google (for example
the issue tracker) that require Google account and that is why we create
them for partners. It is however a real account that can send and
receive e-mails. Whether anyone is looking at it, especially after they
moved to other projects, is a separate topic, but it is the same with a
random gmail or whatever account that people are creating to submit a
patch or two.
>
> But even if it is valid, should we accept it as a way to get in contact
> with the original submitter over time?
I believe that a real corp account is preferable for getting in contact
with the engineer who submitted the patch. Unfortunately corp accounts
often unsuitable for submitting patches to the kernel. Outgoing mail
servers either force HTML, mangle the text, or add legal-sounding
footers that result in snark replies. So submitters often try to use
another account to submit the code, such us a throwaway gmail account,
or as in this case, our "partner domain" account. Neither is ideal but
we require from to match sign-off (including email part) and complain
about sane option of overriding "from" in the mail body to be something
more sensitive, like the email that is actually used by the person in
question.
Again, I have more trust for patches sent as "Joe Wu
<joewu@msi.corp-partner.google.com>" with body
From: Joe Wu <joewu@msi.com>
...
Signed-off-by: Joe Wu <joewu@msi.com>
...
then patches sent and signed off as "Joe Wu <joemsi-oss@gmail.com>"
because I actually know that there is a process for establishing and
managing that @msi.corp-partner.google.com.
>
> > I think if we ask people to stick "From: <whatever the company address
> > is" in the body of the patch we can ignore the difference between sender
> > address and from/signed-off-by when they use partner domain accounts. If
> > anything, such accounts have better vetting than a random gmail or other
> > free email service account some vendors have to create to be able to
> > send a plain-text emails that we require. I mean, we have
> > "Signed-off-by: George Spelvin <lkml@sdf.org>" present in our git
> > history and nobody bats an eye...
>
> Oh lots of people "batted an eye" about that one, I've had too many
> meetings with lawyers about that, which is one reason I now verify email
> addresses like I did here.
Would you attempt to verify it is you saw a sign-off from "Daniil Kharms
<dank@gmail.com>"? What is the trigger for verification? How rigorous is
it?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: xpad - add 8BitDo Pro 2 Wired Controller support
From: John Butler @ 2023-01-24 0:52 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: John Butler, linux-input
Add VID and PID to the xpad_device table to allow driver
to use the 8BitDo Pro 2 Wired Controller, which is
XTYPE_XBOX360 compatible by default.
Signed-off-by: John Butler <radon86dev@gmail.com>
Cc: linux-input@vger.kernel.org
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 2959d80f7fdb..f642ec8e92dd 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -359,6 +359,7 @@ static const struct xpad_device {
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
{ 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
+ { 0x2dc8, 0x3106, "8BitDo Pro 2 Wired Controller", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
@@ -492,6 +493,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */
XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
+ XPAD_XBOX360_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller */
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
--
2.39.1
^ permalink raw reply related
* Re: [RFC PATCH] HID: support the NACON / BigBen PS4 / PC Compact controller
From: Roderick Colenbrander @ 2023-01-24 0:46 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: Linux Input ML, Dmitry Torokhov, Jiri Kosina,
Roderick Colenbrander
In-Reply-To: <CAOxFTcyqV-BgBTs33=Ux6EiiBuVRPX=OQGpbxQpTUQ91czK1RQ@mail.gmail.com>
Hi Giuseppe,
On Sun, Jan 22, 2023 at 3:43 AM Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
>
> Hello Roderick,
>
> I'm terribly sorry for the late reply, it's a bit of a busy period for
> me and I have had less time than I wished to test things.
>
> > Thanks for your work so far. My first thought was 'yikes what an ugly
> > device'. I'm not really sure what the best way of handling it is.
>
> The patch is beyond ugly (in addition to not working). But I'm barely
> treading water here, I'm way out of my element, hence why I came to
> the ML looking for help 8-)
>
> > First is the device a HID device? It would normally be picked up by
> > hid-generic. You can try dumping the HID descriptors.
>
> I'm afraid this is not the case, at least as far as I can tell. Again,
> keep in mind I'm not even exactly sure how to check these things out,
> so please bear with me, and feel free to direct me to appropriate
> resources.
> What I have tried is to first plug the pad in with xpad blacklisted,
> and lsusb -vs the device, which gave me:
>
> --8<-----------------
> Bus 001 Device 006: ID 146b:0603 BigBen Interactive PC Compact Controller
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 255 Vendor Specific Subclass
> bDeviceProtocol 255 Vendor Specific Protocol
> bMaxPacketSize0 64
> idVendor 0x146b BigBen Interactive
> idProduct 0x0603
> bcdDevice 1.00
> iManufacturer 1 Bigben Interactive
> iProduct 2 PC Compact Controller
> iSerial 3 58B00422
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 0x0031
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
You would normally expect bInterfaceClass to be 3 for 'Human Interface
Device'. I recall Xbox controllers in general have this at a vendor
specific value as they are not actual HID devices (with the exception
of in Bluetooth mode recently).
So it is not a formal HID device.
> bInterfaceSubClass 93
> bInterfaceProtocol 1
> iInterface 0
> ** UNRECOGNIZED: 11 21 00 01 01 25 81 14 00 00 00 00 13 02 08 03 03
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 4
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 8
> Device Status: 0x0000
> (Bus Powered)
> --8<-----------------
>
> I also tried running usbhid-dump, that claimed there were “No matching
> HID interfaces”.
>
> If I enable the xpad module shipping with my Debian sid distribution
> (6.0.12-1 from 2022-12-09), there's no difference on the lsusb and
> usbhid-dump outputs,
> even though xpad seems to detect and bind with the device:
>
> --8<-----------------
> [Jan23 05:33] usb 1-1: new full-speed USB device number 7 using xhci_hcd
> [ +0.149801] usb 1-1: New USB device found, idVendor=146b,
> idProduct=0603, bcdDevice= 1.00
> [ +0.000017] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ +0.000008] usb 1-1: Product: PC Compact Controller
> [ +0.000006] usb 1-1: Manufacturer: Bigben Interactive
> [ +0.000006] usb 1-1: SerialNumber: 58B00422
> [ +0.068217] input: Generic X-Box pad as
> /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input35
> [ +0.000114] usbcore: registered new interface driver xpad
> --8<-----------------
>
> Is there some other tool I can use to inspect the HID descriptors or
> check which protocols are supported, possibly depending on the device
> initialization?
The device doesn't seem to be a HID device, which is why there are no
descriptors. I haven't looked at the Xbox protocol in detail, but I
recall Xbox compatible devices report some magic value in some USB
descriptor, which is picked up by drivers and hence no need for a
formal driver unless overrides are needed.
> (I have other gamepads whose behavior seems to depend on
> initialization sequence, so this may be the case for this device too?)
>
> > It is a bit ugly if the device has to spawn multiple drivers. My
> > initial gut feeling would have been to complete the support within the
> > xpad driver. My understanding of our licensed controllers is that the
> > HID protocol they use is different from the DS4 protocol, so it is
> > really like handling an entire new device needing its own HID report
> > parsing. So, no matter what each driver would have needed some changes
> > to deal with the device properly and it is probably smallest in xpad.
>
> I don't have enough knowledge to know exactly what would be better,
> but I would expect the protocol to be closer to the PS one than the
> XBOX one,
> even though out of the box it kind of works with xpad (modulo the
> issues I mentioned).
> I also have no idea how similar or different the PS and XBOX protocols
> are, so it might just be that for the limited use and testing I've
> done they match.
So far it looks like the device is not a HID device, but only a USB
device. If true, you can't leverage the HID drivers and need to be in
a classic input driver such as xpad.
I'm honestly not sure how this device is working on PlayStation if it
is one of BigBen's licensed PlayStation compatible controllers. Our PS
input stack is all HID based (at least to my knowledge).
>
> > You mention access flipping and then the touchpad.
>
> Axes mapping is weird, but I think my original issue was actually with
> jstest-gtk not using the correct information. The CLI jstest seems to
> report things correctly.
> The “touchpad” is a rectangular area above the joysticks and between
> the DPAD and the box/triangle/x/o buttons. I'm not entirely surely if
> it's a touchpad or something else,
> but it seems to be clickable “everywhere”. It's not detected or
> exposed by the xpad driver in any way, but assume it would be
> accessible in the protocol.
> There's also something that looks like an audio jack.
>
The key question is to figure out how this touchpad works. Maybe some
people in the community documented this somewhere.
> I can run tests on this thing, but I really don't know what to try next.
>
> Thank you for your reply, and looking forward for things to try,
> Giuseppe Bilotta
>
>
Thanks,
Roderick
^ permalink raw reply
* Re: [PATCH v2 1/1] Docs/subsystem-apis: Remove '[The ]Linux' prefixes from titles of listed documents
From: Winiarska, Iwona @ 2023-01-23 22:41 UTC (permalink / raw)
To: corbet@lwn.net, sj@kernel.org
Cc: linux-input@vger.kernel.org, viresh.kumar@linaro.org,
linux-hwmon@vger.kernel.org, wim@linux-watchdog.org,
tzimmermann@suse.de, davem@davemloft.net, mripard@kernel.org,
herbert@gondor.apana.org.au, akpm@linux-foundation.org,
daniel@ffwll.ch, maarten.lankhorst@linux.intel.com,
jdelvare@suse.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux@roeck-us.net, perex@perex.cz,
dmitry.torokhov@gmail.com, linux-crypto@vger.kernel.org,
linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org,
tiwai@suse.com, openbmc@lists.ozlabs.org, airlied@gmail.com,
linux-pm@vger.kernel.org, rafael@kernel.org, bhelgaas@google.com,
alsa-devel@alsa-project.org, linux-pci@vger.kernel.org,
linux-watchdog@vger.kernel.org
In-Reply-To: <20230122184834.181977-1-sj@kernel.org>
On Sun, 2023-01-22 at 18:48 +0000, SeongJae Park wrote:
> Some documents that listed on subsystem-apis have 'Linux' or 'The Linux'
> title prefixes. It's duplicated information, and makes finding the
> document of interest with human eyes not easy. Remove the prefixes from
> the titles.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
For Documentation/peci/index.rst
Acked-by: Iwona Winiarska <iwona.winiarska@intel.com>
> ---
> Changes from v1
> (https://lore.kernel.org/lkml/20230114194741.115855-1-sj@kernel.org/)
> - Drop second patch (will post later for each subsystem)
>
> Documentation/PCI/index.rst | 6 +++---
> Documentation/cpu-freq/index.rst | 6 +++---
> Documentation/crypto/index.rst | 6 +++---
> Documentation/driver-api/index.rst | 6 +++---
> Documentation/gpu/index.rst | 6 +++---
> Documentation/hwmon/index.rst | 6 +++---
> Documentation/input/index.rst | 6 +++---
> Documentation/mm/index.rst | 6 +++---
> Documentation/peci/index.rst | 6 +++---
> Documentation/scheduler/index.rst | 6 +++---
> Documentation/scsi/index.rst | 6 +++---
> Documentation/sound/index.rst | 6 +++---
> Documentation/virt/index.rst | 6 +++---
> Documentation/watchdog/index.rst | 6 +++---
> 14 files changed, 42 insertions(+), 42 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/1] HID: evision: Add preliminary support for EVision keyboards
From: Philippe Valembois @ 2023-01-23 21:24 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-kernel, linux-input
In-Reply-To: <CAO-hwJJwUQJueutZ5z_4qwBb1Y4+-9h3ta0Xran=s6pJ_e3itQ@mail.gmail.com>
Hello,
Thanks for the review.
I just sent an updated patch taking your comments into account.
Regards,
Philippe Valembois
Le lun. 23 janv. 2023 à 08:57, Benjamin Tissoires
<benjamin.tissoires@redhat.com> a écrit :
>
> On Sat, Dec 24, 2022 at 1:23 PM Philippe Valembois
> <lephilousophe@gmail.com> wrote:
> >
> > From: Philippe Valembois <lephilousophe@users.noreply.github.com>
>
> Jiri, I have a doubt. Do we accept emails from users.noreply.github.com?
>
> >
> > For now only supports one model and only filters out bogus reports sent
> > when the keyboard has been configured through hidraw.
> > Without this, as events are not released, soft repeat floods userspace
> > with unknown key events.
> >
> > Signed-off-by: Philippe Valembois <lephilousophe@users.noreply.github.com>
> > ---
> > drivers/hid/Kconfig | 7 ++++
> > drivers/hid/Makefile | 1 +
> > drivers/hid/hid-evision.c | 79 +++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 87 insertions(+)
> > create mode 100644 drivers/hid/hid-evision.c
> >
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> > index e2a5d30c8..1320ea75c 100644
> > --- a/drivers/hid/Kconfig
> > +++ b/drivers/hid/Kconfig
> > @@ -329,6 +329,13 @@ config HID_ELO
> > Support for the ELO USB 4000/4500 touchscreens. Note that this is for
> > different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
> >
> > +config HID_EVISION
> > + tristate "EVision Keyboards Support"
> > + depends on USB_HID
>
> AFAICT, the driver only uses pure HID API, so you should be able to
> depend on HID, not just USB_HID.
>
> > + help
> > + Support for some EVision keyboards. Note that this is needed only when
> > + applying customization using userspace programs.
> > +
> > config HID_EZKEY
> > tristate "Ezkey BTC 8193 keyboard"
> > default !EXPERT
> > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> > index e8014c1a2..bd01571dd 100644
> > --- a/drivers/hid/Makefile
> > +++ b/drivers/hid/Makefile
> > @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
> > obj-$(CONFIG_HID_ELAN) += hid-elan.o
> > obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
> > obj-$(CONFIG_HID_ELO) += hid-elo.o
> > +obj-$(CONFIG_HID_EVISION) += hid-evision.o
> > obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> > obj-$(CONFIG_HID_FT260) += hid-ft260.o
> > obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> > diff --git a/drivers/hid/hid-evision.c b/drivers/hid/hid-evision.c
> > new file mode 100644
> > index 000000000..6ea331575
> > --- /dev/null
> > +++ b/drivers/hid/hid-evision.c
> > @@ -0,0 +1,79 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * HID driver for EVision devices
> > + * For now, only ignore bogus consumer reports
> > + * sent after the keyboard has been configured
> > + *
> > + * Copyright (c) 2022 Philippe Valembois
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/input.h>
> > +#include <linux/hid.h>
> > +#include <linux/module.h>
> > +#include <linux/usb.h>
>
> Outside of hid_is_usb(), you are not using anything USB related, so
> this can be dropped
>
> > +
> > +
> > +#define USB_VENDOR_ID_EVISION 0x320f
> > +#define USB_DEVICE_ID_EVISION_ICL01 0x5041
>
> We tend to add those variables in drivers/hid/hid-ids.h
>
> > +
> > +static int evision_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> > + struct hid_field *field, struct hid_usage *usage,
> > + unsigned long **bit, int *max)
> > +{
> > + if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
> > + return 0;
> > +
> > + // Ignore key down event
>
> No C++ comments style please, use /* */ instead
>
> > + if ((usage->hid & HID_USAGE) >> 8 == 0x05)
> > + return -1;
> > + // Ignore key up event
>
> Same (and for any other // below).
>
> > + if ((usage->hid & HID_USAGE) >> 8 == 0x06)
> > + return -1;
> > +
> > + switch (usage->hid & HID_USAGE) {
> > + // Ignore configuration saved event
> > + case 0x0401: return -1;
> > + // Ignore reset event
> > + case 0x0402: return -1;
> > + }
> > + return 0;
> > +}
> > +
> > +static int evision_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > +{
> > + int ret;
> > +
> > + if (!hid_is_usb(hdev))
> > + return -EINVAL;
>
> This can be dropped...
>
> > +
> > + ret = hid_parse(hdev);
> > + if (ret) {
> > + hid_err(hdev, "EVision hid parse failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> > + if (ret) {
> > + hid_err(hdev, "EVision hw start failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
>
> ... which means the probe is the default one, meaning it can also be
> dropped from the patch :)
>
> > +}
> > +
> > +static const struct hid_device_id evision_devices[] = {
> > + { HID_USB_DEVICE(USB_VENDOR_ID_EVISION, USB_DEVICE_ID_EVISION_ICL01) },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(hid, evision_devices);
> > +
> > +static struct hid_driver evision_driver = {
> > + .name = "evision",
> > + .id_table = evision_devices,
> > + .input_mapping = evision_input_mapping,
> > + .probe = evision_probe,
>
> Just for completeness, remove that .probe line and your driver will
> behave the same and be smaller :)
>
> > +};
> > +module_hid_driver(evision_driver);
> > +
> > +MODULE_LICENSE("GPL");
> > --
> > 2.38.2
> >
>
> Cheers,
> Benjamin
>
^ permalink raw reply
* [PATCH v2 1/1] HID: evision: Add preliminary support for EVision keyboards
From: Philippe Valembois @ 2023-01-23 21:18 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-kernel, linux-input
Cc: Philippe Valembois
In-Reply-To: <CAO-hwJJwUQJueutZ5z_4qwBb1Y4+-9h3ta0Xran=s6pJ_e3itQ@mail.gmail.com>
From: Philippe Valembois <lephilousophe@users.noreply.github.com>
For now only supports one model and only filters out bogus reports sent
when the keyboard has been configured through hidraw.
Without this, as events are not released, soft repeat floods userspace
with unknown key events.
Signed-off-by: Philippe Valembois <lephilousophe@users.noreply.github.com>
---
drivers/hid/Kconfig | 7 ++++++
drivers/hid/Makefile | 1 +
drivers/hid/hid-evision.c | 53 +++++++++++++++++++++++++++++++++++++++
drivers/hid/hid-ids.h | 3 +++
4 files changed, 64 insertions(+)
create mode 100644 drivers/hid/hid-evision.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index e2a5d30c8..35f214773 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -329,6 +329,13 @@ config HID_ELO
Support for the ELO USB 4000/4500 touchscreens. Note that this is for
different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
+config HID_EVISION
+ tristate "EVision Keyboards Support"
+ depends on HID
+ help
+ Support for some EVision keyboards. Note that this is needed only when
+ applying customization using userspace programs.
+
config HID_EZKEY
tristate "Ezkey BTC 8193 keyboard"
default !EXPERT
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index e8014c1a2..bd01571dd 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELAN) += hid-elan.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
+obj-$(CONFIG_HID_EVISION) += hid-evision.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
obj-$(CONFIG_HID_FT260) += hid-ft260.o
obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
diff --git a/drivers/hid/hid-evision.c b/drivers/hid/hid-evision.c
new file mode 100644
index 000000000..ef6b4b435
--- /dev/null
+++ b/drivers/hid/hid-evision.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for EVision devices
+ * For now, only ignore bogus consumer reports
+ * sent after the keyboard has been configured
+ *
+ * Copyright (c) 2022 Philippe Valembois
+ */
+
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+static int evision_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
+ return 0;
+
+ /* Ignore key down event */
+ if ((usage->hid & HID_USAGE) >> 8 == 0x05)
+ return -1;
+ /* Ignore key up event */
+ if ((usage->hid & HID_USAGE) >> 8 == 0x06)
+ return -1;
+
+ switch (usage->hid & HID_USAGE) {
+ /* Ignore configuration saved event */
+ case 0x0401: return -1;
+ /* Ignore reset event */
+ case 0x0402: return -1;
+ }
+ return 0;
+}
+
+static const struct hid_device_id evision_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_EVISION, USB_DEVICE_ID_EVISION_ICL01) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, evision_devices);
+
+static struct hid_driver evision_driver = {
+ .name = "evision",
+ .id_table = evision_devices,
+ .input_mapping = evision_input_mapping,
+};
+module_hid_driver(evision_driver);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0f8c11842..7ae89aebd 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -445,6 +445,9 @@
#define USB_VENDOR_ID_EMS 0x2006
#define USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II 0x0118
+#define USB_VENDOR_ID_EVISION 0x320f
+#define USB_DEVICE_ID_EVISION_ICL01 0x5041
+
#define USB_VENDOR_ID_FLATFROG 0x25b5
#define USB_DEVICE_ID_MULTITOUCH_3200 0x0002
--
2.39.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] Docs/subsystem-apis: Remove '[The ]Linux' prefixes from titles of listed documents
From: Bjorn Helgaas @ 2023-01-23 20:34 UTC (permalink / raw)
To: SeongJae Park
Cc: Jonathan Corbet, alsa-devel, linux-doc, Viresh Kumar, dri-devel,
Jaroslav Kysela, linux-mm, linux-watchdog, Herbert Xu,
Iwona Winiarska, openbmc, Rafael J. Wysocki, linux-pci,
Guenter Roeck, Jean Delvare, linux-pm, linux-input, Bjorn Helgaas,
Wim Van Sebroeck, linux-hwmon, Dmitry Torokhov, Takashi Iwai,
linux-kernel, linux-crypto, Thomas Zimmermann, Andrew Morton,
David S. Miller
In-Reply-To: <20230122184834.181977-1-sj@kernel.org>
On Sun, Jan 22, 2023 at 06:48:34PM +0000, SeongJae Park wrote:
> Some documents that listed on subsystem-apis have 'Linux' or 'The Linux'
> title prefixes. It's duplicated information, and makes finding the
> document of interest with human eyes not easy. Remove the prefixes from
> the titles.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
PCI/index.rst change is fine with me:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> Changes from v1
> (https://lore.kernel.org/lkml/20230114194741.115855-1-sj@kernel.org/)
> - Drop second patch (will post later for each subsystem)
>
> Documentation/PCI/index.rst | 6 +++---
> Documentation/cpu-freq/index.rst | 6 +++---
> Documentation/crypto/index.rst | 6 +++---
> Documentation/driver-api/index.rst | 6 +++---
> Documentation/gpu/index.rst | 6 +++---
> Documentation/hwmon/index.rst | 6 +++---
> Documentation/input/index.rst | 6 +++---
> Documentation/mm/index.rst | 6 +++---
> Documentation/peci/index.rst | 6 +++---
> Documentation/scheduler/index.rst | 6 +++---
> Documentation/scsi/index.rst | 6 +++---
> Documentation/sound/index.rst | 6 +++---
> Documentation/virt/index.rst | 6 +++---
> Documentation/watchdog/index.rst | 6 +++---
> 14 files changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index c17c87af1968..e73f84aebde3 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -1,8 +1,8 @@
> .. SPDX-License-Identifier: GPL-2.0
>
> -=======================
> -Linux PCI Bus Subsystem
> -=======================
> +=================
> +PCI Bus Subsystem
> +=================
>
> .. toctree::
> :maxdepth: 2
^ permalink raw reply
* Re: [PATCH 2/2] platform/surface: aggregator: Rename top-level request functions to avoid ambiguities
From: Hans de Goede @ 2023-01-23 15:40 UTC (permalink / raw)
To: Maximilian Luz
Cc: Mark Gross, Jiri Kosina, Benjamin Tissoires, Jonathan Corbet,
platform-driver-x86, linux-input, linux-doc, linux-kernel
In-Reply-To: <20221220175608.1436273-2-luzmaximilian@gmail.com>
Hi,
On 12/20/22 18:56, Maximilian Luz wrote:
> We currently have a struct ssam_request_sync and a function
> ssam_request_sync(). While this is valid C, there are some downsides to
> it.
>
> One of these is that current Sphinx versions (>= 3.0) cannot
> disambiguate between the two (see disucssion and pull request linked
> below). It instead emits a "WARNING: Duplicate C declaration" and links
> for the struct and function in the resulting documentation link to the
> same entry (i.e. both to either function or struct documentation)
> instead of their respective own entries.
>
> While we could just ignore that and wait for a fix, there's also a point
> to be made that the current naming can be somewhat confusing when
> searching (e.g. via grep) or trying to understand the levels of
> abstraction at play:
>
> We currently have struct ssam_request_sync and associated functions
> ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct.
> However, function ssam_request_sync() is one abstraction level above
> this. Similarly, ssam_request_sync_with_buffer() is not a function
> operating on struct ssam_request_sync, but rather a sibling to
> ssam_request_sync(), both using the struct under the hood.
>
> Therefore, rename the top level request functions:
>
> ssam_request_sync() -> ssam_request_do_sync()
> ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer()
> ssam_request_sync_onstack() -> ssam_request_do_sync_onstack()
>
> Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/
> Link: https://github.com/sphinx-doc/sphinx/pull/8313
> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Thank you for your patch, I've applied this patch to my review-hans
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans
Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.
Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.
Regards,
Hans
> ---
> .../driver-api/surface_aggregator/client.rst | 8 +--
> drivers/hid/surface-hid/surface_hid.c | 6 +-
> drivers/hid/surface-hid/surface_kbd.c | 6 +-
> drivers/platform/surface/aggregator/bus.c | 6 +-
> .../platform/surface/aggregator/controller.c | 32 +++++------
> .../platform/surface/surface_acpi_notify.c | 2 +-
> .../surface/surface_aggregator_cdev.c | 6 +-
> .../surface/surface_aggregator_tabletsw.c | 2 +-
> include/linux/surface_aggregator/controller.h | 56 +++++++++----------
> include/linux/surface_aggregator/device.h | 8 +--
> 10 files changed, 66 insertions(+), 66 deletions(-)
>
> diff --git a/Documentation/driver-api/surface_aggregator/client.rst b/Documentation/driver-api/surface_aggregator/client.rst
> index 27f95abdbe99..dd96f8eb6578 100644
> --- a/Documentation/driver-api/surface_aggregator/client.rst
> +++ b/Documentation/driver-api/surface_aggregator/client.rst
> @@ -19,7 +19,7 @@
> .. |ssam_notifier_unregister| replace:: :c:func:`ssam_notifier_unregister`
> .. |ssam_device_notifier_register| replace:: :c:func:`ssam_device_notifier_register`
> .. |ssam_device_notifier_unregister| replace:: :c:func:`ssam_device_notifier_unregister`
> -.. |ssam_request_sync| replace:: :c:func:`ssam_request_sync`
> +.. |ssam_request_do_sync| replace:: :c:func:`ssam_request_do_sync`
> .. |ssam_event_mask| replace:: :c:type:`enum ssam_event_mask <ssam_event_mask>`
>
>
> @@ -209,12 +209,12 @@ data received from it is converted from little-endian to host endianness.
> * with the SSAM_REQUEST_HAS_RESPONSE flag set in the specification
> * above.
> */
> - status = ssam_request_sync(ctrl, &rqst, &resp);
> + status = ssam_request_do_sync(ctrl, &rqst, &resp);
>
> /*
> * Alternatively use
> *
> - * ssam_request_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
> + * ssam_request_do_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
> *
> * to perform the request, allocating the message buffer directly
> * on the stack as opposed to allocation via kzalloc().
> @@ -230,7 +230,7 @@ data received from it is converted from little-endian to host endianness.
> return status;
> }
>
> -Note that |ssam_request_sync| in its essence is a wrapper over lower-level
> +Note that |ssam_request_do_sync| in its essence is a wrapper over lower-level
> request primitives, which may also be used to perform requests. Refer to its
> implementation and documentation for more details.
>
> diff --git a/drivers/hid/surface-hid/surface_hid.c b/drivers/hid/surface-hid/surface_hid.c
> index d4aa8c81903a..bcb6ffd0e6ff 100644
> --- a/drivers/hid/surface-hid/surface_hid.c
> +++ b/drivers/hid/surface-hid/surface_hid.c
> @@ -80,7 +80,7 @@ static int ssam_hid_get_descriptor(struct surface_hid_device *shid, u8 entry, u8
>
> rsp.length = 0;
>
> - status = ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp,
> + status = ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp,
> sizeof(*slice));
> if (status)
> return status;
> @@ -131,7 +131,7 @@ static int ssam_hid_set_raw_report(struct surface_hid_device *shid, u8 rprt_id,
>
> buf[0] = rprt_id;
>
> - return ssam_retry(ssam_request_sync, shid->ctrl, &rqst, NULL);
> + return ssam_retry(ssam_request_do_sync, shid->ctrl, &rqst, NULL);
> }
>
> static int ssam_hid_get_raw_report(struct surface_hid_device *shid, u8 rprt_id, u8 *buf, size_t len)
> @@ -151,7 +151,7 @@ static int ssam_hid_get_raw_report(struct surface_hid_device *shid, u8 rprt_id,
> rsp.length = 0;
> rsp.pointer = buf;
>
> - return ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(rprt_id));
> + return ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(rprt_id));
> }
>
> static u32 ssam_hid_event_fn(struct ssam_event_notifier *nf, const struct ssam_event *event)
> diff --git a/drivers/hid/surface-hid/surface_kbd.c b/drivers/hid/surface-hid/surface_kbd.c
> index 0635341bc517..7ca8038026ce 100644
> --- a/drivers/hid/surface-hid/surface_kbd.c
> +++ b/drivers/hid/surface-hid/surface_kbd.c
> @@ -49,7 +49,7 @@ static int ssam_kbd_get_descriptor(struct surface_hid_device *shid, u8 entry, u8
> rsp.length = 0;
> rsp.pointer = buf;
>
> - status = ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(entry));
> + status = ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(entry));
> if (status)
> return status;
>
> @@ -75,7 +75,7 @@ static int ssam_kbd_set_caps_led(struct surface_hid_device *shid, bool value)
> rqst.length = sizeof(value_u8);
> rqst.payload = &value_u8;
>
> - return ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, NULL, sizeof(value_u8));
> + return ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, NULL, sizeof(value_u8));
> }
>
> static int ssam_kbd_get_feature_report(struct surface_hid_device *shid, u8 *buf, size_t len)
> @@ -97,7 +97,7 @@ static int ssam_kbd_get_feature_report(struct surface_hid_device *shid, u8 *buf,
> rsp.length = 0;
> rsp.pointer = buf;
>
> - status = ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(payload));
> + status = ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(payload));
> if (status)
> return status;
>
> diff --git a/drivers/platform/surface/aggregator/bus.c b/drivers/platform/surface/aggregator/bus.c
> index de539938896e..7004eb4a63a2 100644
> --- a/drivers/platform/surface/aggregator/bus.c
> +++ b/drivers/platform/surface/aggregator/bus.c
> @@ -136,9 +136,9 @@ int ssam_device_add(struct ssam_device *sdev)
> * is always valid and can be used for requests as long as the client
> * device we add here is registered as child under it. This essentially
> * guarantees that the client driver can always expect the preconditions
> - * for functions like ssam_request_sync (controller has to be started
> - * and is not suspended) to hold and thus does not have to check for
> - * them.
> + * for functions like ssam_request_do_sync() (controller has to be
> + * started and is not suspended) to hold and thus does not have to check
> + * for them.
> *
> * Note that for this to work, the controller has to be a parent device.
> * If it is not a direct parent, care has to be taken that the device is
> diff --git a/drivers/platform/surface/aggregator/controller.c b/drivers/platform/surface/aggregator/controller.c
> index c6537a1b3a2e..9c43b9665a2c 100644
> --- a/drivers/platform/surface/aggregator/controller.c
> +++ b/drivers/platform/surface/aggregator/controller.c
> @@ -1674,7 +1674,7 @@ int ssam_request_sync_submit(struct ssam_controller *ctrl,
> EXPORT_SYMBOL_GPL(ssam_request_sync_submit);
>
> /**
> - * ssam_request_sync() - Execute a synchronous request.
> + * ssam_request_do_sync() - Execute a synchronous request.
> * @ctrl: The controller via which the request will be submitted.
> * @spec: The request specification and payload.
> * @rsp: The response buffer.
> @@ -1686,9 +1686,9 @@ EXPORT_SYMBOL_GPL(ssam_request_sync_submit);
> *
> * Return: Returns the status of the request or any failure during setup.
> */
> -int ssam_request_sync(struct ssam_controller *ctrl,
> - const struct ssam_request *spec,
> - struct ssam_response *rsp)
> +int ssam_request_do_sync(struct ssam_controller *ctrl,
> + const struct ssam_request *spec,
> + struct ssam_response *rsp)
> {
> struct ssam_request_sync *rqst;
> struct ssam_span buf;
> @@ -1722,10 +1722,10 @@ int ssam_request_sync(struct ssam_controller *ctrl,
> ssam_request_sync_free(rqst);
> return status;
> }
> -EXPORT_SYMBOL_GPL(ssam_request_sync);
> +EXPORT_SYMBOL_GPL(ssam_request_do_sync);
>
> /**
> - * ssam_request_sync_with_buffer() - Execute a synchronous request with the
> + * ssam_request_do_sync_with_buffer() - Execute a synchronous request with the
> * provided buffer as back-end for the message buffer.
> * @ctrl: The controller via which the request will be submitted.
> * @spec: The request specification and payload.
> @@ -1738,17 +1738,17 @@ EXPORT_SYMBOL_GPL(ssam_request_sync);
> * SSH_COMMAND_MESSAGE_LENGTH() macro can be used to compute the required
> * message buffer size.
> *
> - * This function does essentially the same as ssam_request_sync(), but instead
> - * of dynamically allocating the request and message data buffer, it uses the
> - * provided message data buffer and stores the (small) request struct on the
> - * heap.
> + * This function does essentially the same as ssam_request_do_sync(), but
> + * instead of dynamically allocating the request and message data buffer, it
> + * uses the provided message data buffer and stores the (small) request struct
> + * on the heap.
> *
> * Return: Returns the status of the request or any failure during setup.
> */
> -int ssam_request_sync_with_buffer(struct ssam_controller *ctrl,
> - const struct ssam_request *spec,
> - struct ssam_response *rsp,
> - struct ssam_span *buf)
> +int ssam_request_do_sync_with_buffer(struct ssam_controller *ctrl,
> + const struct ssam_request *spec,
> + struct ssam_response *rsp,
> + struct ssam_span *buf)
> {
> struct ssam_request_sync rqst;
> ssize_t len;
> @@ -1772,7 +1772,7 @@ int ssam_request_sync_with_buffer(struct ssam_controller *ctrl,
>
> return status;
> }
> -EXPORT_SYMBOL_GPL(ssam_request_sync_with_buffer);
> +EXPORT_SYMBOL_GPL(ssam_request_do_sync_with_buffer);
>
>
> /* -- Internal SAM requests. ------------------------------------------------ */
> @@ -1864,7 +1864,7 @@ static int __ssam_ssh_event_request(struct ssam_controller *ctrl,
> result.length = 0;
> result.pointer = &buf;
>
> - status = ssam_retry(ssam_request_sync_onstack, ctrl, &rqst, &result,
> + status = ssam_retry(ssam_request_do_sync_onstack, ctrl, &rqst, &result,
> sizeof(params));
>
> return status < 0 ? status : buf;
> diff --git a/drivers/platform/surface/surface_acpi_notify.c b/drivers/platform/surface/surface_acpi_notify.c
> index 50500e562963..897cdd9c3aae 100644
> --- a/drivers/platform/surface/surface_acpi_notify.c
> +++ b/drivers/platform/surface/surface_acpi_notify.c
> @@ -590,7 +590,7 @@ static acpi_status san_rqst(struct san_data *d, struct gsb_buffer *buffer)
> return san_rqst_fixup_suspended(d, &rqst, buffer);
> }
>
> - status = __ssam_retry(ssam_request_sync_onstack, SAN_REQUEST_NUM_TRIES,
> + status = __ssam_retry(ssam_request_do_sync_onstack, SAN_REQUEST_NUM_TRIES,
> d->ctrl, &rqst, &rsp, SAN_GSB_MAX_RQSX_PAYLOAD);
>
> if (!status) {
> diff --git a/drivers/platform/surface/surface_aggregator_cdev.c b/drivers/platform/surface/surface_aggregator_cdev.c
> index 492c82e69182..07f0ed658369 100644
> --- a/drivers/platform/surface/surface_aggregator_cdev.c
> +++ b/drivers/platform/surface/surface_aggregator_cdev.c
> @@ -302,8 +302,8 @@ static long ssam_cdev_request(struct ssam_cdev_client *client, struct ssam_cdev_
> * theoretical maximum (SSH_COMMAND_MAX_PAYLOAD_SIZE) of the
> * underlying protocol (note that nothing remotely this size
> * should ever be allocated in any normal case). This size is
> - * validated later in ssam_request_sync(), for allocation the
> - * bound imposed by u16 should be enough.
> + * validated later in ssam_request_do_sync(), for allocation
> + * the bound imposed by u16 should be enough.
> */
> spec.payload = kzalloc(spec.length, GFP_KERNEL);
> if (!spec.payload) {
> @@ -342,7 +342,7 @@ static long ssam_cdev_request(struct ssam_cdev_client *client, struct ssam_cdev_
> }
>
> /* Perform request. */
> - status = ssam_request_sync(client->cdev->ctrl, &spec, &rsp);
> + status = ssam_request_do_sync(client->cdev->ctrl, &spec, &rsp);
> if (status)
> goto out;
>
> diff --git a/drivers/platform/surface/surface_aggregator_tabletsw.c b/drivers/platform/surface/surface_aggregator_tabletsw.c
> index 27d95a6a7851..c3a5b7f56c8f 100644
> --- a/drivers/platform/surface/surface_aggregator_tabletsw.c
> +++ b/drivers/platform/surface/surface_aggregator_tabletsw.c
> @@ -382,7 +382,7 @@ static int ssam_pos_get_sources_list(struct ssam_tablet_sw *sw, struct ssam_sour
> rsp.length = 0;
> rsp.pointer = (u8 *)sources;
>
> - status = ssam_retry(ssam_request_sync_onstack, sw->sdev->ctrl, &rqst, &rsp, 0);
> + status = ssam_retry(ssam_request_do_sync_onstack, sw->sdev->ctrl, &rqst, &rsp, 0);
> if (status)
> return status;
>
> diff --git a/include/linux/surface_aggregator/controller.h b/include/linux/surface_aggregator/controller.h
> index d11a1c6e3186..350d6c6c0a1d 100644
> --- a/include/linux/surface_aggregator/controller.h
> +++ b/include/linux/surface_aggregator/controller.h
> @@ -207,17 +207,17 @@ static inline int ssam_request_sync_wait(struct ssam_request_sync *rqst)
> return rqst->status;
> }
>
> -int ssam_request_sync(struct ssam_controller *ctrl,
> - const struct ssam_request *spec,
> - struct ssam_response *rsp);
> +int ssam_request_do_sync(struct ssam_controller *ctrl,
> + const struct ssam_request *spec,
> + struct ssam_response *rsp);
>
> -int ssam_request_sync_with_buffer(struct ssam_controller *ctrl,
> - const struct ssam_request *spec,
> - struct ssam_response *rsp,
> - struct ssam_span *buf);
> +int ssam_request_do_sync_with_buffer(struct ssam_controller *ctrl,
> + const struct ssam_request *spec,
> + struct ssam_response *rsp,
> + struct ssam_span *buf);
>
> /**
> - * ssam_request_sync_onstack - Execute a synchronous request on the stack.
> + * ssam_request_do_sync_onstack - Execute a synchronous request on the stack.
> * @ctrl: The controller via which the request is submitted.
> * @rqst: The request specification.
> * @rsp: The response buffer.
> @@ -227,7 +227,7 @@ int ssam_request_sync_with_buffer(struct ssam_controller *ctrl,
> * fully initializes it via the provided request specification, submits it,
> * and finally waits for its completion before returning its status. This
> * helper macro essentially allocates the request message buffer on the stack
> - * and then calls ssam_request_sync_with_buffer().
> + * and then calls ssam_request_do_sync_with_buffer().
> *
> * Note: The @payload_len parameter specifies the maximum payload length, used
> * for buffer allocation. The actual payload length may be smaller.
> @@ -235,12 +235,12 @@ int ssam_request_sync_with_buffer(struct ssam_controller *ctrl,
> * Return: Returns the status of the request or any failure during setup, i.e.
> * zero on success and a negative value on failure.
> */
> -#define ssam_request_sync_onstack(ctrl, rqst, rsp, payload_len) \
> +#define ssam_request_do_sync_onstack(ctrl, rqst, rsp, payload_len) \
> ({ \
> u8 __data[SSH_COMMAND_MESSAGE_LENGTH(payload_len)]; \
> struct ssam_span __buf = { &__data[0], ARRAY_SIZE(__data) }; \
> \
> - ssam_request_sync_with_buffer(ctrl, rqst, rsp, &__buf); \
> + ssam_request_do_sync_with_buffer(ctrl, rqst, rsp, &__buf); \
> })
>
> /**
> @@ -349,7 +349,7 @@ struct ssam_request_spec_md {
> * zero on success and negative on failure. The ``ctrl`` parameter is the
> * controller via which the request is being sent.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_N(name, spec...) \
> @@ -366,7 +366,7 @@ struct ssam_request_spec_md {
> rqst.length = 0; \
> rqst.payload = NULL; \
> \
> - return ssam_request_sync_onstack(ctrl, &rqst, NULL, 0); \
> + return ssam_request_do_sync_onstack(ctrl, &rqst, NULL, 0); \
> }
>
> /**
> @@ -389,7 +389,7 @@ struct ssam_request_spec_md {
> * parameter is the controller via which the request is sent. The request
> * argument is specified via the ``arg`` pointer.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_W(name, atype, spec...) \
> @@ -406,8 +406,8 @@ struct ssam_request_spec_md {
> rqst.length = sizeof(atype); \
> rqst.payload = (u8 *)arg; \
> \
> - return ssam_request_sync_onstack(ctrl, &rqst, NULL, \
> - sizeof(atype)); \
> + return ssam_request_do_sync_onstack(ctrl, &rqst, NULL, \
> + sizeof(atype)); \
> }
>
> /**
> @@ -430,7 +430,7 @@ struct ssam_request_spec_md {
> * the controller via which the request is sent. The request's return value is
> * written to the memory pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_R(name, rtype, spec...) \
> @@ -453,7 +453,7 @@ struct ssam_request_spec_md {
> rsp.length = 0; \
> rsp.pointer = (u8 *)ret; \
> \
> - status = ssam_request_sync_onstack(ctrl, &rqst, &rsp, 0); \
> + status = ssam_request_do_sync_onstack(ctrl, &rqst, &rsp, 0); \
> if (status) \
> return status; \
> \
> @@ -491,7 +491,7 @@ struct ssam_request_spec_md {
> * request argument is specified via the ``arg`` pointer. The request's return
> * value is written to the memory pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_WR(name, atype, rtype, spec...) \
> @@ -514,7 +514,7 @@ struct ssam_request_spec_md {
> rsp.length = 0; \
> rsp.pointer = (u8 *)ret; \
> \
> - status = ssam_request_sync_onstack(ctrl, &rqst, &rsp, sizeof(atype)); \
> + status = ssam_request_do_sync_onstack(ctrl, &rqst, &rsp, sizeof(atype)); \
> if (status) \
> return status; \
> \
> @@ -550,7 +550,7 @@ struct ssam_request_spec_md {
> * parameter is the controller via which the request is sent, ``tid`` the
> * target ID for the request, and ``iid`` the instance ID.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_MD_N(name, spec...) \
> @@ -567,7 +567,7 @@ struct ssam_request_spec_md {
> rqst.length = 0; \
> rqst.payload = NULL; \
> \
> - return ssam_request_sync_onstack(ctrl, &rqst, NULL, 0); \
> + return ssam_request_do_sync_onstack(ctrl, &rqst, NULL, 0); \
> }
>
> /**
> @@ -592,7 +592,7 @@ struct ssam_request_spec_md {
> * ``tid`` the target ID for the request, and ``iid`` the instance ID. The
> * request argument is specified via the ``arg`` pointer.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_MD_W(name, atype, spec...) \
> @@ -609,7 +609,7 @@ struct ssam_request_spec_md {
> rqst.length = sizeof(atype); \
> rqst.payload = (u8 *)arg; \
> \
> - return ssam_request_sync_onstack(ctrl, &rqst, NULL, \
> + return ssam_request_do_sync_onstack(ctrl, &rqst, NULL, \
> sizeof(atype)); \
> }
>
> @@ -635,7 +635,7 @@ struct ssam_request_spec_md {
> * the target ID for the request, and ``iid`` the instance ID. The request's
> * return value is written to the memory pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_MD_R(name, rtype, spec...) \
> @@ -658,7 +658,7 @@ struct ssam_request_spec_md {
> rsp.length = 0; \
> rsp.pointer = (u8 *)ret; \
> \
> - status = ssam_request_sync_onstack(ctrl, &rqst, &rsp, 0); \
> + status = ssam_request_do_sync_onstack(ctrl, &rqst, &rsp, 0); \
> if (status) \
> return status; \
> \
> @@ -698,7 +698,7 @@ struct ssam_request_spec_md {
> * The request argument is specified via the ``arg`` pointer. The request's
> * return value is written to the memory pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_MD_WR(name, atype, rtype, spec...) \
> @@ -722,7 +722,7 @@ struct ssam_request_spec_md {
> rsp.length = 0; \
> rsp.pointer = (u8 *)ret; \
> \
> - status = ssam_request_sync_onstack(ctrl, &rqst, &rsp, sizeof(atype)); \
> + status = ssam_request_do_sync_onstack(ctrl, &rqst, &rsp, sizeof(atype)); \
> if (status) \
> return status; \
> \
> diff --git a/include/linux/surface_aggregator/device.h b/include/linux/surface_aggregator/device.h
> index 46c45d1b6368..0e353f5cc2e6 100644
> --- a/include/linux/surface_aggregator/device.h
> +++ b/include/linux/surface_aggregator/device.h
> @@ -456,7 +456,7 @@ static inline int ssam_device_register_clients(struct ssam_device *sdev)
> * device of the request and by association the controller via which the
> * request is sent.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_CL_N(name, spec...) \
> @@ -490,7 +490,7 @@ static inline int ssam_device_register_clients(struct ssam_device *sdev)
> * which the request is sent. The request's argument is specified via the
> * ``arg`` pointer.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_CL_W(name, atype, spec...) \
> @@ -524,7 +524,7 @@ static inline int ssam_device_register_clients(struct ssam_device *sdev)
> * the request is sent. The request's return value is written to the memory
> * pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_CL_R(name, rtype, spec...) \
> @@ -560,7 +560,7 @@ static inline int ssam_device_register_clients(struct ssam_device *sdev)
> * specified via the ``arg`` pointer. The request's return value is written to
> * the memory pointed to by the ``ret`` parameter.
> *
> - * Refer to ssam_request_sync_onstack() for more details on the behavior of
> + * Refer to ssam_request_do_sync_onstack() for more details on the behavior of
> * the generated function.
> */
> #define SSAM_DEFINE_SYNC_REQUEST_CL_WR(name, atype, rtype, spec...) \
^ permalink raw reply
* Re: [PATCH 0/9] platform/surface: aggregator: Improve target/source handling in SSH messages
From: Hans de Goede @ 2023-01-23 15:37 UTC (permalink / raw)
To: Maximilian Luz, Jiri Kosina, Benjamin Tissoires,
Sebastian Reichel
Cc: Mark Gross, Jonathan Corbet, platform-driver-x86, linux-doc,
linux-input, linux-pm, linux-kernel
In-Reply-To: <20221202223327.690880-1-luzmaximilian@gmail.com>
Hi,
On 12/2/22 23:33, Maximilian Luz wrote:
> We have some new insights into the Serial Hub protocol, obtained through
> reverse engineering. In particular, regarding the command structure. The
> input/output target IDs actually represent source and target IDs of
> (what looks like) physical entities (specifically: host, SAM EC, KIP EC,
> debug connector, and SurfLink connector).
>
> This series aims to improve handling of messages with regards to those
> new findings and, mainly, improve clarity of the documentation and usage
> around those fields.
>
> See the discussion in
>
> https://github.com/linux-surface/surface-aggregator-module/issues/64
>
> for more details.
>
> There are a couple of standouts:
>
> - Patch 1 ensures that we only handle commands actually intended for us.
> It's possible that we receive messages not intended for us when we
> enable debugging. I've kept it intentionally minimal to simplify
> backporting. The rest of the series patch 9 focuses more on clarity
> and documentation, which is probably too much to backport.
>
> - Patch 8 touches on multiple subsystems. The intention is to enforce
> proper usage and documentation of target IDs in the SSAM_SDEV() /
> SSAM_VDEV() macros. As it directly touches those macros I
> unfortunately can't split it up by subsystem.
>
> - Patch 9 is a loosely connected cleanup for consistency.
>
> Hans, Jiri, Benjamin, Sebastian: While patch 8 ("platform/surface:
> aggregator: Enforce use of target-ID enum in device ID macros") touches
> multiple subsystems, it should be possible to take the whole series
> through the pdx86 tree. The changes in other subsystems are fairly
> limited.
Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans
Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.
Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.
Regards,
Hans
>
>
> Maximilian Luz (9):
> platform/surface: aggregator: Ignore command messages not intended for
> us
> platform/surface: aggregator: Improve documentation and handling of
> message target and source IDs
> platform/surface: aggregator: Add target and source IDs to command
> trace events
> platform/surface: aggregator_hub: Use target-ID enum instead of
> hard-coding values
> platform/surface: aggregator_tabletsw: Use target-ID enum instead of
> hard-coding values
> platform/surface: dtx: Use target-ID enum instead of hard-coding
> values
> HID: surface-hid: Use target-ID enum instead of hard-coding values
> platform/surface: aggregator: Enforce use of target-ID enum in device
> ID macros
> platform/surface: aggregator_registry: Fix target-ID of base-hub
>
> .../driver-api/surface_aggregator/client.rst | 4 +-
> .../driver-api/surface_aggregator/ssh.rst | 36 ++++-----
> drivers/hid/surface-hid/surface_hid.c | 2 +-
> drivers/hid/surface-hid/surface_kbd.c | 2 +-
> .../platform/surface/aggregator/controller.c | 12 +--
> .../platform/surface/aggregator/ssh_msgb.h | 4 +-
> .../surface/aggregator/ssh_request_layer.c | 15 ++++
> drivers/platform/surface/aggregator/trace.h | 73 +++++++++++++++++--
> .../platform/surface/surface_aggregator_hub.c | 8 +-
> .../surface/surface_aggregator_registry.c | 2 +-
> .../surface/surface_aggregator_tabletsw.c | 10 +--
> drivers/platform/surface/surface_dtx.c | 20 ++---
> .../surface/surface_platform_profile.c | 2 +-
> drivers/power/supply/surface_battery.c | 4 +-
> drivers/power/supply/surface_charger.c | 2 +-
> include/linux/surface_aggregator/controller.h | 4 +-
> include/linux/surface_aggregator/device.h | 50 ++++++-------
> include/linux/surface_aggregator/serial_hub.h | 40 ++++++----
> 18 files changed, 191 insertions(+), 99 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 0/8] Docs: Add missing SPDX license identifiers of
From: Jonathan Corbet @ 2023-01-23 15:02 UTC (permalink / raw)
To: SeongJae Park
Cc: SeongJae Park, Alex Deucher, Daniel Vetter, David Airlie,
David S. Miller, Dmitry Torokhov, Guenter Roeck, Herbert Xu,
Jaroslav Kysela, Jean Delvare, Maarten Lankhorst, Maxime Ripard,
Takashi Iwai, Thomas Zimmermann, Andrew Morton, linux-mm,
alsa-devel, dri-devel, linux-crypto, linux-doc, linux-hwmon,
linux-input, linux-kernel
In-Reply-To: <20230122213650.187710-1-sj@kernel.org>
SeongJae Park <sj@kernel.org> writes:
> Some subsystem documents are missing SPDX license identifiers on index
> files. This patchset adds those.
Documentation/ is far behind on the SPDX front, and I'm all in favor of
fixing that. I do worry, though, about sticking license declarations
onto files that did not previously have them; do we know what the
original contributor's intent was?
> Changes from v1
> (https://lore.kernel.org/lkml/20230114194741.115855-2-sj@kernel.org/)
> - Separate from index file content changes
> - Separate patch for each subsystem doc (Alex Deucher)
> - Use MIT license for gpu (Alex Deucher)
>
> SeongJae Park (8):
> Docs/crypto/index: Add missing SPDX License Identifier
> Docs/driver-api/index: Add missing SPDX License Identifier
> Docs/gpu/index: Add missing SPDX License Identifier
> Docs/hwmon/index: Add missing SPDX License Identifier
> Docs/input/index: Add missing SPDX License Identifier
> Docs/mm/index: Add missing SPDX License Identifier
> Docs/scheduler/index: Add missing SPDX License Identifier
> Docs/sound/index: Add missing SPDX License Identifier
>
> Documentation/crypto/index.rst | 2 ++
> Documentation/driver-api/index.rst | 2 ++
I added this one, and GPLv2 is fine there.
> Documentation/gpu/index.rst | 2 ++
> Documentation/hwmon/index.rst | 2 ++
> Documentation/input/index.rst | 2 ++
> Documentation/mm/index.rst | 2 ++
> Documentation/scheduler/index.rst | 2 ++
> Documentation/sound/index.rst | 2 ++
> 8 files changed, 16 insertions(+)
Thanks,
jon
^ permalink raw reply
* [PATCH v2 2/2] HID: uhid: Over-ride the default maximum data buffer value with our own
From: Lee Jones @ 2023-01-23 12:39 UTC (permalink / raw)
To: lee, jikos, benjamin.tissoires, avid.rheinsberg; +Cc: linux-kernel, linux-input
In-Reply-To: <20230123123912.360651-1-lee@kernel.org>
The default maximum data buffer size for this interface is UHID_DATA_MAX
(4k). When data buffers are being processed, ensure this value is used
when ensuring the sanity, rather than a value between the user provided
value and HID_MAX_BUFFER_SIZE (16k).
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/uhid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 2a918aeb0af13..59ac757c1d471 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -395,6 +395,7 @@ struct hid_ll_driver uhid_hid_driver = {
.parse = uhid_hid_parse,
.raw_request = uhid_hid_raw_request,
.output_report = uhid_hid_output_report,
+ .max_buffer_size = UHID_DATA_MAX,
};
EXPORT_SYMBOL_GPL(uhid_hid_driver);
--
2.39.0.246.g2a6d74b583-goog
^ permalink raw reply related
* [PATCH v2 1/2] HID: core: Provide new max_buffer_size attribute to over-ride the default
From: Lee Jones @ 2023-01-23 12:39 UTC (permalink / raw)
To: lee, jikos, benjamin.tissoires, avid.rheinsberg; +Cc: linux-kernel, linux-input
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 => v2:
- Edit the commit message to be less focused on UHID
drivers/hid/hid-core.c | 32 +++++++++++++++++++++++++-------
include/linux/hid.h | 3 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index bd47628da6be0..b10383ca8fc05 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -261,6 +261,7 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign
{
struct hid_report *report;
struct hid_field *field;
+ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE;
unsigned int usages;
unsigned int offset;
unsigned int i;
@@ -291,8 +292,11 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign
offset = report->size;
report->size += parser->global.report_size * parser->global.report_count;
+ if (parser->device->ll_driver->max_buffer_size)
+ max_buffer_size = parser->device->ll_driver->max_buffer_size;
+
/* Total size check: Allow for possible report index byte */
- if (report->size > (HID_MAX_BUFFER_SIZE - 1) << 3) {
+ if (report->size > (max_buffer_size - 1) << 3) {
hid_err(parser->device, "report is too long\n");
return -1;
}
@@ -1963,6 +1967,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
struct hid_report_enum *report_enum = hid->report_enum + type;
struct hid_report *report;
struct hid_driver *hdrv;
+ int max_buffer_size = HID_MAX_BUFFER_SIZE;
u32 rsize, csize = size;
u8 *cdata = data;
int ret = 0;
@@ -1978,10 +1983,13 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = hid_compute_report_size(report);
- if (report_enum->numbered && rsize >= HID_MAX_BUFFER_SIZE)
- rsize = HID_MAX_BUFFER_SIZE - 1;
- else if (rsize > HID_MAX_BUFFER_SIZE)
- rsize = HID_MAX_BUFFER_SIZE;
+ if (hid->ll_driver->max_buffer_size)
+ max_buffer_size = hid->ll_driver->max_buffer_size;
+
+ if (report_enum->numbered && rsize >= max_buffer_size)
+ rsize = max_buffer_size - 1;
+ else if (rsize > max_buffer_size)
+ rsize = max_buffer_size;
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
@@ -2384,7 +2392,12 @@ int hid_hw_raw_request(struct hid_device *hdev,
unsigned char reportnum, __u8 *buf,
size_t len, enum hid_report_type rtype, enum hid_class_request reqtype)
{
- if (len < 1 || len > HID_MAX_BUFFER_SIZE || !buf)
+ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE;
+
+ if (hdev->ll_driver->max_buffer_size)
+ max_buffer_size = hdev->ll_driver->max_buffer_size;
+
+ if (len < 1 || len > max_buffer_size || !buf)
return -EINVAL;
return hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
@@ -2403,7 +2416,12 @@ EXPORT_SYMBOL_GPL(hid_hw_raw_request);
*/
int hid_hw_output_report(struct hid_device *hdev, __u8 *buf, size_t len)
{
- if (len < 1 || len > HID_MAX_BUFFER_SIZE || !buf)
+ unsigned int max_buffer_size = HID_MAX_BUFFER_SIZE;
+
+ if (hdev->ll_driver->max_buffer_size)
+ max_buffer_size = hdev->ll_driver->max_buffer_size;
+
+ if (len < 1 || len > max_buffer_size || !buf)
return -EINVAL;
if (hdev->ll_driver->output_report)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 8677ae38599e4..f9b500b26f67c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -826,6 +826,7 @@ struct hid_driver {
* @output_report: send output report to device
* @idle: send idle request to device
* @may_wakeup: return if device may act as a wakeup source during system-suspend
+ * @max_buffer_size: over-ride maximum data buffer size (default: HID_MAX_BUFFER_SIZE)
*/
struct hid_ll_driver {
int (*start)(struct hid_device *hdev);
@@ -851,6 +852,8 @@ struct hid_ll_driver {
int (*idle)(struct hid_device *hdev, int report, int idle, int reqtype);
bool (*may_wakeup)(struct hid_device *hdev);
+
+ unsigned int max_buffer_size;
};
extern struct hid_ll_driver i2c_hid_ll_driver;
--
2.39.0.246.g2a6d74b583-goog
^ permalink raw reply related
* Re: [PATCH 1/3] Input: ads7846 - don't report pressure for ads7845
From: Andy Shevchenko @ 2023-01-23 12:25 UTC (permalink / raw)
To: Luca Ellero
Cc: Luca Ellero, dmitry.torokhov, daniel, m.felsch, u.kleine-koenig,
mkl, miquel.raynal, imre.deak, linux-input, linux-kernel
In-Reply-To: <74c917ce-a67c-7b4a-023b-2f2f4fb365b5@brickedbrain.com>
On Mon, Jan 23, 2023 at 09:27:37AM +0100, Luca Ellero wrote:
> On 20/01/2023 16:16, Andy Shevchenko wrote:
> > On Fri, Jan 20, 2023 at 01:45:42PM +0100, Luca Ellero wrote:
> > > ADS7845 doesn't support pressure.
> > > This patch avoids the following error reported by libinput-list-devices:
> >
> > s/This patch avoids/Avoid/
> >
> > (This rule is written in Submitting Patches documentation.)
> >
> > > "ADS7845 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE".
> >
> > Do you need a Fixes tag?
> >
>
> Hi Andy,
> thank you for your reply.
> I haven't found a specific bug report to apply to this patches.
> Could you kindly provide a "Fixes:" tag that I can apply?
The Fixes tag in accordance with the documentation should refer to the commit
in the Git history which brought the problem (regression).
> It's more like this driver has never been tested with ADS7845.
> Maybe the patches should be considered as a new implementation instead than
> a bug fix?
If it's indeed from day 1, then the initial commit can be considered as Fixes
tag, but I leave it to maintainer to decide.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] Input: ads7846 - don't report pressure for ads7845
From: Luca Ellero @ 2023-01-23 8:27 UTC (permalink / raw)
To: Andy Shevchenko, Luca Ellero
Cc: dmitry.torokhov, daniel, m.felsch, u.kleine-koenig, mkl,
miquel.raynal, imre.deak, linux-input, linux-kernel
In-Reply-To: <Y8qwQM2zLbboTeth@smile.fi.intel.com>
On 20/01/2023 16:16, Andy Shevchenko wrote:
> On Fri, Jan 20, 2023 at 01:45:42PM +0100, Luca Ellero wrote:
>> ADS7845 doesn't support pressure.
>> This patch avoids the following error reported by libinput-list-devices:
>
> s/This patch avoids/Avoid/
>
> (This rule is written in Submitting Patches documentation.)
>
>> "ADS7845 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE".
>
> Do you need a Fixes tag?
>
Hi Andy,
thank you for your reply.
I haven't found a specific bug report to apply to this patches.
Could you kindly provide a "Fixes:" tag that I can apply?
It's more like this driver has never been tested with ADS7845.
Maybe the patches should be considered as a new implementation instead
than a bug fix?
Thanks
Regards
Luca Ellero
--
Luca Ellero
E-mail: luca.ellero@brickedbrain.com
Internet: www.brickedbrain.com
^ permalink raw reply
* Re: [PATCH 1/1] HID: evision: Add preliminary support for EVision keyboards
From: Benjamin Tissoires @ 2023-01-23 7:57 UTC (permalink / raw)
To: Philippe Valembois; +Cc: Jiri Kosina, linux-kernel, linux-input
In-Reply-To: <20221224121814.11709-1-lephilousophe@gmail.com>
On Sat, Dec 24, 2022 at 1:23 PM Philippe Valembois
<lephilousophe@gmail.com> wrote:
>
> From: Philippe Valembois <lephilousophe@users.noreply.github.com>
Jiri, I have a doubt. Do we accept emails from users.noreply.github.com?
>
> For now only supports one model and only filters out bogus reports sent
> when the keyboard has been configured through hidraw.
> Without this, as events are not released, soft repeat floods userspace
> with unknown key events.
>
> Signed-off-by: Philippe Valembois <lephilousophe@users.noreply.github.com>
> ---
> drivers/hid/Kconfig | 7 ++++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-evision.c | 79 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 87 insertions(+)
> create mode 100644 drivers/hid/hid-evision.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index e2a5d30c8..1320ea75c 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -329,6 +329,13 @@ config HID_ELO
> Support for the ELO USB 4000/4500 touchscreens. Note that this is for
> different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
>
> +config HID_EVISION
> + tristate "EVision Keyboards Support"
> + depends on USB_HID
AFAICT, the driver only uses pure HID API, so you should be able to
depend on HID, not just USB_HID.
> + help
> + Support for some EVision keyboards. Note that this is needed only when
> + applying customization using userspace programs.
> +
> config HID_EZKEY
> tristate "Ezkey BTC 8193 keyboard"
> default !EXPERT
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index e8014c1a2..bd01571dd 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
> obj-$(CONFIG_HID_ELAN) += hid-elan.o
> obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
> obj-$(CONFIG_HID_ELO) += hid-elo.o
> +obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> diff --git a/drivers/hid/hid-evision.c b/drivers/hid/hid-evision.c
> new file mode 100644
> index 000000000..6ea331575
> --- /dev/null
> +++ b/drivers/hid/hid-evision.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * HID driver for EVision devices
> + * For now, only ignore bogus consumer reports
> + * sent after the keyboard has been configured
> + *
> + * Copyright (c) 2022 Philippe Valembois
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
Outside of hid_is_usb(), you are not using anything USB related, so
this can be dropped
> +
> +
> +#define USB_VENDOR_ID_EVISION 0x320f
> +#define USB_DEVICE_ID_EVISION_ICL01 0x5041
We tend to add those variables in drivers/hid/hid-ids.h
> +
> +static int evision_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> + struct hid_field *field, struct hid_usage *usage,
> + unsigned long **bit, int *max)
> +{
> + if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
> + return 0;
> +
> + // Ignore key down event
No C++ comments style please, use /* */ instead
> + if ((usage->hid & HID_USAGE) >> 8 == 0x05)
> + return -1;
> + // Ignore key up event
Same (and for any other // below).
> + if ((usage->hid & HID_USAGE) >> 8 == 0x06)
> + return -1;
> +
> + switch (usage->hid & HID_USAGE) {
> + // Ignore configuration saved event
> + case 0x0401: return -1;
> + // Ignore reset event
> + case 0x0402: return -1;
> + }
> + return 0;
> +}
> +
> +static int evision_probe(struct hid_device *hdev, const struct hid_device_id *id)
> +{
> + int ret;
> +
> + if (!hid_is_usb(hdev))
> + return -EINVAL;
This can be dropped...
> +
> + ret = hid_parse(hdev);
> + if (ret) {
> + hid_err(hdev, "EVision hid parse failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> + if (ret) {
> + hid_err(hdev, "EVision hw start failed: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
... which means the probe is the default one, meaning it can also be
dropped from the patch :)
> +}
> +
> +static const struct hid_device_id evision_devices[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_EVISION, USB_DEVICE_ID_EVISION_ICL01) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, evision_devices);
> +
> +static struct hid_driver evision_driver = {
> + .name = "evision",
> + .id_table = evision_devices,
> + .input_mapping = evision_input_mapping,
> + .probe = evision_probe,
Just for completeness, remove that .probe line and your driver will
behave the same and be smaller :)
> +};
> +module_hid_driver(evision_driver);
> +
> +MODULE_LICENSE("GPL");
> --
> 2.38.2
>
Cheers,
Benjamin
^ permalink raw reply
* [PATCH v2 5/8] Docs/input/index: Add missing SPDX License Identifier
From: SeongJae Park @ 2023-01-22 21:36 UTC (permalink / raw)
To: Jonathan Corbet
Cc: SeongJae Park, Dmitry Torokhov, linux-input, linux-doc,
linux-kernel
In-Reply-To: <20230122213650.187710-1-sj@kernel.org>
Add missing SPDX License Identifier for input documentation index file.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/input/index.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 35581cd18e91..d60bf9cfe005 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
===================
Input Documentation
===================
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/8] Docs: Add missing SPDX license identifiers of
From: SeongJae Park @ 2023-01-22 21:36 UTC (permalink / raw)
To: Jonathan Corbet
Cc: SeongJae Park, Alex Deucher, Daniel Vetter, David Airlie,
David S. Miller, Dmitry Torokhov, Guenter Roeck, Herbert Xu,
Jaroslav Kysela, Jean Delvare, Maarten Lankhorst, Maxime Ripard,
Takashi Iwai, Thomas Zimmermann, Andrew Morton, linux-mm,
alsa-devel, dri-devel, linux-crypto, linux-doc, linux-hwmon,
linux-input, linux-kernel
Some subsystem documents are missing SPDX license identifiers on index
files. This patchset adds those.
Changes from v1
(https://lore.kernel.org/lkml/20230114194741.115855-2-sj@kernel.org/)
- Separate from index file content changes
- Separate patch for each subsystem doc (Alex Deucher)
- Use MIT license for gpu (Alex Deucher)
SeongJae Park (8):
Docs/crypto/index: Add missing SPDX License Identifier
Docs/driver-api/index: Add missing SPDX License Identifier
Docs/gpu/index: Add missing SPDX License Identifier
Docs/hwmon/index: Add missing SPDX License Identifier
Docs/input/index: Add missing SPDX License Identifier
Docs/mm/index: Add missing SPDX License Identifier
Docs/scheduler/index: Add missing SPDX License Identifier
Docs/sound/index: Add missing SPDX License Identifier
Documentation/crypto/index.rst | 2 ++
Documentation/driver-api/index.rst | 2 ++
Documentation/gpu/index.rst | 2 ++
Documentation/hwmon/index.rst | 2 ++
Documentation/input/index.rst | 2 ++
Documentation/mm/index.rst | 2 ++
Documentation/scheduler/index.rst | 2 ++
Documentation/sound/index.rst | 2 ++
8 files changed, 16 insertions(+)
--
2.25.1
^ permalink raw reply
* Subject: unsubscribe
From: Tommi P. Laiho @ 2023-01-22 20:04 UTC (permalink / raw)
To: linux-input
Please unsubscribe the following email address from the Linux mailing list.
Email: tommi.p.laihol@gmail.com
^ permalink raw reply
* [PATCH v2 1/1] Docs/subsystem-apis: Remove '[The ]Linux' prefixes from titles of listed documents
From: SeongJae Park @ 2023-01-22 18:48 UTC (permalink / raw)
To: Jonathan Corbet
Cc: SeongJae Park, Andrew Morton, Bjorn Helgaas, Rafael J. Wysocki,
Viresh Kumar, Herbert Xu, David S. Miller, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Iwona Winiarska, Jaroslav Kysela, Takashi Iwai, Wim Van Sebroeck,
linux-pci, linux-doc, linux-kernel, linux-pm, linux-crypto,
linux-mm, dri-devel, linux-hwmon, linux-input, openbmc,
alsa-devel, linux-watchdog
Some documents that listed on subsystem-apis have 'Linux' or 'The Linux'
title prefixes. It's duplicated information, and makes finding the
document of interest with human eyes not easy. Remove the prefixes from
the titles.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Changes from v1
(https://lore.kernel.org/lkml/20230114194741.115855-1-sj@kernel.org/)
- Drop second patch (will post later for each subsystem)
Documentation/PCI/index.rst | 6 +++---
Documentation/cpu-freq/index.rst | 6 +++---
Documentation/crypto/index.rst | 6 +++---
Documentation/driver-api/index.rst | 6 +++---
Documentation/gpu/index.rst | 6 +++---
Documentation/hwmon/index.rst | 6 +++---
Documentation/input/index.rst | 6 +++---
Documentation/mm/index.rst | 6 +++---
Documentation/peci/index.rst | 6 +++---
Documentation/scheduler/index.rst | 6 +++---
Documentation/scsi/index.rst | 6 +++---
Documentation/sound/index.rst | 6 +++---
Documentation/virt/index.rst | 6 +++---
Documentation/watchdog/index.rst | 6 +++---
14 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
index c17c87af1968..e73f84aebde3 100644
--- a/Documentation/PCI/index.rst
+++ b/Documentation/PCI/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-=======================
-Linux PCI Bus Subsystem
-=======================
+=================
+PCI Bus Subsystem
+=================
.. toctree::
:maxdepth: 2
diff --git a/Documentation/cpu-freq/index.rst b/Documentation/cpu-freq/index.rst
index 2fe32dad562a..de25740651f7 100644
--- a/Documentation/cpu-freq/index.rst
+++ b/Documentation/cpu-freq/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-==============================================================================
-Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
-==============================================================================
+========================================================================
+CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
+========================================================================
Author: Dominik Brodowski <linux@brodo.de>
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 21338fa92642..da5d5ad2bdf3 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -1,6 +1,6 @@
-=======================
-Linux Kernel Crypto API
-=======================
+==========
+Crypto API
+==========
:Author: Stephan Mueller
:Author: Marek Vasut
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index d3a58f77328e..b208e0dac3a0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -1,6 +1,6 @@
-========================================
-The Linux driver implementer's API guide
-========================================
+==============================
+Driver implementer's API guide
+==============================
The kernel offers a wide variety of interfaces to support the development
of device drivers. This document is an only somewhat organized collection
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index b99dede9a5b1..eee5996acf2c 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -1,6 +1,6 @@
-==================================
-Linux GPU Driver Developer's Guide
-==================================
+============================
+GPU Driver Developer's Guide
+============================
.. toctree::
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fe2cc6b73634..c2b3c1a822dd 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -1,6 +1,6 @@
-=========================
-Linux Hardware Monitoring
-=========================
+===================
+Hardware Monitoring
+===================
.. toctree::
:maxdepth: 1
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 9888f5cbf6d5..35581cd18e91 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -1,6 +1,6 @@
-=============================
-The Linux Input Documentation
-=============================
+===================
+Input Documentation
+===================
Contents:
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 4aa12b8be278..5a94a921ea40 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -1,6 +1,6 @@
-=====================================
-Linux Memory Management Documentation
-=====================================
+===============================
+Memory Management Documentation
+===============================
Memory Management Guide
=======================
diff --git a/Documentation/peci/index.rst b/Documentation/peci/index.rst
index 989de10416e7..930e75217c33 100644
--- a/Documentation/peci/index.rst
+++ b/Documentation/peci/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0-only
-====================
-Linux PECI Subsystem
-====================
+==============
+PECI Subsystem
+==============
.. toctree::
diff --git a/Documentation/scheduler/index.rst b/Documentation/scheduler/index.rst
index b430d856056a..1aac972a652f 100644
--- a/Documentation/scheduler/index.rst
+++ b/Documentation/scheduler/index.rst
@@ -1,6 +1,6 @@
-===============
-Linux Scheduler
-===============
+=========
+Scheduler
+=========
.. toctree::
:maxdepth: 1
diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst
index 7c5f5f8f614e..919f3edfe1bf 100644
--- a/Documentation/scsi/index.rst
+++ b/Documentation/scsi/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-====================
-Linux SCSI Subsystem
-====================
+==============
+SCSI Subsystem
+==============
.. toctree::
:maxdepth: 1
diff --git a/Documentation/sound/index.rst b/Documentation/sound/index.rst
index 4d7d42acf6df..5abed5fc6485 100644
--- a/Documentation/sound/index.rst
+++ b/Documentation/sound/index.rst
@@ -1,6 +1,6 @@
-===================================
-Linux Sound Subsystem Documentation
-===================================
+=============================
+Sound Subsystem Documentation
+=============================
.. toctree::
:maxdepth: 2
diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst
index 56e003ff28ff..7fb55ae08598 100644
--- a/Documentation/virt/index.rst
+++ b/Documentation/virt/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-============================
-Linux Virtualization Support
-============================
+======================
+Virtualization Support
+======================
.. toctree::
:maxdepth: 2
diff --git a/Documentation/watchdog/index.rst b/Documentation/watchdog/index.rst
index c177645081d8..4603f2511f58 100644
--- a/Documentation/watchdog/index.rst
+++ b/Documentation/watchdog/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-======================
-Linux Watchdog Support
-======================
+================
+Watchdog Support
+================
.. toctree::
:maxdepth: 1
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH] HID: support the NACON / BigBen PS4 / PC Compact controller
From: Giuseppe Bilotta @ 2023-01-22 11:43 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Linux Input ML, Dmitry Torokhov, Jiri Kosina,
Roderick Colenbrander
In-Reply-To: <CAEc3jaBwTHiC5_JBdYm1eO-zdingohQsbndGEPWnTbRSW_tzmw@mail.gmail.com>
Hello Roderick,
I'm terribly sorry for the late reply, it's a bit of a busy period for
me and I have had less time than I wished to test things.
> Thanks for your work so far. My first thought was 'yikes what an ugly
> device'. I'm not really sure what the best way of handling it is.
The patch is beyond ugly (in addition to not working). But I'm barely
treading water here, I'm way out of my element, hence why I came to
the ML looking for help 8-)
> First is the device a HID device? It would normally be picked up by
> hid-generic. You can try dumping the HID descriptors.
I'm afraid this is not the case, at least as far as I can tell. Again,
keep in mind I'm not even exactly sure how to check these things out,
so please bear with me, and feel free to direct me to appropriate
resources.
What I have tried is to first plug the pad in with xpad blacklisted,
and lsusb -vs the device, which gave me:
--8<-----------------
Bus 001 Device 006: ID 146b:0603 BigBen Interactive PC Compact Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x146b BigBen Interactive
idProduct 0x0603
bcdDevice 1.00
iManufacturer 1 Bigben Interactive
iProduct 2 PC Compact Controller
iSerial 3 58B00422
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0031
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 11 21 00 01 01 25 81 14 00 00 00 00 13 02 08 03 03
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
Device Status: 0x0000
(Bus Powered)
--8<-----------------
I also tried running usbhid-dump, that claimed there were “No matching
HID interfaces”.
If I enable the xpad module shipping with my Debian sid distribution
(6.0.12-1 from 2022-12-09), there's no difference on the lsusb and
usbhid-dump outputs,
even though xpad seems to detect and bind with the device:
--8<-----------------
[Jan23 05:33] usb 1-1: new full-speed USB device number 7 using xhci_hcd
[ +0.149801] usb 1-1: New USB device found, idVendor=146b,
idProduct=0603, bcdDevice= 1.00
[ +0.000017] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000008] usb 1-1: Product: PC Compact Controller
[ +0.000006] usb 1-1: Manufacturer: Bigben Interactive
[ +0.000006] usb 1-1: SerialNumber: 58B00422
[ +0.068217] input: Generic X-Box pad as
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input35
[ +0.000114] usbcore: registered new interface driver xpad
--8<-----------------
Is there some other tool I can use to inspect the HID descriptors or
check which protocols are supported, possibly depending on the device
initialization?
(I have other gamepads whose behavior seems to depend on
initialization sequence, so this may be the case for this device too?)
> It is a bit ugly if the device has to spawn multiple drivers. My
> initial gut feeling would have been to complete the support within the
> xpad driver. My understanding of our licensed controllers is that the
> HID protocol they use is different from the DS4 protocol, so it is
> really like handling an entire new device needing its own HID report
> parsing. So, no matter what each driver would have needed some changes
> to deal with the device properly and it is probably smallest in xpad.
I don't have enough knowledge to know exactly what would be better,
but I would expect the protocol to be closer to the PS one than the
XBOX one,
even though out of the box it kind of works with xpad (modulo the
issues I mentioned).
I also have no idea how similar or different the PS and XBOX protocols
are, so it might just be that for the limited use and testing I've
done they match.
> You mention access flipping and then the touchpad.
Axes mapping is weird, but I think my original issue was actually with
jstest-gtk not using the correct information. The CLI jstest seems to
report things correctly.
The “touchpad” is a rectangular area above the joysticks and between
the DPAD and the box/triangle/x/o buttons. I'm not entirely surely if
it's a touchpad or something else,
but it seems to be clickable “everywhere”. It's not detected or
exposed by the xpad driver in any way, but assume it would be
accessible in the protocol.
There's also something that looks like an audio jack.
I can run tests on this thing, but I really don't know what to try next.
Thank you for your reply, and looking forward for things to try,
Giuseppe Bilotta
>
> Thanks,
> Roderick
>
> On Fri, Dec 23, 2022 at 9:25 AM Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
> >
> > ---
> >
> > I have recently come into possession of a NACON / Big Ben Interactive
> > USB wired PC Compact controller (USB vendor:device 146b:0603).
> > This is advertised as an «officially licensed PS4™ wired controller»
> > that «also boasts full compatibility with PC games».
> >
> > It is supposed to be similar to a DualShock 4 controller except for the
> > lack of built-in speaker, light bar and “SIXAXIS” motion sensor.
> > In particular, in addition to the typical gamepad goodies, it has a
> > built-in touchpad and an audio jack.
> >
> > As things are currently, the Linux kernel automatically matches it with
> > the xpad driver, that detects this as a “Generic X-Box controller”.
> > This kind of works, but in addition to minor issues such as the default
> > axis mapping being wrong (which could be fixed in the xpad driver),
> > the major downside for the xpad driver binding to the controller
> > is that it fails to expose the touchpad and the audio jack.
> >
> > My hope was to let the xpad driver skip this device, and to manage it
> > through the hid subsystem, expecting the hid-sony and/or hid-playstation
> > drivers to be able to manage it.
> >
> > However, I obviously don't understand enough about how the hid driver
> > manages the bindings, and so far I've been at a loss about making this
> > work. The hack to ignore the device in xpad works, although it's a
> > horrible hack that probably shouldn't be needed in the first place,
> > but the HID subsystem doesn't seem to pick up the device.
> > This patch is my very poor (and currently NOT WORKING) attempt,
> > and since I'm obviously going at this all wrong, I'd be glad for
> > any recommendations on how to approach this.
> >
> > Cheers,
> >
> > Giuseppe Bilotta
> >
> >
> > drivers/hid/hid-ids.h | 1 +
> > drivers/hid/hid-playstation.c | 5 ++++-
> > drivers/hid/hid-quirks.c | 1 +
> > drivers/hid/hid-sony.c | 3 +++
> > drivers/input/joystick/xpad.c | 5 +++++
> > 5 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 82713ef3aaa6..78d993415071 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -250,6 +250,7 @@
> > #define USB_VENDOR_ID_BETOP_2185V2BFM 0x20bc
> >
> > #define USB_VENDOR_ID_BIGBEN 0x146b
> > +#define USB_DEVICE_ID_BIGBEN_PC_COMPACT_CONTROLLER 0x0603
> > #define USB_DEVICE_ID_BIGBEN_PS3OFMINIPAD 0x0902
> >
> > #define USB_VENDOR_ID_BTC 0x046e
> > diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
> > index f399bf0d3c8c..8302394479bd 100644
> > --- a/drivers/hid/hid-playstation.c
> > +++ b/drivers/hid/hid-playstation.c
> > @@ -2589,7 +2589,8 @@ static int ps_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > goto err_stop;
> > }
> >
> > - if (hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER ||
> > + if (hdev->product == USB_DEVICE_ID_BIGBEN_PC_COMPACT_CONTROLLER ||
> > + hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER ||
> > hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER_2 ||
> > hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE) {
> > dev = dualshock4_create(hdev);
> > @@ -2632,6 +2633,8 @@ static void ps_remove(struct hid_device *hdev)
> > }
> >
> > static const struct hid_device_id ps_devices[] = {
> > + /* NACON / BigBen Interact Wired PC Compact controller */
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_BIGBEN, USB_DEVICE_ID_BIGBEN_PC_COMPACT_CONTROLLER) },
> > /* Sony DualShock 4 controllers for PS4 */
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
> > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> > index 0e9702c7f7d6..fa9503257621 100644
> > --- a/drivers/hid/hid-quirks.c
> > +++ b/drivers/hid/hid-quirks.c
> > @@ -639,6 +639,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
> > { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SUPER_JOY_BOX_5_PRO) },
> > #endif
> > #if IS_ENABLED(CONFIG_HID_SONY)
> > + { HID_USB_DEVICE(USB_VENDOR_ID_BIGBEN, USB_DEVICE_ID_BIGBEN_PC_COMPACT_CONTROLLER) },
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_HARMONY_PS3) },
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_PS3_BDREMOTE) },
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_NSG_MR5U_REMOTE) },
> > diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> > index 13125997ab5e..4f5d5643dd19 100644
> > --- a/drivers/hid/hid-sony.c
> > +++ b/drivers/hid/hid-sony.c
> > @@ -3180,6 +3180,9 @@ static const struct hid_device_id sony_devices[] = {
> > /* SMK-Link PS3 BD Remote Control */
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, USB_DEVICE_ID_SMK_PS3_BDREMOTE),
> > .driver_data = PS3REMOTE },
> > + /* NACON / BigBen Interact Wired PC Compact controller */
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_BIGBEN, USB_DEVICE_ID_BIGBEN_PC_COMPACT_CONTROLLER),
> > + .driver_data = DUALSHOCK4_CONTROLLER_USB },
> > /* Sony Dualshock 4 controllers for PS4 */
> > { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER),
> > .driver_data = DUALSHOCK4_CONTROLLER_USB },
> > diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> > index 2959d80f7fdb..d3d3ce84bd6c 100644
> > --- a/drivers/input/joystick/xpad.c
> > +++ b/drivers/input/joystick/xpad.c
> > @@ -92,6 +92,7 @@
> > #define XTYPE_XBOX360W 2
> > #define XTYPE_XBOXONE 3
> > #define XTYPE_UNKNOWN 4
> > +#define XTYPE_NOTXBOX 0xff
> >
> > /* Send power-off packet to xpad360w after holding the mode button for this many
> > * seconds
> > @@ -281,6 +282,7 @@ static const struct xpad_device {
> > { 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
> > { 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
> > { 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 },
> > + { 0x146b, 0x0603, "BigBen Interactive PC Compact Controller", 0, XTYPE_NOTXBOX },
> > { 0x146b, 0x0604, "Bigben Interactive DAIJA Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
> > { 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
> > { 0x1532, 0x0a00, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
> > @@ -1951,6 +1953,9 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
> > break;
> > }
> >
> > + if (xpad_device[i].xtype == XTYPE_NOTXBOX)
> > + return -ENODEV;
> > +
> > xpad = kzalloc(sizeof(struct usb_xpad), GFP_KERNEL);
> > if (!xpad)
> > return -ENOMEM;
> > --
> > 2.39.0
> >
--
Giuseppe "Oblomov" Bilotta
^ 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