Re: [linux-pm] [PATCH 3/5] [pm] Respect the actual device power states in sysfs interface

[Pavel Machek]

On Ne 19-02-06 16:17:01, Patrick Mochel wrote:
> 
> On Mon, 20 Feb 2006, Pavel Machek wrote:
> 
> > On Ne 19-02-06 15:59:25, Patrick Mochel wrote:
> > >
> > > On Sat, 18 Feb 2006, Pavel Machek wrote:
> > >
> > > > Hi!
> > > >
> > > > > Fix the per-device state file to respect the actual state that
> > > > > is reported by the device, or written to the file.
> > > >
> > > > Can we let "state" file die? You actually suggested that at one point.
> > > >
> > > > I do not think passing states in u32 is good idea. New interface that passes
> > > > state as string would probably be better.
> > >
> > > Yup, in the future that will be better. For now, let's work with what we
> > > got and fix 2.6.16 to be compatible with previous versions..
> >
> > It already is. It accepts "0" and "2" and "3". That's all values that
> > used to work.
> 
> The core should not dictate the valid range of values. The bus drivers
> should decide, since they are their states. "1" also used to work.

We are talking about hotfix. Maybe "1" used to work year ago, but not
in recent history. 0/2/3 seems to do for a hotfix.

> > If you add u32 into pm_message_t, it will be impossible to remove in
> > future.
> 
> I don't follow this argument either.
> 
> I really fail to see what your fundamental objection is. This restores
> compatability, makes the core simpler, and adds the ability to use the
> additional states, should drivers choose to implement them; all for
> relatively little code. It seems a like a good thing to me..

Compatibility is already restored.

Introducing additional states should be done in right way, something
we can keep long-term.
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
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/