On Sat, Jan 14, 2012 at 11:19:29AM -0500, Alan Stern wrote: > On Fri, 13 Jan 2012, Oliver Neukum wrote: > > > Am Freitag, 13. Januar 2012, 19:02:36 schrieb Alan Stern: > > > > Yes, I know. I had hoped that if the auto-suspend timeout was set to > > > > zero, the mass storage driver would suspend the device immediately after > > > > any SCSI command, but you've said that's not true. > > > > > > Well, it makes sense for usb-storage devices always to have their > > > autosuspend timeout set to 0. This means relying on the timeouts of > > > the underlying SCSI devices. I don't know if you would want to set > > > those to 0, but you might set them to something like 100 ms. And > > > hopefully the CD polling rate would be set pretty low -- but that's > > > probably not under direct user control. > > > > > > But the emulated hub will still have an autosuspend timeout of 2 > > > seconds, unless that is changed as well. > > > > Which again leads to the question why we want autosuspend delays > > on the inner nodes of the device tree. It really makes no sense to delay > > on the inner nodes. If you suspend at all, you want to suspend as much > > as you can of a branch and at once. > > That's a good question. In general, inner nodes should have very short > delays. > > On the other hand, USB hubs aren't always inner nodes. They generate > their own wake requests, in addition to forwarding requests from > downstream. Therefore hubs should not necessarily have short delays. Sorry, I still don't get it. :) Why can't we immediately suspend a parent hub when all its children are suspended? I don't see why the fact that the hub may send remote wake events for device connect/disconnect should have any effect on how fast we suspend the hub. Sarah Sharp -- 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
