Resending as my previous mail never made it to the PM mailing list. ------------------- Hi Rafael, I had a question on Idle notification in the runtime PM core. Is this function comment accurate - +/** + * __pm_runtime_idle - Notify device bus type if the device can be suspended. + * @dev: Device to notify the bus type about. + * + * This function must be called under dev->power.lock with interrupts disabled. + */ +static int __pm_runtime_idle(struct device *dev) I also do see that the in the pm_runtime.txt there is a mention - +The action performed by a bus type's ->runtime_idle() callback is totally +dependent on the bus type in question, but the expected and recommended action +is to check if the device can be suspended (i.e. if all of the conditions +necessary for suspending the device are satisfied) and to queue up a suspend +request for the device in that case. If this is the case, are the below checks in __pm_runtime_idle and __pm_request_idle suggested? In __pm_runtime_idle + || dev->power.runtime_status != RPM_ACTIVE) + retval = -EAGAIN; In __pm_request_idle + || dev->power.runtime_status == RPM_SUSPENDED + retval = -EAGAIN; Shouldn't we just return success if power.runtime_status == RPM_SUSPENDED? I know it does not make a difference in the runtime PM core as return value for the idle callbacks are never checked. But what if someone wants to use idle callback API explicitly? Note: I am not very sure if returning success is also a clean solution, I am just trying to understand what might be the right thing to in this scenario. Regards, Nithish Mahalingam _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
