On Thu, 13 Mar 2014, Oliver Neukum wrote: > On Thu, 2014-03-13 at 10:11 -0400, Alan Stern wrote: > > On Thu, 13 Mar 2014, Oliver Neukum wrote: > > > > > On Wed, 2014-03-12 at 15:18 +0000, Poulain, Loic wrote: > > > > My thought was to fix the usbcore rebind issue (with pm_runtime) > > > > to let the core unbind and rebind the device's interfaces for drivers > > > > with no reset_resume callback (not only btusb). > > > > > > Those functions seem to be independent. > > > > Which functions are you referring to? > > reset_resume() and the ability to deal with errors > in the resume code paths. I should have written functionalities. Well, we are talking about two different classes of errors: Errors encountered by usb_port_resume and helpers when resuming the physical device; Errors encountered by the various interface drivers when they come back to life following a resume. Errors in the first class are handled by a reset-resume (when applicable) or by a logical disconnect (as the last resort). Errors in the second class are handled by unbinding and rebinding the driver. > > > Alan, perhaps the core code should honor QUIRK_RESET and unbind > > > if it is set. Then hid2hci could set the flag. > > > > You mean, if QUIRK_RESET is set then don't bother doing a reset-resume? > > Just logically disconnect the device? > > No, rebind. This bug > https://lkml.org/lkml/2013/11/26/347 > seems to indicate a problem in that area. Ah, now I understand. We are talking about mode-switching devices that revert to their default mode following a reset, as opposed to losing their firmware contents (although the mode switch may involve a change to the descriptors too). This sort of thing doesn't fit cleanly into the two classes of errors outlined above. In this situation we have a choice. We could do a reset and then rebind all the interfaces, or we could do a logical disconnect and then rediscover the reverted device. I think the second approach is cleaner, because it would generate the appropriate udev events for userspace hooks. (For example, it would allow the usb_modeswitch program to do its job properly.) This reasoning suggests that when QUIRK_RESET is present, we should always skip reset-resume and go directly to logical disconnect. > > Why would that be better than unbinding and rebinding the driver? > > It isn't. But now that you are asking, you remind me. What about > the port power off code? Does it need to look at QUIRK_RESET? Yes, it should. Dan Williams and I haven't reached that point yet in our patch review. 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
