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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
