On Thu, 2022-02-24 at 12:31 +0100, Greg KH wrote:

On Thu, Feb 24, 2022 at 12:08:22PM +0100, Benjamin Tissoires wrote:

quoted

Hi there,

This series introduces support of eBPF for HID devices.

I have several use cases where eBPF could be interesting for those
input devices:

- simple fixup of report descriptor:

In the HID tree, we have half of the drivers that are "simple" and
that just fix one key or one byte in the report descriptor.
Currently, for users of such devices, the process of fixing them
is long and painful.
With eBPF, we could externalize those fixups in one external repo,
ship various CoRe bpf programs and have those programs loaded at
boot
time without having to install a new kernel (and wait 6 months for
the
fix to land in the distro kernel)

Why would a distro update such an external repo faster than they
update
the kernel?  Many sane distros update their kernel faster than other
packages already, how about fixing your distro?  :)

I'm all for the idea of using ebpf for HID devices, but now we have
to
keep track of multiple packages to be in sync here.  Is this making
things harder overall?

I don't quite understand how taking eBPF quirks for HID devices out of
the kernel tree is different from taking suspend quirks out of the
kernel tree:
https://www.spinics.net/lists/linux-usb/msg204506.html