Re: (subset) [PATCH HID v2 00/11] HID: bpf: add a new hook to control hid-generic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sep 13 2024, Benjamin Tissoires wrote:
> On Sep 13 2024, Benjamin Tissoires wrote:
> > On Tue, 10 Sep 2024 23:43:36 +0900, Benjamin Tissoires wrote:
> > > This is a slight change from the fundamentals of HID-BPF.
> > > In theory, HID-BPF is abstract to the kernel itself, and makes
> > > only changes at the HID level (through report descriptors or
> > > events emitted to/from the device).
> > > 
> > > However, we have seen a few use cases where HID-BPF might interact with
> > > the running kernel when the target device is already handled by a
> > > specific device.
> > > 
> > > [...]
> > 
> > Applied to hid/hid.git (for-6.12/bpf), thanks!
> > 
> > [01/11] HID: bpf: move HID-BPF report descriptor fixup earlier
> >         https://git.kernel.org/hid/hid/c/f10a11b7b599
> > [02/11] HID: core: save one kmemdup during .probe()
> >         https://git.kernel.org/hid/hid/c/6941754dbbc7
> > [03/11] HID: core: remove one more kmemdup on .probe()
> >         https://git.kernel.org/hid/hid/c/4fe29f36d2a3
> > [04/11] HID: bpf: allow write access to quirks field in struct hid_device
> >         https://git.kernel.org/hid/hid/c/b722f588adc6
> > [05/11] selftests/hid: add dependency on hid_common.h
> >         https://git.kernel.org/hid/hid/c/3d816765e12e
> > [06/11] selftests/hid: cleanup C tests by adding a common struct uhid_device
> >         https://git.kernel.org/hid/hid/c/28023a0f99d1
> > [07/11] selftests/hid: allow to parametrize bus/vid/pid/rdesc on the test device
> >         https://git.kernel.org/hid/hid/c/10d3147f9bb1
> > [08/11] HID: add per device quirk to force bind to hid-generic
> >         https://git.kernel.org/hid/hid/c/d030f826ea47
> > [09/11] selftests/hid: add test for assigning a given device to hid-generic
> >         https://git.kernel.org/hid/hid/c/10929078201f
> > 
> 
> Just for completeness, I've dropped 10/11 and 11/11 when applying the
> series because even if they are working it's unclear if the use case is
> rock solid, like the first one is.
> 
> The patches are still on the LKML, so if anyone believes they required
> it, we can alwasy pull them in later.

And I just dropped them from for-next, I had some KASAN issues in the
testsuite, meaning that something is off in the memory allocation/free.

Cheers,
Benjamin




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux