Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCHv3 1/1] kernel/power/autosleep.c: check for pm_suspend() return before queueing suspend again | Date | Thu, 16 Jul 2015 00:29:25 +0200 |
| |
On Tuesday, July 14, 2015 09:34:08 AM Nitish Ambastha wrote: > On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote: > >> Prevent tight loop for suspend-resume when some > >> devices failed to suspend > > > > This *still* doesn't explain what problem you're *really* trying to address. > > > > Even if a driver returns an error code from one of its suspend callbacks, > > you should get final_count == initial_count in the final check and we'll > > schedule the timeout. > > > > So there is a failure scenarion you're trying to address where that check is > > not sufficient, but you're not saying what the scenario is. > > > As I mentioned earlier, if some driver failed to suspend, and during > resume if *somebody* called pm_stay_awake() or pm_wakeup_event() > meantime, and then pm_relax(), final_count and initial_count will not > be the same in try_to_suspend(). We observed this behavior with > battery monitor thread on being restarted
But that means there was a valid wakeup event, doesn't it?
> In these scenarios, it will be considered a *valid wakeup* event and > it will try to queue suspend immediately, though the actual reason of > resume was driver returning error code.
Even if a wakeup event occurs in addition to a driver failing the suspend, it is still valid.
So it looks like you want to schedule the timeout unconditionally in case of a failed suspend, but then you need to filter out -EBUSY (which is returned on valid wakeup events). Essentially, that would slow down autosleep, but how does that help exactly?
Thanks, Rafael
| |