linux-kernel - [PATCH 0/3] acpi: GPE fixes

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: <4881D205.1000901@tuffmail.co.uk>
Date:	Sat, 19 Jul 2008 12:37:41 +0100
From:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
To:	Alexey Starikovskiy <astarikovskiy@...e.de>
CC:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] acpi: GPE fixes

Here's what I came up with -

1.  I was fighting against EC_FLAGS_QUERY_PENDING.  This was used to ignore
    multiple successive GPE interrupts and treat them as a single GPE instead.
    That's the exact opposite of what we want to do.  Let's get rid of it.

2.  Then we can apply my original patch to fix GPE polling on the Asus EeePC,
    by repeatedly querying for GPEs until there are none left.

3.  Finally, if I'm right then we now know how to handle "GPE interrupt storms".
    Some EC's are raising multiple interrupts before we acknowledge them. but
    they're just telling us how many events are pending.  There's no harm in
    that, so we don't ever need to disable GPE interrupts.  Let's get rid of
    GPE polling mode.  (Code mainly stolen from Alexey).

Patch 3 would benefit from wider testing.  Fortunately there are several open
bugs about GPEs so it should be easy to find testers :-).

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/