> If you leave the decision-making entirely up to the drivers, and expose > through sysfs only the name entries of your state tables, then the rest of > the table is unnecessary and you end up with something very much like what > we have been discussing all along. Hrm... my idea was to have a way to expose all possible driver states to sysfs, which could still be kept around. And it allows to move the decision making to common code in 99% of the cases, actually simplifying the drivers... but I need to think more about it. It could be something added on top of the exisiting mecaism instead, as a sort of "helper". What about that so: - fix sysfs "power" entry thing so that it actually calls to device hooks: get_power_states() return a list of possible power states (which is then exposed in sysfs) and set_power_state() which takes a string and is called with whatever the user echo'ed in there. That is the basic optional interface for drivers wanting to expose power states to userspace. By default, nothing is provided, thus either we don't expose the sysfs entries at all, or we put some "compat" stuff in there that turns those calls into suspend/resume calls but I'm not too hot. - provide "helper" get/set power state (and eventually suspend/resume) even that can be used and that will use a table with state name, some flags, and rather than the set of stuff i described, a function pointer to enter the state (which returns the actual state that was entered, so the function can decide to do otherwise) Anyway, that's just thought for the future. I agree with Pavel on the need to push the existing stuffs to 2.6.11 asap, we have other things to fix, like the problem of random subsystem blocking on GFP_KERNEL allocation and bad times, or call_usermodehelper beeing abused while userland is offline, etc... Ben.
