On Thu, 13 Mar 2014, Oliver Neukum wrote: > 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. Fair enough. Although we don't really lose much by making the attempt, even if it is doomed to fail. As I see it, the only compelling reason for allowing QUIRK_RESET to prevent reset-resume would be if the device morphs in a very subtle way, which we can't detect. However, I don't know of any devices like that. > If we take the premise that a class driver ought to have reset_resume() > then we need a way to identify the hopeless cases. Not necessarily. We can try the reset anyway, and then see if it fails. Or if the driver's reset-resume routine fails. Don't forget, it's possible for some of the drivers bound to a composite device to succeed during a reset-resume while others fail. We wouldn't want to disconnect the entire device in that case. > In addition there is the problem that a driver isn't told why > reset_resume() is called. There's only one reason for calling reset_resume: The device was suspended and it had to be reset during the resume procedure. Alan Stern -- 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
