On Thu, Jul 15, 2021 at 9:45 PM Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote: > > On Do, 2021-07-15T21:14+0200, Jiri Kosina wrote: > > On Thu, 15 Jul 2021, Thomas Weißschuh wrote: > > > > > > > This driver provides HID fixups for CMedia audio chips. > > > > > For now this enables the recognition of the microphone mute button for the > > > > > HS-100B. > > > > > > > > > > Signed-off-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx> > > > > > --- > > > > > drivers/hid/Kconfig | 6 +++ > > > > > drivers/hid/Makefile | 1 + > > > > > drivers/hid/hid-cmedia-fixup.c | 82 ++++++++++++++++++++++++++++++++++ > > > > > drivers/hid/hid-ids.h | 1 + > > > > > drivers/hid/hid-quirks.c | 3 ++ > > > > > 5 files changed, 93 insertions(+) > > > > > create mode 100644 drivers/hid/hid-cmedia-fixup.c > > > > > > > > Can you please drop the '-fixup' from the driver name? We have quite a > > > > couple of drivers that do report descriptor modifications, but we're not > > > > using this '-fixup' naming scheme for them either. > > > > > > There is already an existing driver "hid-cmedia": > > > "HID driver for CMedia CM6533 audio jack controls". > > > > > > This driver works in a completely different way from mine, so I thought > > > to keep them separate. The idea was for the new driver to be a > > > collection of simple, similar report fixups. > > > > > > Should they be combined? > > > > If it's the same vendor, then yes. We generally (with exceptions, of > > course :) ) group the HID drivers by vendor, even if completely different > > quirks are needed for different devices from the same vendor. > > Will do. > > Should I merge it into the existing `struct hid_driver` and do id checks in > every member function or declare a dedicated `struct hid_driver`? Adding checks for every function is less than ideal because that would add useless calls for every raw event. But adding a new `struct hid_driver` is tempting given how different the 2 drivers are. However, you would have to write a new module_init/exit for it to register 2 drivers. Worse case, if you can not create 2 drivers in one module, you could always not set `.raw_event` in the main `struct hid_driver`, and assign it in the `.probe` once you know which device you are facing. In both cases, this is not something we already have in the HID subsystem, but we need a first, right? I also have a small nitpick on the patch itself, will comment in the original submission email. Cheers, Benjamin > > Thanks! >
