Re: reset_resume() for btusb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux