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. 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. 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. Regards Oliver -- 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
