On Wed, 5 Mar 2014, Oliver Neukum wrote: > On Wed, 2014-03-05 at 09:40 +0000, Poulain, Loic wrote: > > Hi, > > > > I think there is an issue with the reset-resume mechanism during USB > > runtime resume, leaving the interfaces suspended forever. > > > > - Context: > > > > Android platform, running a 3.13 + Google AOSP patches kernel. > > I'm facing a USB issue with the bsusb driver. btusb driver has the USB > > runtime suspend enabled + remote wakeup. > > However sometimes the USB runtime resume does not work as expected (we > > admit here that this can happen). > > > > [ 3066.408413] usb 2-3: usb auto-resume > > [ 3066.408433] hub 2-0:1.0: state 7 ports 9 chg 0000 evt 0008 > > [ 3066.445465] usb 2-3: finish resume > > [ 3071.447591] usb 2-3: bt_hc_worker timed out on ep0in len=0/2 > > [ 3071.447598] usb 2-3: retry with reset-resume > > > > Then the usbcore tries a reset-resume, but btusb driver does not > > implement this callback. The best solution would be to fix the hardware so that a normal resume does work. > This is extremely tricky, almost academical a question. > We cannot fall back to reset_resume() in this case without > very bad consequences. > If remote wakeup is needed, reset_resume() must not be used. The only alternative is to logically disconnect the device. But this conflicts with the persist_enabled flag. > It seems to me that the bug in this case is the fallback itself. > From a design viewpoint is probably wrong the unbind a device > in the runtime case. We'd better notify the driver in every case. > If you unbind and rebind you just risk getting into a tight loop. In this case, turning off the persist flag might help: echo 0 >/sys/bus/usb/devices/.../power/persist 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
