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

From: Alan Stern
Date: Thu Jan 05 2006 - 16:36:37 EST


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/