On Mon, Oct 2, 2017, vpalatin@xxxxxxxxxx wrote:
> Is there really a value in putting it in both lists ? can we put it only in the latter ?
No, you're right we can just use the latter.
> > + * against the good_release value. If the bcdDevice value is less
> > +than
> > + * good_release the device is ignored.
> > + */
> > +static const struct hid_ignore_by_release {
> > + __u16 idVendor;
> > + __u16 idProduct;
> > + __u16 good_release;
> > +} hid_ignore_by_release[] = {
> > + { USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_410, 0x111 },
> > + { USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_510, 0x214 },
> > + { 0, 0 }
> > +};
>
> Maybe we should use here 'struct usb_device_id' as done in other drivers.
> (and maybe put the flags in .driver_info) It conveniently has a .bcdDevice_lo and
> .bcdDevice_hi fields. Then we can use the more generic usb_match_id() function.
That's a good idea.
I just had a look, and afaics I will need to use struct usb_interface in
drivers/hid/usbhid/hid-quirks.c. So I will need to pull in include/linux/usb.h.
Also I will need to forward declare struct usb_interface in
include/linux/hid.h for the usbhid_lookup_quirk() prototype. Is it going
to be OK to do this?
I will come up with a V2 patch for these suggestions.
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 ************************
��.n��������+%������w��{.n�����{��)��^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
