On Tue, 21 Jan 2014, Phillip Susi wrote: > On 1/21/2014 11:03 AM, Alan Stern wrote: > > However, there is a compromise. The user gets to select the > > autosuspend delay. If that delay is set to a very large value, it > > will effectively prevent autosuspends from occurring, without > > causing an already-suspended device to resume right away. (On the > > other hand, it would not prevent a lazy resume.) > > Right, so why can't you set the delay to -1 without waking the already > sleeping drive up? There are separate sysfs knobs for the delay and > whether or not it is enabled, yet the kernel seems to couple the two > together. Right now, setting the delay to -1 is taken to mean that runtime PM should be disabled. Hence, if the device is suspended, it has to be resumed. (The reason is historical; in the earliest implementation of runtime PM, there was no way to disable it other than to set the delay to -1 -- there was no separate sysfs knob.) You are suggesting that the meaning be changed: The kernel would never initiate an autosuspend, but runtime PM would still be enabled so the device would remain suspended if it already was. I can't think of any reason why that would cause any problems. I'll suggest it in a new thread on the linux-pm mailing list. It's somewhat off-topic for this thread. 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
