Hi!

quoted

quoted

quoted

That, or there may be an additional value, say "aggressive", to write to the
control file in which case it becomes just

echo aggressive >/sys/.../power/control

That said I suppose that the "off" value for the "wakeup" file might also be
useful in some other cases, so it likely is a better approach.

We still need some sort of "inhibit" callback for cases where the
driver doesn't want to go into runtime suspend but does want to turn
off all I/O.  Should this callback be triggered when the user writes
"off" to power/wakeup, or when the user writes "inhibit" to
power/control, or should there be a separate sysfs attribute?

My first thought is that if there is a separate attribute, then it only actually
makes sense for devices that generate input events, while the "off" thing may
be generally useful in principle (eg. it may indicate to disable PME for the
device to the PCI layer etc).

OTOH, the additional "inhibit" attribute may only be exposed if the corresponding
callback is present, so I'm not really sure.

Question is, though, what's the use case for turning off I/O when we don't
go into runtime suspend.  After all, runtime suspend need not mean putting

Well... In "cellphone goes to pocket" case, you want to turn off I/O even if
the touchscreen can not support runtime suspend.

See parents in the thread for explanation.

									Pavel