On Wed, 13 Sep 2017, jikos@xxxxxxxxxx wrote:
> On Wed, 13 Sep 2017, benjamin.tissoires@xxxxxxxxxx wrote:
>
> > I do not see a reason not to. Maybe Jiri will, but the fact that one
> > version works and one doesn't seem enough to allow such specific
> > blacklisting.
>
> The blacklist matching currently doesn't support that, but it'd be trivial to match, and I
> actually think it generally makes sense to me. So feel free (once you guys settle on
> solution that both Chromium and Jabr folk find acceptable) to send this together with
> a hid-core patch that'd add a possibility to perform per-fw-version matching.
I believe that ChromiumOS and Jabra agree on a firmware version based
blacklisting of these 2 devices. We release new firmwares for the 2
devices and add code to ignore the HID interface on all previous versions.
We have discussed using 'bcdDevice' for this. I am afraid the bcdDevice
field won't cut it as firmware version for devices in general. In all
descriptions I have seen, the field is a vendor defined device release
number. In the USB 3.1 spec, bcdDevice is described like this:
"Device release number in binary-coded decimal"
For Jabra devices the bcdDevice contains the firmware version, but it is
vendor specific. So I don't think it makes sense to come up with
a generic mechanism based on this.
Therefore, my proposal is to handle this in the vendor switch in
hid_ignore(). I could add a case for Jabra that checks
bcdDevice against a known good version.
To access bcdDevice we can do something like this:
u16 hid_get_bcd_device(struct hid_device *hdev)
{
struct usb_device *usbdev =
interface_to_usbdev(to_usb_interface(hdev->dev.parent));
return le16_to_cpu(usbdev->descriptor.bcdDevice);
}
There are several vendor specific drivers that do something
along these lines. Would this be OK in hid-core.c? I have tested
Comments welcome, thanks.
Niels
**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
