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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 5 Jan 2006, Pavel Machek wrote:

> > > | Why to make it this complex?
> > > | 
> > > | I do not think there's any confusion possible. "on" always corresponds
> > > | to "D0", and "suspend" is "D3". Anyone who knows what "D2" means,
> > > | should know that, too...
> > 
> > Not necessarily.  For instance, a particular driver might want to map 
> > "suspend" to D1 instead of to D3.
> 
> Ok, lets change that to "on" and "off". That way, hopefully all the
> drivers will agree that "off" means as low Dstate as possible.

Nothing wrong with that.  We could let "off" be another synonym.  Although 
I don't see the need for it, really.

> > Given that "on" and "suspend" are generic names and not actual states (at 
> > least, not for PCI devices and presumably not for others as well), I think 
> > it makes sense to treat them specially.
> > 
> > And it's not all that complex.  Certainly no more complex than forcing
> > userspace tools to use {"on", "D1, "D2", "suspend"} instead of the
> > much-more-logical {"D0", "D1", "D2", "D3"}.
> 
> It is not much more logical. First, noone really needs D1 and
> D2. Plus, people want to turn their devices on and off, and don't want
> and should not have to care about details like D1.

Who are you to say what people really need?  What about people who want to 
test their PCI device and see if it behaves properly in D1 or D2?  How are 
they going to do that if you don't let them put it in that state?

What about people with platform-specific non-PCI devices that have a whole
bunch of different internal power states?  Why force them to use only two
of those states?

The kernel isn't supposed to prevent people from doing perfectly legal
things.  The kernel should provide mechanisms to help people do what they
want.

Besides, as long as the sysfs interface accepts "on" and "suspend" (or 
"off"), what harm does it do to accept the device-specific names as 
well?

Alan Stern


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux