acpi: GPE fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | acpi: Rip out EC_FLAGS_QUERY_PENDING (prevent race condition)drivers/ | +2 | 4 replies | |
| 2/3 | acpi: Avoid dropping rapid GPEs on Asus EeePC and othersdrivers/ | +13 | 0 replies | |
| 3/3 | acpi: remove GPE pollingdrivers/ | +1 | 0 replies |
Reviews trailers per patch
None of the 3 patches has a Reviewed-by or Acked-by.
| Patch | Alan Jenkins |
|---|---|
| 1/3 | T-b |
| 2/3 | T-b |
| 3/3 | T-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [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