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
