> From: Lukas Wunner [mailto:lu...@wunner.de]
> Subject: Re: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the
> On Thu, Aug 10, 2017 at 12:34:23AM +0200, Rafael J. Wysocki wrote:
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -2139,6 +2139,10 @@ int __init acpi_scan_init(void)
> > acpi_get_spcr_uart_addr();
> > }
> > + acpi_gpe_apply_masked_gpes();
> > + acpi_update_all_gpes();
> > + acpi_ec_ecdt_start();
> > +
> > mutex_lock(&acpi_scan_lock);
> > /*
> > * Enumerate devices in the ACPI namespace.
> I notice this is called from a subsys_initcall(). We scan the PCI bus
> much earlier in arch/x86/kernel/early-quirks.c and it would be possible
> to identify presence of Thunderbolt host controllers in an early quirk
> (using the method of pci_is_thunderbolt_attached()) and, if found,
> enable their GPEs or all GPEs.
We have 2 choices here:
1. GPE is a part of device enumeration.
GPE must be enabled one by one after making sure that all related
bus/devices are powered on.
But it seems there is no such relationship between GPE and bus/device
in ACPI spec.
However if Windows works in this way, we'll regress by applying this
2. GPE is not a part of device enumeration.
Then probably we can even move GPE enabling into
acip_initialize_objects(), before calling
acpi_ns_initialize_devices(). As after preparing ACPI namespace,
_Lxx/_Exx is ready, and ACPI subsystem should be able to handle early
And ACPI subsystem's device enumeration starts from
So this patch should be correct in theory. ;)
Thanks and best regards
> Just as an aside in case your method doesn't work, I'm not affected by
> this issue being a Mac user... ;-)