Messages in this thread | | | Date | Mon, 20 Feb 2006 01:20:53 +0100 | From | Pavel Machek <> | Subject | Re: [linux-pm] [PATCH 3/5] [pm] Respect the actual device power states in sysfs interface |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |