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

Kai-Heng Feng
2022-08-17T14:38:10Z

On Wed, Aug 17, 2022 at 9:34 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> 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?

The AER happens at Physical Layer as soon as the device hit D3cold, so
I don't know what really happens at such low level.

Here's my proposed solution:
https://lore.kernel.org/linux-pci/20220727013255.269815-1-kai.heng.feng@canonical.com/

Anyway, it's just an example to show why I think it's better to
implement "dark resume" in kernel instead of deferring it to the
userspace.

Kai-Heng