Hi, On Jun 25 2016 or thereabouts, Dennis Chen wrote: > On Fri, 2016-06-24 at 09:14 +0200, Benjamin Tissoires wrote: > > Looks like the same issue Andy is seeing on the Surface Book. So I > > think my patch must have a bug where it resets the quirks set by > > usbhid. And this is why we are screwed here. > > > > Yes, I think that's likely. There doesn't seem to be an issue most of > the time, so it's not a huge deal. I spent a good amount of time trying to figure out where the bug was, and I couldn't reproduce it either with uhid or even with usb_gadget. Even KASan doesn't gives any wrong memory access, and I can't understand why you get this faulty behavior. So I must say, I am puzzled on why you end up calling usbhid_init_reports() while the quirk HID_QUIRK_NO_INIT_REPORTS should be in place. Would you mind adding some printk() in hid-multitouch to dump the value of hdev->quirks before and after calling hid_hw_start() in mt_probe()? Also, ideally, if you could add a dump_stack() in drivers/hid/usbhid/hid-core.c, right before leaving usbhid_init_reports(), that would be awesome. I would have prefer being able to understand myself what is going on, but it looks like there is something different happening when I do not have the device. > > > Regarding your disconnect issue, what happens I think is that you > > disconnect it before the timeout of usb_submit_urb(), and so the usb > > layer is stuck trying to access the device and can't access the newly > > plugged one. If you wait enough (initial timeout + new timeout -> 20 > > secs), then the device behaves properly again. > > > > That is the behavior I have noticed. Is there any potential fix? > The fix is to not fetch the buggy features that timeout. For that, we usually set the flag HID_QUIRK_NO_INIT_REPORTS, which prevents it. But in your case, the code says that the flag is set, while the code is still called :( Thanks, Benjamin -- 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
