On Mon, 24 Jul 2006, David Brownell wrote: > OK, _now_ we're discussing a semantic change. ;) > > I've added dev->power.power_state to the "this is deprecated" text, along > with the sysfs power/state file. IMO we can't realistically make that change > (removing the "is it nonzero" test) so long as the sysfs mechanism exists. All right, I can accept that. A fundamental problem is that echo -n 2 >/sys/devices/.../power/state calls the driver's suspend() method, thereby telling it that the system as a whole is going to be suspended. It's an unfortunate overloading of meanings. Is it too early to start thinking about replacements for .../power/state in individual subsystems? Is that attribute file currently used anywhere outside of PCMCIA (other than for testing)? The sooner a safe replacement is provided for such uses, the better. > Once the sysfs mechanism goes away, there won't be much need for the mechanism. > Only callers to dpm_runtime_*() would trigger any of the troublesome paths. > The two callers are USB and PCMCIA, and I'm not sure they really need the extra > lock that's grabbed by the dpm_runtime_*() calls if there's no need to protect > against that sysfs mechanism. My autosuspend patches remove the dpm_runtime_* stuff from USB, leaving only PCMCIA. The "extra lock" you refer to is dpm_sem? I'm not quite sure why it's there at all... Apparently all it does is attempt to prevent runtime PM requests from being made while a system suspend/resume transition is in progress. But it's futile to try doing this from within the core, if drivers are going to be managing device states internally. (Not to mention that a task waiting on dpm_sem will cause the "freeze processes" procedure to fail.) And it's not clear that we _do_ want to prevent runtime PM changes from occurring during a system sleep transition. If a remote-wakeup request arrives while the system is suspending, it ought to be legal for the request to succeed and thereby abort the transition. Alan Stern
