Re: Nested suspends; messages vs. states

Alan Stern
2005-03-22T03:08:10Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1258 bytes --]

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