Hi Rafael, Sorry if this question has been raised before. I actually have two questions here. These questions are related to PM runtime being disabled at runtime (i.e. call to pm_runtime_disable() ) If I call pm_runtime_enabled() to first determine if PM runtime is enabled followed conditionally by a call to pm_runtime_get_sync(), it would be possible for PM runtime to be disabled between these two calls and the get_sync() will fail. Is there any reason to even use the enabled() call? My goal here was to use the enabled() call to determine if PM runtime was configured/enabled in the kernel and then to manage my resources, clocks etc, in a different way if PM runtime is not present. My second question then is what if PM runtime is enabled in the kernel and then gets disabled at runtime. What is the expected behavior for a driver? Should it fail all requests with EGAIN until PM runtime is enabled again? (in suspend state, PM runtime gets disable, new i/o request is made, power and clocks need to be turned on). What about delayed autosuspend? I believe that if PM runtime is disabled while there is a delayed autosuspend pending, the suspend will fail without notification (clocks and power will be left on). Will PM runtime still be in the idle state once PM runtime is re-enabled? thanks, Ken -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
