On Sat, 4 Sep 2010, Rafael J. Wysocki wrote: > > while. (There's also a notion of an "energy break-even" time.) > > That's correct, but people are considering using PM QoS for this purpose. When applied to an individual device, it can be considered a runtime-PM concept. Ultimately these two separate things will have to cooperate somehow... > > Until now, a subsystem or driver wanting to do this has had to handle > > all the details on its own: keeping track of when the device was last > > used, computing how long the device should remain idle, allowing the > > user to set the idle-delay value, and so on. The patch merely moves > > all these pesky details into the PM core. > > That's fine, but I think there are situations in which las_busy/suspend_delay > are simply not useful. That's why it's off by default and there are function calls by which a subsystem/driver can turn it on and off. In general, I don't expect these changes to happen very frequently. At least, no more frequently than the user changes the card in a card reader or changes the network cable going to an Ethernet adapter. > > That's why I think using "autosuspend" in the name isn't so good. > > This stuff is centered around the idea of implementing delays, not > > automatically suspending. > > That depends on what you mean by "automatic suspending". To me, "automatic > suspend" means exactly "suspend after certain period of inactivity", but there > are other situations in which runtime PM is applicable (eg. the "cable not > present" case). What the patch provides could more accurately be described as "don't allow suspend until a certain period of inactivity has elapsed". That isn't the same as "suspend after a certain period of inactivity". > > In view of these thoughts, do you have any suggestions for the names of > > the new functions? > > Well, I guess we first need to clarify the terminology. :-) Better now than later! 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
