On Wed, 2014-03-05 at 11:15 -0500, Alan Stern wrote: > 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. Indeed. > > 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. In error handling? It seems to me that persist_enabled is a declaration of a goal. What the consequences of reaching that goal should be is a legitimate question. > > 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 But in case remote wakeup is not requested the device should persist. 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
