On Thu, 2014-03-13 at 08:05 +0000, Peter Chen wrote: > > > > On Wed, 2014-03-12 at 15:18 +0000, Poulain, Loic wrote: > > > Implementing the btusb reset_resume seems risky, a patch implementing > > > this callback has been previously reverted due to HID dual mode device > > > regression. (cf https://lkml.org/lkml/2013/11/26/347) > > > > Alan, perhaps the core code should honor QUIRK_RESET and unbind if it is > > set. Then hid2hci could set the flag. > > > > It will cause reset every time, just like Poulain said, some devices may > only fail at rare cases. True, but that is the point. We cannot tell devices apart. If we know reset_resume() will fail, there's no point in the attempt. If we take the premise that a class driver ought to have reset_resume() then we need a way to identify the hopeless cases. In addition there is the problem that a driver isn't told why reset_resume() is called. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
