On Fri, Jul 25, 2014 at 02:12:42PM -0400, Alan Stern wrote: > On Fri, 25 Jul 2014, Michael Welling wrote: > > > > What if you prevent the root hub from going into runtime suspend? Or > > > prevent the external hub from going into runtime suspend? You could be > > > facing a wakeup problem. > > > > This helps, it appears that the issue is with the external HUB. > > > > If I disable the autosuspend on the external USB HUB I can plug and > > unplug the devices as many times as I want. > > > > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control > > > > The external USB HUB is USB2512 and is right on the board. > > How do I go about either preventing the suspend or fixing the code such > > that it works? > The plot thickens.... So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 3788886573 S Ci:001:00 s a3 00 0000 0001 0004 4 < de382e40 3788890604 C Ci:001:00 0 4 = 07050000 de382e40 3788892965 S Ci:001:00 s a3 00 0000 0002 0004 4 < de382e40 3788893093 C Ci:001:00 0 4 = 00010000 de382e40 3788894834 S Ci:001:00 s a3 00 0000 0003 0004 4 < de382e40 3788894958 C Ci:001:00 0 4 = 00010000 de7d92c0 3788896519 S Ii:001:01 -115 4 < de382e40 3788898778 S Ci:001:00 s a3 00 0000 0001 0004 4 < de382e40 3788900188 C Ci:001:00 0 4 = 07050000 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0000 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0000 0001 0004 4 < de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 < de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0000 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0000 0000 0002 2 < de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0000 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0000 0001 0004 4 < de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 3789022226 S Ii:001:01 -115 4 < de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0000 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0000 0001 0004 4 < de249040 3789231111 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0000 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0000 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0000 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0000 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0000 0001 0004 4 < de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0000 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0000 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0000 0001 0004 4 < de2490c0 3789286255 C Ci:001:00 0 4 = 00010000 de2490c0 3789330975 S Ci:001:00 s a3 00 0000 0001 0004 4 < de2490c0 3789332606 C Ci:001:00 0 4 = 00010000 de2490c0 3789371015 S Ci:001:00 s a3 00 0000 0001 0004 4 < de2490c0 3789371146 C Ci:001:00 0 4 = 00010000 de2490c0 3789410975 S Ci:001:00 s a3 00 0000 0001 0004 4 < de2490c0 3789411097 C Ci:001:00 0 4 = 00010000 de2490c0 3789450972 S Ci:001:00 s a3 00 0000 0001 0004 4 < de2490c0 3789451081 C Ci:001:00 0 4 = 00010000 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. > One way to prevent the hub from suspending is to use the echo command > above. Another way is to set the autosuspend value to -1. Or set the > usbcore autosuspend module parameter to -1, which affects the default > autosuspend setting for all USB devices. > > As for fixing the code... that's harder to answer because as far as I > know, there is nothing wrong in the code. Maybe the problem is in an > area I'm not familiar with (such as the phy support), or maybe you have > non-compliant hardware. > > You can get more information as follows: enable suspend, let the hub go > into runtime suspend, then plug in a device, and disable suspend. The > port status information in the resulting usbmon trace is likely to show > whether the hub responded properly to the hotplug event. > > If you're asking about config options to disable runtime suspend, you > can turn off CONFIG_PM_RUNTIME. But that will prevent runtime suspend > for _all_ devices on the system, which probably isn't what you want. > If you want to edit the code to prevent USB hubs (or any USB device) > from ever going into runtime suspend, I can tell you what to change. > > > It should be noted that the CONFIG_USB_SUSPEND option not longer exists > > in the kernel but it is still referenced in the documentation. > > > > http://lxr.free-electrons.com/source/Documentation/usb/power-management.txt > > Yes. There was a proposal to update the documentation posted on the > mailing list a few weeks ago. I don't know what happened to it. > > 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
