On Tuesday, July 14, 2015 09:34:08 AM Nitish Ambastha wrote: > On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki <r...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
