usbhid: call report_fixup before comparing descriptors

hid_post_reset checks the stored report descriptor against what is currently returned by the device. An HID driver's report_fixup method may have changed the stored descriptor, however, creating false positives. These leave some devices nonfunctional after a resume, with a "reset_resume error 1" reported. This patch passes the new descriptor to the driver's report_fixup method, if any, before it is compared to the stored one.

---

@@ -1436,6 +1436,10 @@ static int hid_post_reset(struct usb_int
         kfree(rdesc);
         return 1;
     }
+
+    if (hid->driver && hid->driver->report_fixup)
+        rdesc = hid->driver->report_fixup(hid, rdesc, &status);
+
     status = memcmp(rdesc, hid->rdesc, hid->rsize);
     kfree(rdesc);
     if (status != 0) {

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hello.

Hi Kevin,

Hi Henrik. Thanks for the tip. I tried comparing rdesc to hid->dev_rdesc without any report_fixup call, but the problem (device nonfunctional with "reset_resume error 1" message) still occurred. Upon looking at hid_open_report, I noticed that it calls report_fixup on dev_rdesc (pointer copied to "start") before it is kmemdup'd to rdesc. For most HID drivers, the report_fixup method directly modifies and returns the passed structure instead of returning a new pointer, so dev_rdesc is also modified. Assuming that dev_rdesc is supposed to be the unmodified data, I moved the report_fixup call in hid_open_report to after the kmemdup. This combination successfully solves the original problem. I'll submit a new patch version presently that addresses both points.

Hi Sergei. Thanks for catching that. The munging problem was supposedly fixed in Thunderbird years ago! I guess I'll just mail the new version from the command line.

-Kevin