Re: Runtime PM: Calling Device runtime PM callbacks?

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Monday 14 December 2009, Alan Stern wrote:
> On Mon, 14 Dec 2009, Rafael J. Wysocki wrote:
> 
> > On Monday 14 December 2009, Alan Stern wrote:
> > > On Mon, 14 Dec 2009, Rafael J. Wysocki wrote:
> > > 
> > > > There you go (untested for now).
> > > > 
> > > > ->runtime_idle() is still only called for the device's bus type, because
> > > > otherwise it will be hard to determine the right ordering of the bus type,
> > > > device type and device class callbacks.
> > > 
> > > Shouldn't it be the same as runtime_suspend and runtime_resume?
> > 
> > Well, the ordering is different in each of them ...
> 
> Why not just copy the order used by device_suspend(): class, then type,
> then bus?

Do you mean in _idle?

> Actually, I don't know of any cases where the order matters.  But there 
> may be some, for system suspend.  Runtime suspend is new enough that 
> people will adapt.

Still, calling them in the reverse order in resume is kind of logical ...

> > > What's the reason for error_ptr here?  Its value will always be the
> > > same as the return value except in the case where none of the callbacks
> > > are defined.  Why not just use -ENOSYS in that case and eliminate
> > > error_ptr?
> > 
> > To preserve the existing logic.
> > 
> > Namely, without the patch dev->power.runtime error is not updated in the
> > -ENOSYS case and that actually is for a reason (we don't want runtime_error to
> > be set merely because there's no callbacks to execute).  I could check the
> > return value, but what if one of the callbacks returns -ENOSYS?
> 
> Don't worry about it.  -ENOSYS means the operation isn't implemented.  
> So if somebody's method implementation tells you that the method isn't 
> implemented, they'll get what they deserve.  :-)

OK

Rafael