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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
