On Monday 24 July 2006 8:42 am, Alan Stern wrote: > > What I wrote wasn't necessarily intended to be different from what the > methods mean today. But it _is_ different from what people tend to think. > > It's very natural for someone to imagine that suspend() means "Suspend > your device" (i.e., put it in a low-power state) and resume() means > "Resume your device" (i.e., change it to full-power). But the real > emphasis is different; people need to know that suspend() actually means > "The _system_ is going to suspend" and resume() means "The _system_ is > resuming". Good point. I'll tweak the text to make that more explicit. We're in agreement it seems, and that was already written up ... but not in what I suspect is the best place for such points. > > > These meanings may not be entirely consistent with the way the PM core > > > works now, > > > > I don't believe any semantic change is being discussed here. > > There is. Right now suspend_device() won't call the bus's suspend method > if dev->power.power_state.event is non-zero. But since the purpose of the > call is to inform the driver that the _system_ is going to suspend, the > call should be made regardless of the _device's_ state (which the core > shouldn't be concerned with anyway). 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. > > Considering how few drivers use dev->power.power_state, it's easier to > > say the problem is in the ones that use it ... rather than the ones that > > ignore it and act as I've described above! :) > > I don't know to what extent there are problems in the drivers. Not much, > hopefully. The real problem lies in the core. Yes the core has the problem, but drivers referencing power_state is the workaround for that problem. 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. - Dave
