On Monday, August 30, 2010, Alan Stern wrote: > On Sun, 29 Aug 2010, Rafael J. Wysocki wrote: > > > > > It seems to me that the standard for /sys is to use miliseconds. > > > > > > "45 minutes" expressed in milliseconds isn't very easy to comprehend; > > > it comes out as "2700000". Compare this to "45:00.000". I'm not sure > > > that's the best way to go. > > > > Well, that depends on whether or not you intend to make them human-readable. > > While the latter is definitely better for humans, the former may be more > > convenient for software processing. > > It seems likely that the most common usage pattern will be via a GUI > control, so the GUI can do the formatting and conversion. In that case > I think the attribute should be named "suspend_delay_ms". Putting the > units into the name like this seems to be a common pattern. > > Should we continue the convention (used in the USB subsystem) that > negative values for suspend_delay will disable autosuspend? I'm not > sure how useful that is, given that setting power/control to "on" has > the same effect. > > Oliver, you originally argued strongly in favor of having both > mechanisms. Do you still think they are both needed? > > One last thing... I'm definitely planning to make the suspend_delay > value affect suspends initiated by pm_schedule_suspend. (The routine > will always use the maximum of the specified delay and the value > calculated from last_busy plus suspend_delay. Also, > pm_suspend_timer_fn would check to see if last_busy has changed and > restart the timer if needed.) Hmm. What exactly is going to be the purpose of this? > I'm not sure whether suspends initiated from pm_runtime_suspend > or pm_request_suspend should behave the same way. What do you think? I don't think they should at the moment, but that depends a good deal on the answer to the question above. :-) Thanks, Rafael -- 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
