On Fri, 18 Jan 2013, Sarah Sharp wrote: > Hi Alan, > > What's the current state of USB mass storage suspend? I know there was > some purposed changes to the SCSI or block layer that would have > effected suspend, and I wondered if those made it in. The block-layer autosuspend patches are in pretty good shape. I haven't heard any objections to them recently from James Bottomley or Jens Axboe, so maybe they'll be accepted soon. Don't forget that autosuspend for mass storage is available right now, in 3.7 and earlier kernels. It affects only disks whose device file isn't open (hence no mounted filesystems on the disk), and it has to be enabled by userspace (write "auto" to power/control for the SCSI disk device and its ancestors). > I'm specifically looking for when we can expect a USB storage device to > go into auto-suspend. If userspace enables auto-suspend and sets the > autosuspend_delay_ms to zero, could we see auto-suspend between SCSI > commands? Or will the device remain in U0 until the storage device is > unmounted? The autosuspend delay at the USB level probably should be set to 0; then the autosuspend delay at the SCSI disk level will control the actual power changes. I'm not sure if everything will work correctly with the delay set to 0. In theory you would indeed see autosuspend kicking in between SCSI commands. But the implementation might not work correctly under those conditions -- I didn't care about that case because it shouldn't be used. On the other hand, it should work as expected once the autosuspend delay is set to a not-unreasonable value, say 100 ms or anything larger. The drive should indeed go into suspend whenever the interval between SCSI commands is longer than the autosuspend delay (within a factor of 2). Note that drives with removable media are polled automatically by the kernel at intervals of 2 seconds by default. If the autosuspend delay is longer than that, it will never have a chance to take effect. 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
