Re: RFC -- updated Documentation/power/devices.txt

[David Brownell <david-b@pacbell.net>]

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