"Rafael J. Wysocki" <rjw@xxxxxxx> writes: > On Friday, June 17, 2011, Alan Stern wrote: >> On Tue, 14 Jun 2011, Rafael J. Wysocki wrote: >> >> > > Then you suggest: >> > > >> > > Call pm_runtime_disable after .suspend; >> > > >> > > Call pm_runtime_get_noresume and pm_runtime_enable before >> > > .resume; >> > > >> > > Call pm_runtime_put_sync after .complete. >> > > >> > > Right? >> > >> > Yes, that would be resonable IMO. >> >> This turns out to be harder than it looks. If an error occurs, we may >> run the complete callback for devices that never were suspended or >> resumed and hence never had their usage_count incremented. How can we >> tell that we need to skip the pm_runtime_put_sync for these devices? >> >> Would it be okay to call pm_runtime_put_sync immediately after the >> resume callback instead of after complete? > > Yes, it would. > > That said we may be better off by simply reverting commit > e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to > succeed during system suspend). I'm OK with blocking runtime PM requests after .suspend (and unblocking before .resume) e.g. protecting the _noirq callbacks, but I hope we don't have to go back to blocking them before .prepare (and unblocking after .complete) Kevin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
