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

[Greg KH]

On Mon, Feb 20, 2006 at 09:58:27AM -0800, Patrick Mochel wrote:
> 
> On Sun, 19 Feb 2006, Greg KH wrote:
> 
> > On Sun, Feb 19, 2006 at 03:59:25PM -0800, 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's _way_ too late in the 2.6.16 cycle for this series of patches, if
> > that is what you are proposing.
> 
> Would you mind commmenting on why, as well as your opinion on the validity
> of the patches themselves?
> 
> This static, hardcoded policy was introduced into the core ~2 weeks ago,
> and it doesn't seem like it belongs there at all.

That patch was accepted as it fixed a oops.  It also went in for
2.6.16-rc2, which is much earlier than 2.6.16-rc4, and it had been in
the -mm tree for quite a while for people to test it out and verify that
it didn't break anything.  I didn't hear any complaints about it, so
that is why it went in.

In contrast, this patch series creates a new api and doesn't necessarily
fix any reported bugs.  It also has not had the time to be tested in the
-mm tree, and there is quite a lot of disagreement about the patches on
the lists.  All of that combinded makes it not acceptable for so late in
the -rc cycle (remember, -rc4 means only serious bug fixes.)

> This seems like the easiest way to fixing it, but I'm open to
> alternative suggestions..

Care to resend the series based on all of the comments you have
addressed so far?  I'll be glad to review it then.

thanks,

greg k-h
-
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/