On Fri, Sep 21, 2012 at 12:49 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 20 Sep 2012, Ming Lei wrote: > >> On Thu, Sep 20, 2012 at 10:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Thu, 20 Sep 2012, Ming Lei wrote: >> > >> >> This patch sets hub device's default autosuspend delay as 0 to >> >> speedup bus suspend, see comments in code for details. >> > >> > The explanation in the comments assumes that the only reasons for hubs >> > to wake up are because of a connect change or a wakeup request from a >> > child. This is not correct. >> > >> > Hubs can also be woken up by the user. Have you tried running lsusb on >> > a system with several USB devices attached to the same hub and the >> > autosuspend delay set to 0? It's a mess. >> >> Looks no mess, see log below: >> >> [ 513.732513] hub 1-1.2:1.0: state 7 ports 4 chg 0000 evt 0008 >> [ 513.826019] usb 1-1.2.3: link qh256-0001/ee780800 start 6 [1/0 us] >> [ 513.826141] hub 1-1.2.3:1.0: state 7 ports 4 chg 0000 evt 0000 >> [ 513.826293] hub 1-1.2.3:1.0: hub_suspend >> [ 513.826324] usb 1-1.2.3: unlink qh256-0001/ee780800 start 6 [1/0 us] >> [ 513.842559] usb 1-1.2.3: usb auto-suspend, wakeup 1 >> [ 513.863067] hub 1-1.2:1.0: hub_suspend >> [ 513.863128] usb 1-1.2: unlink qh256-0001/ee6c7e00 start 2 [1/0 us] >> [ 513.873413] usb 1-1.2: usb auto-suspend, wakeup 1 >> [ 513.894287] hub 1-1:1.0: hub_suspend >> [ 513.894317] usb 1-1: unlink qh256-0001/eea03dc0 start 1 [1/0 us] >> [ 513.904357] usb 1-1: usb auto-suspend, wakeup 1 >> [ 513.925506] hub 1-0:1.0: hub_suspend >> [ 513.925720] usb usb1: bus auto-suspend, wakeup 1 >> [ 513.925750] ehci-omap ehci-omap.0: suspend root hub >> >> [root@tom-pandaboard 1-1.2]# lsusb >> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. >> Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB >> Bus 001 Device 007: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / >> D-Link DUB-H4 USB 2.0 Hub > > Your log above shows four devices (usb1, 1-1, 1-1.2, and 1-1.2.3) but > the lsusb output shows five devices (1, 2, 3, 4, and 7). So the log > isn't complete. It is complete because the device 0424:ec00 is an unbound built-in usbnet device(smsc95xx). I unbound it because its driver doesn't support runtime suspend. > > The results will be more impressive if you plug three of the hubs > directly into the fourth and attach the fourth hub to the computer. OK, I will try to do it. > >> > I think it would make more sense to set the autosuspend delay to >> > something more like 50 or 100 ms. Maybe even as low as 20. But 0 >> > seems too small. >> >> IMO, suppose it is a problem, we should try to use 0 to make it >> working because 'lsusb' is just a tool which isn't involved into actual >> hub function. >> >> I will try to study 'lsusb' to see if there is one problem and try to solve it. > > The problem isn't in lsusb. The problem is that the autosuspend > timeout should not be too small. As I explained it in another email, there shouldn't be the problem since the device will be resumed in open() when it is accessed via libusb and be suspended in its close(), should there? Thanks, -- Ming Lei -- 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
