Thread (53 messages) 53 messages, 11 authors, 2006-01-13

Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys interface

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2006-01-05 22:06:48
Also in: lkml

On Thu, 5 Jan 2006, Patrick Mochel wrote:
quoted
It would be good to make the details available so that they are there when
needed.  For instance, we might export "D0", "on", "D1", "D2", "D3", and
"suspend", treating "on" as a synonym for "D0" and "suspend" as a synonym
for "D3".
Do it in userspace; the kernel doesn't need to know about "on" or
"suspend". It should just validate and forward requests to enter specific
states.
The problem is that the set of devices, drivers, and states is not 
bounded.  A single userspace tool might not know about all the 
device-specific states some weird driver supports.  The tool should still 
be able to ask the kernel to suspend the device without needing to know 
exactly which device state corresponds to "suspended".


On Thu, 5 Jan 2006, Pavel Machek wrote:
Its okay with me to add more states _when they are needed_. Just now,
many drivers do not even handle system suspend/resume correctly.
We are not adding random crap to kernel just because "someone may need
it". And yes, having aliases counts as "random crap". Perfectly legal 
but totally useless things count as a random crap, too.

Bring example hardware that needs more than two states, implement
driver support for that, and then we can talk about adding more than
two states into core code.
Embedded devices are a great example.  Consider putting Linux on a 
portable phone.  The individual components can have many different power 
states, depending on which clock and power lines are enabled.  "on" and 
"suspend" won't be sufficient to handle the vendor's needs.

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help