Re: [PATCH] HID: add cmedia-fixup driver

On Thu, Jul 15, 2021 at 9:45 PM Thomas Weißschuh [off-list ref] wrote:

On Do, 2021-07-15T21:14+0200, Jiri Kosina wrote:

quoted

On Thu, 15 Jul 2021, Thomas Weißschuh wrote:

quoted

quoted

quoted

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@weissschuh.net>
---
 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!