On Mon, 21 Mar 2005, Pavel Machek wrote: > > > > Obviously a message isn't the same thing as a state. This looks like > > > > something that will need to be changed in a lot of drivers when we > > > > introduce the new notion of a power state. > > > > > > This is not so obvious to me. Message seems to represent the state > > > driver is in quite well... Plus we need PMSG_ON for state the device > > > gets after resume, but that's quite easy... > > > > So what value for power_state do you use to tell apart PCI D1 from D2? > > You just ask via pci_choose_state(), and it tells > you... pci_choose_state() should be deterministic. That's useless for sysfs. It won't know to call pci_choose_state when it has to display the device's current power state in an attribute file. Nor will it know what pm_message_t to send the driver when the user writes the string "D2" to the attribute. Even just from first principles the mistake is apparent. pm_message_t is (or will be, when the structure is defined in its final form) a _message_, not a _state_. It contains (will contain) things other than the power state setting, such as the "flags" field. Why would a device want to store pm_message_t.flags as part of its current state? Alan Stern
