> I'm talking about an array of device states the device supports. They
> would be exporting them to userspace for the purpose of device power
> management. While it's related to the device states a driver supports,
> it's not exactly the same thing.
I would have a single array. Just use a flag in there to mark the ones
that are visible to userspace.
> You want to expose only the mutual set of those sets (the states the
> device and the driver both support) on a per-device basis. The easiest way
> to do that would be with a per-device array. You could do it with a
> per-driver array, but in the case where a driver supports different revs
> of a chip with different power management capabilities, you'd have to
> constantly check what rev of the chip you're using..
Too many arrays, we are going to complicate the driver-side of the model
too much. I'm thinking more about an array that can be pointed to
statically from the driver structure (which is usually static as well).
This is important for a reason: Devices may be added to a part of the
tree that is in a low power state. So the actual "state" upon probe() is
_not_ necessarily the "main" power state. The core must be able to
resolve the state dependency at device add time before probe I think, or
at least know what value to put in "current state" before probe(), so
the driver can eventually try to clamp the state up on the parent if it
needs more power to initialize itself.
Something like
struct pm_state_list my_states = {
{ "running", PM_STATE_USER, .... <whatever else> },
{ "snoozing", PM_STATE_USER, .... <whatever else> },
{ "suspended", PM_STATE_USER, .... <whatever else> },
};
struct pci_driver my_driver = {
.../...
dev.pm_states = &my_states;
};
The above array is just a random example, we definitely have to work
more on the defintion of a state. In that example, we have the state
name and a flags word, PM_STATE_USER indicating the state can be set by
the user.
Ben.
