This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Remove extern declaration of bpf_wq_set_callback_impl() from
hid_bpf_helpers.h and replace bpf_wq_set_callback macro with a
corresponding new declaration.
Tested with:
# append tools/testing/selftests/hid/config and build the kernel
$ make -C tools/testing/selftests/hid
# in built kernel
$ ./tools/testing/selftests/hid/hid_bpf -t test_multiply_events_wq
TAP version 13
1..1
# Starting 1 tests from 1 test cases.
# RUN hid_bpf.test_multiply_events_wq ...
[ 2.575520] hid-generic 0003:0001:0A36.0001: hidraw0: USB HID v0.00 Device [test-uhid-device-138] on 138
# OK hid_bpf.test_multiply_events_wq
ok 1 hid_bpf.test_multiply_events_wq
# PASSED: 1 / 1 tests passed.
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
PASS
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://lore.kernel.org/r/20260120222638.3976562-9-ihor.solodrai@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Cross-merge BPF and other fixes after downstream PR.
No conflicts.
Adjacent:
Auto-merging MAINTAINERS
Auto-merging Makefile
Auto-merging kernel/bpf/verifier.c
Auto-merging kernel/sched/ext.c
Auto-merging mm/memcontrol.c
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Similar to commit 835a507535 ("selftests/bpf: Add -fms-extensions to
bpf build flags") and commit 639f58a0f4 ("bpftool: Fix build warnings
due to MS extensions")
The kernel is now built with -fms-extensions, therefore
generated vmlinux.h contains types like:
struct slab {
..
struct freelist_counters;
};
Use -fms-extensions and -Wno-microsoft-anon-tag flags
to build bpf programs that #include "vmlinux.h"
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
As KF_TRUSTED_ARGS is now considered default for all kfuns, the verifier
will not allow passing NULL pointers to these kfuns. These checks for
NULL pointers can therefore be removed.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Link: https://lore.kernel.org/r/20260102180038.2708325-6-puranjay@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
We could go to the USB consortium, but it's probably
easier that way.
And update HID usage table json generated file from
https://usb.org/sites/default/files/hut1_6.pdf updated: 01/30/2025
Reported-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/191
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Same issues with a secondary tip switch instead of secondary barrel
switch as the Kamvas 19.
Copy the stable Kamvas 19 support back into testing and add the vid/pid
for the Kamvas 27.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/189
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When pressing the phsyical eraser button (remapped by us to the
Secondary Barrel Switch) while the tip is down, the device
gives us several false reports with a Tip Switch 0:
press| |release
SBS: [0 0 ... 1 1 1 ... 1 0 0 0 0 0 0 ...]
TS: [1 1 ... 1 0 1 ... 1 1 0 0 0 1 1 ...]
In both press/release the number of Tip Switch 0 reports can be up to 4
and *sometimes* the Tip Switch is released in the same report
as the button press/release event.
Paper over this by forcing the tip down for a few reports if it was down
before the button toggled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/195
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Modifies report to have tablet buttons report as buttons, rather than as
keyboard key combinations. The dial is also converted to a relative
input, using the dedicated bit previously reserved for modifier key
information.
Signed-off-by: Hannah Pittman <dev@hannahl.co.uk>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/203
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This device needs a fix for the tilt range on the pen report descriptor
and the usual conversion of the pad keys from the firmware's hardcoded
keyboard shortcuts to actual pad buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/185
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Several bugs as outlined in udev-hid-bpf#66 and udev-hid-bpf!198:
- pressure curve is far from linear
- tilt range is ±60, not ±127
- pressing the second button sets both tip down and
barrel switch
Fix the second button by adding a Secondary Barrel Switch in the
existing padding and check for the tip down/barrel switch down combo.
When both values become true at the same time, set the Secondary Barrel
Switch instead.
Implement a custom pressure curve that maps the hardware range 0-102
linearly to the logical range 0-1224, and maps the hardware range
103-2047 logarithmically to the logical range 1232-2047. This mapping
isn’t perfect, but it’s way more natural than the stock configuration.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jan Felix Langenbach <JanFelix.Langenbach@protonmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/200
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The 3Dconnexion SpaceNavigator HID report descriptor declares its axis
data to be "relative" when it is actually "absolute". This quirk was
addressed in the kernel in 2.6.33, but some SpaceNavigator variants have
a slightly different report descriptor whose axis input items are at
different offsets than those assumed by the kernel fixup.
Add a BPF fixup to handle both sets of offsets for known SpaceNavigator
variants if the descriptor has not already been fixed by the kernel.
Signed-off-by: Curran Muhlberger <curran@cs.cornell.edu>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/181
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Another Huion Kamvas tablet support.
Again it's safer to duplicate the code source in a separate file to
ensure we are not breaking any existing device.
Signed-off-by: Higgins Dragon <higgins@higginsdragon.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/207
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
This assumes that the tablet has been switched into vendor mode (by
using huion-switcher[1], for example) and is sending events using
Huion's proprietary data format.
This has been tested using the PW600L pen, which does not have an
eraser. There is no expectation that a pen with an eraser will work at
this time.
[1] https://github.com/whot/huion-switcher
Signed-off-by: Nicholas LaPointe <nicholaslapointe8@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/162
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
There are a differences in the report descriptor to the existing
Inspiroy 2S which makes having this as separate file a more efficient
approach than merging them together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/167
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The current HID bpf implementation assumes no output report/request will
go through it after hid_bpf_destroy_device() has been called. This leads
to a bug that unplugging certain types of HID devices causes a cleaned-
up SRCU to be accessed. The bug was previously a hidden failure until a
recent x86 percpu change [1] made it access not-present pages.
The bug will be triggered if the conditions below are met:
A) a device under the driver has some LEDs on
B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver)
If condition A is met, hidinput_led_worker() is always scheduled *after*
hid_bpf_destroy_device().
hid_destroy_device
` hid_bpf_destroy_device
` cleanup_srcu_struct(&hdev->bpf.srcu)
` hid_remove_device
` ...
` led_classdev_unregister
` led_trigger_set(led_cdev, NULL)
` led_set_brightness(led_cdev, LED_OFF)
` ...
` input_inject_event
` input_event_dispose
` hidinput_input_event
` schedule_work(&hid->led_work) [hidinput_led_worker]
This is fine when condition B is not met, where hidinput_led_worker()
calls hid_ll_driver->request(). This is the case for most HID drivers,
which implement it or use the generic one from usbhid. The driver itself
or an underlying driver will then abort processing the request.
Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads
to the bug.
hidinput_led_worker
` hid_hw_output_report
` dispatch_hid_bpf_output_report
` srcu_read_lock(&hdev->bpf.srcu)
` srcu_read_unlock(&hdev->bpf.srcu, idx)
The bug has existed since the introduction [2] of
dispatch_hid_bpf_output_report(). However, the same bug also exists in
dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect
because of the lack of [1], but confirmed bpf.destroyed == 1) the bug
against the commit (i.e., the Fixes:) introducing the function. This is
because hidinput_led_worker() falls back to hid_hw_raw_request() when
hid_ll_driver->output_report() is uninplemented (e.g., logitech-
djreceiver).
hidinput_led_worker
` hid_hw_output_report: -ENOSYS
` hid_hw_raw_request
` dispatch_hid_bpf_raw_requests
` srcu_read_lock(&hdev->bpf.srcu)
` srcu_read_unlock(&hdev->bpf.srcu, idx)
Fix the issue by returning early in the two mentioned functions if
hid_bpf has been marked as destroyed. Though
dispatch_hid_bpf_device_event() handles input events, and there is no
evidence that it may be called after the destruction, the same check, as
a safety net, is also added to it to maintain the consistency among all
dispatch functions.
The impact of the bug on other architectures is unclear. Even if it acts
as a hidden failure, this is still dangerous because it corrupts
whatever is on the address calculated by SRCU. Thus, CC'ing the stable
list.
[1]: commit 9d7de2aa8b ("x86/percpu/64: Use relative percpu offsets")
[2]: commit 9286675a2a ("HID: bpf: add HID-BPF hooks for
hid_hw_output_report")
Closes: https://lore.kernel.org/all/20250506145548.GGaBoi9Jzp3aeJizTR@fat_crate.local/
Fixes: 8bd0488b5e ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests")
Cc: stable@vger.kernel.org
Signed-off-by: Rong Zhang <i@rong.moe>
Tested-by: Petr Tesarik <petr@tesarici.cz>
Link: https://patch.msgid.link/20250512152420.87441-1-i@rong.moe
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
With v6.11+, we can actually call hid_hw_output_report() and put the device
into raw mode, thus getting accurate events without being messed up.
Technically we could do the same on v6.10, but given that wayland, gnome
and KDE are still not capable of handling the dial, and that v6.10 is EOL,
we can safely save a little bit of compilation by only allowing v6.11+.
We can easily export the battery information to userspace by adding a
dedicated report. However, we need to cheat on the kernel to force it
not to query the battery by making the physical collection a stylus. The
kernel will then only rely on the events it gets from the device.
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/133
Acked-by: Jiri Kosina <jkosina@suse.com>
Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-7-6048fdd5a206@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
The purpose is to simplify the use of bpf_wq to defer blocking
operations in a sleepable context. Compared to a more "classic"
async approach, there is no sync mechanism to wait for the async
to finish.
The "simple" API is the following:
```
static int HID_BPF_ASYNC(async_fun)(struct hid_bpf_ctx *hctx)
{
bpf_printk("%s", __fun__);
return 0;
}
SEC("syscall")
int probe(struct hid_bpf_probe_args *ctx)
{
ctx->retval = HID_BPF_ASYNC_INIT(async_fun);
return 0;
}
SEC(HID_BPF_DEVICE_EVENT)
int BPF_PROG(event_handler, struct hid_bpf_ctx *hctx)
{
/* async_fun() can be called now, it's not a sleepable
* function in this example
*/
async_fun(hctx);
/* but we can also delay the call by 10 ms */
HID_BPF_ASYNC_DELAYED_CALL(async_fun, hctx, 10);
return 0;
}
HID_BPF_OPS(xppen_ack05_remote) = {
.hid_device_event = (void *)event_handler,
};
```
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/133
Acked-by: Jiri Kosina <jkosina@suse.com>
Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-6-6048fdd5a206@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
The TUXEDO Sirius 16 Gen1 and the TUXEDO Sirius 16 Gen2 Notebooks have an
additional "fan" key next to F12.
Pressing it alone sends a F14 key press which can be bound by user space.
Pressing it while holding the FN key triggers two things:
- The EC firmware locks the fan speed of the internal fans at 100%
- F13 key press is registered which by default is already bound in xkb and
desktop environments (e.g. in KDE Plasma it launches system settings)
To avoid this unexpected double duty of the FN shortcut, this bpf program
suppresses the F13 key press.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/166
Acked-by: Jiri Kosina <jkosina@suse.com>
Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-2-6048fdd5a206@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
This re-uses the same HID report descriptor that we also use for
the tablet mode after switching the device. The keys send uniquely
identifyable shortcuts so we can map those to buttons.
However the dial and the button inside the dial send events on a
different hidraw node and they are unreliable (e.g. the button does not
get released reliably). So they're ignored in this patch, it's not
worth the effort getting those to work correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/158
Acked-by: Jiri Kosina <jkosina@suse.com>
Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-1-6048fdd5a206@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
In commit 33c0fb85b5 ("HID: bpf: make part of struct hid_device writable")
the const qualifier was dropped from struct hid_bpf_ctx::hid.
The casts are now unnecessary.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20241127-hid-bpf-cast-v1-1-f26424960e84@weissschuh.net
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
This reverts commit 6fd47effe9, and the related self-test update
commit e14e0eaeb0 ("selftests/hid: add test for assigning a given
device to hid-generic").
It results in things like the scroll wheel on Logitech mice not working
after a reboot due to the kernel being confused about the state of the
high-resolution mode.
Quoting Benjamin Tissoires:
"The idea of 6fd47effe9 was to be able to call hid_bpf_rdesc_fixup()
once per reprobe of the device.
However, because the bpf filter can now change the quirk value, the
call had to be moved before the driver gets bound (which was
previously ensuring the unicity of the call).
The net effect is that now, in the case hid-generic gets loaded first
and then the specific driver gets loaded once the disk is available,
the value of ->quirks is not reset, but kept to the value that was set
by hid-generic (HID_QUIRK_INPUT_PER_APP).
Once hid-logitech-hidpp kicks in, that quirk is now set, which creates
two inputs for the single mouse: one keyboard for fancy shortcuts, and
one mouse node.
However, hid-logitech-hidpp expects only one input node to be attached
(it stores it into hidpp->input), and when a wheel event is received,
because there is some processing with high-resolution wheel events,
the wheel event is injected into hidpp->input.
And of course, when HID_QUIRK_INPUT_PER_APP is set, hidpp->input gets
the keyboard node, which doesn't have wheel event type, and the events
are ignored"
Reported-and-bisected-by: Mike Galbraith <efault@gmx.de>
Link: https://lore.kernel.org/all/CAHk-=wiUkQM3uheit2cNM0Y0OOY5qqspJgC8LkmOkJ2p2LDxcw@mail.gmail.com/
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Replace with individual Minimum/Maximum calls to match the HID report
descriptor - HID doesn't have a Range field. Abstracting this is good
for hand-written descriptors but almost all tools will output min/max
instead so let's stick with that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jiri Kosina <jkosina@suse.com>
Link: https://patch.msgid.link/20241017-import_bpf_6-13-v2-3-6a7acb89a97f@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
This allows to give more control from BPF during report descriptor fixup.
We already reset the quirks before calling ->probe(), so now we reset
it once before calling hid_bpf_rdesc_fixup().
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-4-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
With the introduction of commit e42ac14180 ("bpf: Check unsupported ops
from the bpf_struct_ops's cfi_stubs"), a HID-BPF struct_ops containing
a .hid_hw_request() or a .hid_hw_output_report() was failing to load
as the cfi stubs were not defined.
Fix that by defining those simple static functions and restore HID-BPF
functionality.
This was detected with the HID selftests suddenly failing on Linus' tree.
Cc: stable@vger.kernel.org # v6.11+
Fixes: 9286675a2a ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")
Fixes: 8bd0488b5e ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests")
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The parameter is never modified, so mark it as const.
Also inline the return statement to avoid a type mismatch error.
This is a prerequisite for constification changes in the HID core.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20240803-hid-const-fixup-v2-1-f53d7a7b29d8@weissschuh.net
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
The module does not do anything when the JIT is disabled, but instead
causes a warning:
In file included from include/linux/bpf_verifier.h:7,
from drivers/hid/bpf/hid_bpf_struct_ops.c:10:
drivers/hid/bpf/hid_bpf_struct_ops.c: In function 'hid_bpf_struct_ops_init':
include/linux/bpf.h:1853:50: error: statement with no effect [-Werror=unused-value]
1853 | #define register_bpf_struct_ops(st_ops, type) ({ (void *)(st_ops); 0; })
| ^~~~~~~~~~~~~~~~
drivers/hid/bpf/hid_bpf_struct_ops.c:305:16: note: in expansion of macro 'register_bpf_struct_ops'
305 | return register_bpf_struct_ops(&bpf_hid_bpf_ops, hid_bpf_ops);
| ^~~~~~~~~~~~~~~~~~~~~~~
Add a Kconfig dependency to only allow building the HID-BPF support
when a JIT is enabled.
Fixes: ebc0d8093e ("HID: bpf: implement HID-BPF through bpf_struct_ops")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/96a00b6f-eb81-4c67-8c4b-6b1f3f045034@app.fastmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEoEVH9lhNrxiMPSyI7MXwXhnZSjYFAmaWVnITHGJlbnRpc3NA
a2VybmVsLm9yZwAKCRDsxfBeGdlKNvC2D/0ZkIRcJn8OU3j8vbSE2D10hy3tyDZa
3P5rI2UrlE6NPlJUo755VBEaLe608481TNZlhIKQ6LFzmUdlj3C7bKiCOQ6KLOyT
ZoCeRS3cVgNfSEnF5N6SwfuVW3PgXo6GC6pueNcNepLIVnWGJ5QhLmiLOzPr0YER
mW/y3s447TxecQ803UYtaFQnwSOhxzWvN+G7mnzkz2PNpta3UJ68jsqxQOivrSV0
mEx4W5VN6MYaSVZ2c5s+LIcn48+LMGNwkRAdMkFUAksLDNwvSIgdgRcjaJhpVIPK
MfYrQ9QAXezFxzUxbEoCI5PXOA44MODhT3095fyq+Uf3r2OB/gGKE8p3f2jv24nv
RR/TR5S4y8FD+bWh12/BL8j4bv0weXFFUjwJwZmmpXnL3ev0oN92TaRrKRPuNO4Y
GDmRV5qwUZrL2+e7j0bpXFGxulsxc+1JYxb8UY03BHIB2M8LnUTpsfpcxtSi1MYW
N1U//fObXBfRl1CcdDPbT2cTJD9jwuozJm5l1p/BHOHu3cwhJTStH1XzsnKQXL9g
O5izXWqwCgNmbG8egGR3ddV53ZGi1MsD7tGcc5GGcYnevdBi4l+Q4Zl+oFxjfHvs
MKWMKygdaHUBqmYfOGgspA+S2zY38smbul8ZQUxP0yOl3+MyqCCedYQHi/w8MU+L
k2w+NzXIWXBifA==
=hVVT
-----END PGP SIGNATURE-----
Merge tag 'for-linus-2024071601' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID updates from Benjamin Tissoires:
- rewrite of the HID-BPF internal implementation to use bpf struct_ops
instead of a tracing endpoint (Benjamin Tissoires)
- add two new HID-BPF hooks to be able to intercept userspace calls
targeting a HID device and filtering them (Benjamin Tissoires)
- add support for various new devices through HID-BPF filters (Benjamin
Tissoires)
- add support for the magic keyboard backlight (Orlando Chamberlain)
- add the missing MODULE_DESCRIPTION() macros in HID drivers (Jeff
Johnson)
- use of kvzalloc in case memory gets too fragmented (Hailong Liu)
- retrieve the device firmware node in the child HID device (Danny
Kaehn)
- some hid-uclogic improvements (José Expósito)
- some more typos, trivial fixes, kernel doctext and unused functions
cleanups
* tag 'for-linus-2024071601' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (60 commits)
HID: hid-steam: Fix typo in goto label
HID: mcp2221: Remove unnecessary semicolon
HID: Fix spelling mistakes "Kensigton" -> "Kensington"
HID: add more missing MODULE_DESCRIPTION() macros
HID: samples: fix the 2 struct_ops definitions
HID: fix for amples in for-6.11/bpf
HID: apple: Add support for magic keyboard backlight on T2 Macs
HID: bpf: Thrustmaster TCA Yoke Boeing joystick fix
HID: bpf: Add Huion Dial 2 bpf fixup
HID: bpf: Add support for the XP-PEN Deco Mini 4
HID: bpf: move the BIT() macro to hid_bpf_helpers.h
HID: bpf: add a driver for the Huion Inspiroy 2S (H641P)
HID: bpf: Add a HID report composition helper macros
HID: bpf: doc fixes for hid_hw_request() hooks
HID: bpf: doc fixes for hid_hw_request() hooks
HID: bpf: fix gcc warning and unify __u64 into u64
selftests/hid: ensure CKI can compile our new tests on old kernels
selftests/hid: add an infinite loop test for hid_bpf_try_input_report
selftests/hid: add another test for injecting an event from an event hook
HID: bpf: allow hid_device_event hooks to inject input reports on self
...
This is a a driver for the Huion Inspiroy 2S in both modes (firmware mode
and tablet mode). This device has 6 buttons and a wheel, all of which
send key combinations (see the comments for the defaults). Luckily the
device is quite limited in that it only supports one button down at a
time, so with this BPF we can simply remap the 8 possible report IDs to
our own custom-built report descriptor.
If the device is in tablet mode (e.g. using huion-switcher it sends
everything through the vendor report instead). This BPF program converts
both, depending which devices you attach to you get both. Or if you
attach to all hid devices you get a duplicate device but it'll work
either way.
This BPF should be mostly compatible for the M and L as well though they
have more buttons so the rdescs will need some minor rework.
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/85
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/109
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20240627-import-bpf-v1-2-0dbcda4a5b1f@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
These macros make it slightly easier and more modular to create
a HID report descriptor from scratch. Since they carry the annotation
we don't need to comment it and they cannot get stale.
For comparison, before we had this:
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x95, 0x04, // Report Count (4)
0x75, 0x01, // Report Size (1)
Now we can write this as:
LogicalRange_i8(0, 1)
ReportCount(4)
ReportSize(1)
Because these macros are for creating new report descriptors,
some bits aren't directly exposed. e.g in the example above:
there is a logical range as one macro that sets both min and max.
There is seldom a good use case for skipping either anyway.
These macros will need to be expanded over time.
For Usage Pages and Usage IDs, we use a tool to parse the HUT JSON
(attached to the HUT 1.5 PDF [1]) and generate all #defines for all
usage pages and usages in the form:
#define UsagePage_Foo_Bar
#define Usage_FB_SomeOrOther
Where the FB is simply the acronym based on the capital letters in the
Usage Page name or the first three letters, whichever makes slightly
more sense.
[1] https://usb.org/document-library/hid-usage-tables-15
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/92
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/96
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20240627-import-bpf-v1-1-0dbcda4a5b1f@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
We had the following errors while doing make htmldocs:
Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:167:
ERROR: Unexpected indentation.
Also ensure consistency with the rest of the __u64 vs u64.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 9286675a2a ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")
Link: https://patch.msgid.link/20240701-fix-cki-v2-4-20564e2e1393@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
This is the same logic than hid_hw_raw_request or hid_hw_output_report:
we can allow hid_bpf_try_input_report to be called from a hook on
hid_input_report if we ensure that the call can not be made twice in a
row.
There is one extra subtlety in which there is a lock in hid_input_report.
But given that we can detect if we are already in the hook, we can notify
hid_input_report to not take the lock. This is done by checking if
ctx_kern data is valid or null, and if it is equal to the dedicated
incoming data buffer.
In order to have more control on whether the lock needs to be taken or not
we introduce a new kfunc for it: hid_bpf_try_input_report()
Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-11-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
hid_bpf_input_report() is already marked to be used in sleepable context
only. So instead of hammering with timers the device to hopefully get
an available slot where the device is not sending events, we can make
that kfunc wait for the current event to be terminated before it goes in.
This allows to work with the following pseudo code:
in struct_ops/hid_device_event:
- schedule a bpf_wq, which calls hid_bpf_input_report()
- once this struct_ops function terminates, hid_bpf_input_report()
immediately starts before the next event
Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-9-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
We add 3 new tests:
- first, we make sure we can prevent the output_report to happen
- second, we make sure that we can detect that a given hidraw client
was actually doing the request, and for that client only, call ourself
hid_bpf_hw_output_report(), returning a custom value
- last, we ensure that we can not loop between hooks for
hid_hw_output_report() and manual calls to hid_bpf_hw_output_report()
from that same hook
Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-8-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Same story than hid_hw_raw_requests:
This allows to intercept and prevent or change the behavior of
hid_hw_output_report() from a bpf program.
The intent is to solve a couple of use case:
- firewalling a HID device: a firewall can monitor who opens the hidraw
nodes and then prevent or allow access to write operations on that
hidraw node.
- change the behavior of a device and emulate a new HID feature request
The hook is allowed to be run as sleepable so it can itself call
hid_hw_output_report(), which allows to "convert" one feature request into
another or even call the feature request on a different HID device on the
same physical device.
Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-7-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
