- 01 Jul, 2024 6 commits
-
-
Benjamin Tissoires authored
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/109Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Link: https://patch.msgid.link/20240627-import-bpf-v1-2-0dbcda4a5b1f@kernel.orgSigned-off-by:
Benjamin Tissoires <bentiss@kernel.org>
-
Benjamin Tissoires authored
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/96Signed-off-by: -
Benjamin Tissoires authored
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: 9286675a ("HID: bpf: add HID-BPF hooks for hid_hw_output_report") Link: https://patch.msgid.link/20240701-fix-cki-v2-4-20564e2e1393@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
We had the following errors while doing make htmldocs: Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:144: ERROR: Unexpected indentation. Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:145: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:147: ERROR: Unexpected indentation. Reported-by:
-
Benjamin Tissoires authored
I've got multiple reports of: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]. Let's use the same trick than kernel/bpf/helpers.c to shut up that warning. Even if we were on an architecture with addresses on more than 64 bits, this isn't much of an issue as the address is not used as a pointer, but as an hash and the caller is not supposed to go back to the kernel address ever. And while we change those, make sure we use u64 instead of __u64 for consistency Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/Reported-by:
Mirsad Todorovac <mtodorovac69@gmail.com> Fixes: 67eccf15 ("HID: add source argument to HID low level functions") Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
In the same way than commit ae7487d1 ("selftests/hid: ensure we can compile the tests on kernels pre-6.3") we should expose struct hid_bpf_ops when it's not available in vmlinux.h. So unexpose an eventual struct hid_bpf_ops, include vmlinux.h, and re-export struct hid_bpf_ops. Fixes: d7696738 ("selftests/hid: convert the hid_bpf selftests with struct_ops") Reported-by:
-
- 27 Jun, 2024 14 commits
-
-
Benjamin Tissoires authored
We don't want this call to allow an infinite loop in HID-BPF, so let's have some tests. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-13-cfd60fb6c79f@kernel.orgAcked-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Benjamin Tissoires authored
Similar to test_multiply_events_wq: we receive one event and inject a new one. But given that this time we are already in the event hook, we can use hid_bpf_try_input_report() directly as this function will not sleep. Note that the injected event gets processed before the original one this way. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-12-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
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.orgAcked-by:
-
Benjamin Tissoires authored
Now that bpf_wq is available, we can write a test with it. Having hid_bpf_input_report() waiting for the device means that we can directly call it, and we get that event when the device is ready. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-10-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
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.orgAcked-by: -
Benjamin Tissoires authored
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.orgAcked-by:
-
Benjamin Tissoires authored
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.orgAcked-by: -
Benjamin Tissoires authored
We add 3 new tests: - first, we make sure we can prevent the raw_request 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_request(), returning a custom value - last, we ensure that we can not loop between hooks for hid_hw_raw_request() and manual calls to hid_bpf_hw_request() from that hook Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-6-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
When we attach a sleepable hook to hid_hw_raw_requests, we can (and in many cases should) call ourself hid_bpf_raw_request(), to actually fetch data from the device itself. However, this means that we might enter an infinite loop between hid_hw_raw_requests hooks and hid_bpf_hw_request() call. To prevent that, if a hid_bpf_hw_request() call is emitted, we prevent any new call of this kfunc by storing the information in the context. This way we can always trace/monitor/filter the incoming bpf requests, while preventing those loops to happen. I don't think exposing "from_bpf" is very interesting because while writing such a bpf program, you need to match at least the report number and/or the source of the call. So a blind "if there is a hid_hw_raw_request() call, I'm emitting another one" makes no real sense. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-5-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
This allows to intercept and prevent or change the behavior of hid_hw_raw_request() 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_bpf_hw_request(), 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-4-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
We want to add sleepable callbacks for hid_hw_raw_request() and hid_hw_output_report(), but we can not use a plain RCU for those. Prepare for a SRCU so we can extend HID-BPF. This changes a little bit how hid_bpf_device_init() behaves, as it may now fail, so there is a tiny hid-core.c change to accommodate for this. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-3-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
This allows to know who actually sent what when we process the request to the device. This will be useful for a BPF firewall program to allow or not requests coming from a dedicated hidraw node client. Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-2-cfd60fb6c79f@kernel.orgAcked-by:
-
Benjamin Tissoires authored
Looks like if a bpf program gets inserted and then removed, hdev->bpf.device_data is then allocated, but the loop iterating over the bpf program is never assigning ret. This is a problem and also revealed another bug in which only the last value of ret was checked. This effectively meant than only the last program in the chain could change the size of the incoming buffer. Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/all/00f7b624-219f-4a05-a7ad-5335f15a41c7@moroto.mountain Fixes: 4a86220e ("HID: bpf: remove tracing HID-BPF capability") Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-1-cfd60fb6c79f@kernel.orgAcked-by:
-
Luis Felipe Hernandez authored
* spelling fix: XBox -> Xbox, lowercase 'b' as per Microsoft branding * rephrase: paddle -> paddles, the controller itself has more than one paddle * rephrase: replace usage of "those" in favor of explicitly making reference to the paddles * grammatical fix: report -> reports, use present tense verb. * spelling fix: interpret * consistency: capitalize the first word in bullet points Signed-off-by:
Luis Felipe Hernandez <luis.hernandez093@gmail.com> Link: https://patch.msgid.link/20240625105553.50830-1-luis.hernandez093@gmail.com [bentiss: renamed the file into Xbox, not XBox] Signed-off-by:
-
- 14 Jun, 2024 16 commits
-
-
Benjamin Tissoires authored
It is useful to change the name, the phys and/or the uniq of a struct hid_device during .rdesc_fixup(). For example, hid-uclogic.ko changes the uniq to store the firmware version to differentiate between 2 devices sharing the same PID. In the same way, changing the device name is useful when the device export 3 nodes, all with the same name. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-16-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
The idea is to provide a list of stucts and their editable fields. Currently no functional changes are introduced here, we will add some more writeable fields in the next patch. Acked-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-15-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
Without this helpers like bpf_printk() or bpf_map_update() are not available, making anything but change of bytes impossible to do. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-14-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
There is no real reasons to paper over warnings for such small programs. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-13-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
warning: unused variable ‘tilt’ [-Wunused-variable] Signed-off-by:
-
Benjamin Tissoires authored
This is the current decision we took: we don't provide automatic loading of HID-BPF by the kernel directly, but rely on an external tool for it. This tool is currently udev-hid-bpf, so let's make people aware of it. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-11-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
Now that we are using struct_ops, the docs need to be changed. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-10-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
I got a weird verifier error with a subprog once, so let's have a test for it. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-9-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
We can now rely on struct_ops as we cleared the users in-tree. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-8-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
Very mechanical: - Change HID_BPF_DEVICE_EVENT and HID_BPF_RDESC_FIXUP #defines - add a matching SEC(".struct_ops.link") - in ArtistPro16Gen2 make the 2 functions static and have a new one calling them Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-7-6ac6ade58329@kernel.orgSigned-off-by: -
Benjamin Tissoires authored
We are going to switch over struct_ops, so instead of having to manually replace all fields one by one, let's have a common place to change it. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-6-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
This is mostly mechanical: attach_prog is dropped, and the SEC are converted into struct_ops. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-5-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
We drop the need for the attach() bpf syscall, but we need to set up the hid_id field before calling __load(). The .bpf.c part is mechanical: we create one struct_ops per HID-BPF program, as all the tests are for one program at a time. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-4-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
We do this implementation in several steps to not have the CI failing: - first (this patch), we add struct_ops while keeping the existing infra available - then we change the selftests, the examples and the existing in-tree HID-BPF programs - then we remove the existing trace points making old HID-BPF obsolete There are a few advantages of struct_ops over tracing: - compatibility with sleepable programs (for hid_hw_raw_request() in a later patch) - a lot simpler in the kernel: it's a simple rcu protected list - we can add more parameters to the function called without much trouble - the "attach" is now generic through BPF-core: the caller just needs to set hid_id and flags before calling __load(). - all the BPF tough part is not handled in BPF-core through generic processing - hid_bpf_ctx is now only writable where it needs be Acked-by:
-
Benjamin Tissoires authored
no code change, but this way we reduce code duplication and we can export it later. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-2-6ac6ade58329@kernel.orgSigned-off-by:
-
Benjamin Tissoires authored
Those operations are the ones from HID, not HID-BPF, and I'd like to reuse hid_bpf_ops as the user facing struct_ops API. Link: https://lore.kernel.org/r/20240608-hid_bpf_struct_ops-v3-1-6ac6ade58329@kernel.orgSigned-off-by:
-
- 08 Jun, 2024 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hidLinus Torvalds authored
Pull HID fixes from Benjamin Tissoires: - fix potential read out of bounds in hid-asus (Andrew Ballance) - fix endian-conversion on little endian systems in intel-ish-hid (Arnd Bergmann) - A couple of new input event codes (Aseda Aboagye) - errors handling fixes in hid-nvidia-shield (Chen Ni), hid-nintendo (Christophe JAILLET), hid-logitech-dj (José Expósito) - current leakage fix while the device is in suspend on a i2c-hid laptop (Johan Hovold) - other assorted smaller fixes and device ID / quirk entry additions * tag 'for-linus-2024060801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: Ignore battery for ELAN touchscreens 2F2C and 4116 HID: i2c-hid: elan: fix reset suspend current leakage dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property dt-bindings: HID: i2c-hid: elan: add Elan eKTH5015M dt-bindings: HID: i2c-hid: add dedicated Ilitek ILI2901 schema input: Add support for "Do Not Disturb" input: Add event code for accessibility key hid: asus: asus_report_fixup: fix potential read out of bounds HID: logitech-hidpp: add missing MODULE_DESCRIPTION() macro HID: intel-ish-hid: fix endian-conversion HID: nintendo: Fix an error handling path in nintendo_hid_probe() HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() HID: core: remove unnecessary WARN_ON() in implement() HID: nvidia-shield: Add missing check for input_ff_create_memless HID: intel-ish-hid: Fix build error for COMPILE_TEST
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix the initial state of the save button in 'make gconfig' - Improve the Kconfig documentation - Fix a Kconfig bug regarding property visibility - Fix build breakage for systems where 'sed' is not installed in /bin - Fix a false warning about missing MODULE_DESCRIPTION() * tag 'kbuild-fixes-v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: modpost: do not warn about missing MODULE_DESCRIPTION() for vmlinux.o kbuild: explicitly run mksysmap as sed script from link-vmlinux.sh kconfig: remove wrong expr_trans_bool() kconfig: doc: document behavior of 'select' and 'imply' followed by 'if' kconfig: doc: fix a typo in the note about 'imply' kconfig: gconf: give a proper initial state to the Save button kconfig: remove unneeded code for user-supplied values being out of range
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fixes from Mauro Carvalho Chehab: - fixes for the new ipu6 driver (and related fixes to mei csi driver) - fix a double debugfs remove logic at mgb4 driver - a documentation fix * tag 'media/v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: intel/ipu6: add csi2 port sanity check in notifier bound media: intel/ipu6: update the maximum supported csi2 port number to 6 media: mei: csi: Warn less verbosely of a missing device fwnode media: mei: csi: Put the IPU device reference media: intel/ipu6: fix the buffer flags caused by wrong parentheses media: intel/ipu6: Fix an error handling path in isys_probe() media: intel/ipu6: Move isys_remove() close to isys_probe() media: intel/ipu6: Fix some redundant resources freeing in ipu6_pci_remove() media: Documentation: v4l: Fix ACTIVE route flag media: mgb4: Fix double debugfs remove
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Ingo Molnar: - Fix possible memory leak the riscv-intc irqchip driver load failures - Fix boot crash in the sifive-plic irqchip driver caused by recently changed boot initialization order - Fix race condition in the gic-v3-its irqchip driver * tag 'irq-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update() irqchip/sifive-plic: Chain to parent IRQ after handlers are ready irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails
-
