lkml.org 
[lkml]   [2006]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-pm] [PATCH 3/5] [pm] Respect the actual device power states in sysfs interface

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.

> Other values used to trigger BUG() in pci.c (and we do not want to
> re-introduce _that_ behaviour, right?).

I don't follow - the BUG() call was introduced recently for reasons
unknown. The interface had never triggered that previously.

> 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..

Thanks,


Pat

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

\
 
 \ /
  Last update: 2006-02-20 01:19    [W:0.323 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site