linux-kernel - Re: [PATCH] drivers/acpi: Clear status of an event before enabling it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jPJYM6n0OWBM17d3MF5h5B+an+LSRiXTHqboXZuXkcvw@mail.gmail.com>
Date:   Thu, 28 Mar 2019 09:57:18 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Furquan Shaikh <furquan@...gle.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Robert Moore <robert.moore@...el.com>,
        "Schmauss, Erik" <erik.schmauss@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        devel@...ica.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rajat Jain <rajatja@...gle.com>,
        Evan Green <evgreen@...gle.com>,
        Duncan Laurie <dlaurie@...gle.com>
Subject: Re: [PATCH] drivers/acpi: Clear status of an event before enabling it

On Thu, Mar 28, 2019 at 1:46 AM Furquan Shaikh <furquan@...gle.com> wrote:
>
> On Wed, Mar 27, 2019 at 5:24 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh <furquan@...gle.com> wrote:
> > >
> > > On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > >
> > > > On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh <furquan@...gle.com> wrote:
> > > > >
> > > > > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > > > > clearing ACPI IRQs during suspend/resume") was added to stop clearing
> > > > > of event status bits unconditionally on suspend and resume paths. This
> > > > > was done because of an issue
> > > > > reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> > > > > lid status stays closed even on resume (which happens because event
> > > > > status bits are cleared unconditionally on resume). Though this change
> > > > > fixed the issue on suspend path, it introduced regressions on several
> > > > > resume paths.
> > > > >
> > > > > First regression was reported and fixed on S5 path by the following
> > > > > change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> > > > > entering S5"). Next regression was reported and fixed on all legacy
> > > > > sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> > > > > events when entering sleep states"). However, regression still exists
> > > > > on S0ix sleep path since it does not follow the legacy sleep path.
> > > >
> > > > What exactly is failing?
> > >
> > > Here is the failure scenario:
> > >
> > > 1. Consider the case of trackpad which acts as a wake source.
> > > 2. Since the pad is configured for SCI, GPE_STS gets set for that pad
> > > during normal interrupts as well (i.e. during probe at boot or when
> > > using the trackpad)
> >
> > I don't quite understand this.
> >
> > Is the same GPE used for signaling trackpad events in the system
> > working state and for wakeup?
>
> Yes. The same pad is being configured for interrupts (i.e. routed to
> APIC) during S0 as well as configured for GPE (i.e. routed for SCI) to
> cause wakes when in S0ix/S3. This pad is externally connected to
> trackpad interrupt line.

And the way the system is wired up causes the GPE status to be set
when it is enabled, I suppose?

So effectively, you need to disable the active-state IRQ, then clear
the GPE status and enable it for wakeup.

OK, I'll queue up the patch (and talk to the upstream ACPICA people
about taking it in there).

Thanks!