There are many situations where generic HID driver provides some basic level of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden there is a new config option they have to enable in order to get any support for their device whatsoever, although previous kernel versions provided basic support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in hid_have_special_driver iff the specific config option has been specified, and let generic driver handle the device otherwise. Also make the behavior of hid_scan_report() (where the same decision is being taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver a bit to restore the alphabetical ordering (first order by config option, and within those sections order by VID).
This is considered a short-term solution, before generic way of giving precedence to special drivers and falling back to generic driver is figured out.
While at it, fixup a missing entry for GFRM driver; thanks to Hans de Geode for spotting this (and for discovering a few issues in the conversion).
0ca4cd7 HID: let generic driver yield control iff specific driver has been enabled
drivers/hid/hid-core.c | 282 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 221 insertions(+), 61 deletions(-)