Hi! > > > > > 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. And do we really want user writing D2 to /sys file? > 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? Because device may enter different hw states for different flags? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
