There has been a recent proposal to add autosuspend support to the usb-storage driver. (I.e., after a certain user-definable period of inactivity, usb-storage would automatically suspend the USB link to the device. Receipt of a request from the SCSI core would cause an automatic resume.) This has been discussed on linux-scsi in the past, and reactions were mixed. We are now at the point where the infrastructure is in place to actually implement the proposal. The question is, should we? For many USB mass-storage devices, the overhead of suspend and resume is pretty small, just the time required to carry out the operations (a few tens of milliseconds for resume, less than 10 ms for suspend). On the other hand, a SCSI device might interpret a USB suspend as a signal to start its own power-saving measures. It might even cause a drive to spin down, although I don't think the common USB-IDE bridges work that way. It can be argued that autosuspend requests should originate at lower points in the device tree and bubble up to the parent. With a disk-type device, for instance, we might want to have sd decide when it's okay to suspend. It would inform the SCSI core, which would then decide when the entire SCSI bus can be suspended. The core would then inform the host adapter driver (usb-storage in this case), which would suspend the transport. Has there been any discussion about doing things this way? Does anybody think that usb-storage should _not_ do autosuspend on its own initiative? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
