Re: How to get "wake up reason" for Suspend-to-Idle

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Aug 17, 2022 at 08:53:00PM +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 6:30 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Hi,
> >
> > On Wed, Aug 17, 2022 at 03:08:18PM +0800, Kai-Heng Feng wrote:
> > > We are seeing laptops wake up when Thunderbolt dock gets plugged, or
> > > even wake up on AC plugging.
> > >
> > > On Windows these events are logged with "Wakeup Reason", and if the
> > > wakeup event is from unplugging AC, the system will be put to suspend
> > > again.
> > >
> > > So I wonder if it's possible to get the "Wakeup Reason" under Linux?
> > >
> > > '/sys/power/wakeup_count' seems to be insufficient for this purpose.
> >
> > I don't know if there is a way but unfortunately several systems (or
> > their firmware) are expecting Windows style "dark resume" so they pretty
> > much wake up each time something gets plugged or even unplugged to these
> > ports. Linux does not have similar mechanism at the moment but I think
> > at least if you have lid closed it will eventually go back to s2idle.
> 
> ChromeOS also developed their own version of dark resume [1], which
> checks  '/sys/power/wakeup_count' to decide if the system should go
> back to suspend again.

Right.

> However, if there's any spurious wakeup event occurs during s2idle
> like [2], checking 'wakeup_count' alone will put the system back to
> suspend, and the system will stuck in a wakeup/suspend loop.
> 
> So I think it's safer to implement the mechanism in the kernel, by
> implementing .suspend_again() callback for s2idle just like what S3
> does.
> However, to make the right decision on suspend or wakeup we need a
> concrete "wakeup reason", but I wonder how do we achieve that?
> 
> [1] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=216295

Do we know why the AER event happens in the first place? I think that's
where we should look first. Perhaps there is something missing int the
Linux AER implementation that causes this?