On Tue, 15 Dec 2009, Rafael J. Wysocki wrote: > > Idle is very similar to suspend. They should use the same order. > > > > I guess there's one extra thing to look out for: If one of the idle > > callbacks does pm_runtime_suspend() then there's no point invoking the > > later callbacks. > > But how do we know that? How do we know whether the callback does pm_runtime_suspend()? Because dev->runtime_status changes to RPM_SUSPENDED. How do we know there's no point invoking the later callbacks? Because an idle callback is merely supposed to decide whether or not to suspend the device. If the device is already suspended then the callback's job is already done. > I'm still not sure what actually the point executing _idle for device types and > device classes is. The only situation I can aticipate if when there's a device > without a bus type. In the USB stack we have "devices" and "interfaces", two different device types (both belonging to the USB bus type). They need to have separate callbacks. The device idle callback will do a bunch of testing, whereas the interface idle callback will always invoke pm_runtime_suspend() immediately. > Hmm. Actually, are we ever going to call two or more suspend callbacks (ie. > bus type one and device type one or device type one and device class one) > for the same device? If not, we'll be able to simplify things significantly > by making them mutually exclusive (ie. if there's bus type, call bus type, > or else if there's device type, call device type, or else if there's device > class, call device class). I don't plan ever to have more than one callback. But I can't speak for other parts of the kernel. The situation should be very much the same as with the DPM callbacks. They could make the same assumption. Or neither should make it -- as the case may be. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
