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