On Thu, 2 Sep 2010, Alan Stern wrote: > The alternative, as I suggested earlier, is to store _two_ delay values > in dev->power: the value from sysfs and the value to actually use. I'm > not in favor of this but I'll consider it if you want. After thinking about this some more, I have decided this may not be so bad. There could be two suspend_delay values stored, a primary and an alternate, along with a flag telling the PM core which value to use. The sysfs interface would always update the primary delay and subsystems would be responsible for updating the alternate. (In the SCSI case, the primary value would be the "medium present" delay and the alternate would be for "medium not present".) The subsystem would set the "use_alternate_delay" flag as desired. A subsystem could even maintain more than one alternate delay value; all it would have to do is tell the PM core when it wanted to replace the current alternate delay with a different value. It makes sense to treat the primary delay specially, since many or most devices will never need any others. But this way we can allow for that possibility. Back on the topic of USB interfaces... Rather than having a flag to mean "use the parent's delay", I think a different approach would work better. The real issue with interfaces is that they are only logical sub-devices; they can't be power-managed separately from their parent. Indeed, the runtime_suspend and runtime_resume callbacks for interfaces always return 0 immediately without doing anything, and the runtime_idle callback always calls pm_runtime_suspend. So why not tell the PM core about this behavior? Let's put a "no_callbacks" flag in dev_pm_info. When this flag is set the core won't bother invoking the runtime callbacks; it can always assume success. More importantly, an asynchronous request may never need to use the workqueue: __pm_request_idle can directly call __pm_request_suspend. If the device's state is ACTIVE then __pm_request_suspend can switch the state directly to SUSPENDED. If the device's state is SUSPENDED and the parent's state is ACTIVE then __pm_request_resume can switch the device directly to ACTIVE. (If the parent isn't ACTIVE then we need to proceed as we do now.) With those shortcuts added there won't be any need to use delayed autosuspend for interfaces. I don't know if any other subsystems would want to use the no_callbacks flag, but it's possible. What do you think? 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
