On Sun, May 5, 2019 at 11:45 PM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Fri, May 03, 2019 at 04:35:02PM -0700, Furquan Shaikh wrote: > > Thanks for reporting the issue and apologize for the breakage. When I > > pushed the patch, my understanding was that the device drivers do not > > depend on stale GPE events to take any action. > > > > I am curious to understand the behavior for the thunderbolt device > > since I do not have one to test with. The failure seems to be a result > > of either having a edge-triggered interrupt or a pulse interrupt which > > indicates some kind of ready condition to the kernel driver. All the > > runtime GPEs seem to be initialized as part of acpi_init before ACPI > > bus is scanned. So, is this some special kind of requirement for > > thunderbolt that requires GPE enabled before the device can actually > > be probed. And so the GPEs going active before being enabled are then > > used as a way to call into ACPI Method to enable something which is > > essential for probing of device? > > IIRC the idea is that when you boot with a TBT device connected (this is > only for the BIOS assisted/ACPI enumeration mode) the Thunderbolt host > router (the device with PCIe switch + xHCI + NHI) is configured in two > phases. The basic configuration is done in the ASL code that then waits > for a synchronization event (signal) from the SMI hotplug handler that > allows it to continue. The GPE which can be either edge or level is then > used to call the SMI hotplug handler to initialize the host router and > its resources properly. > > If this is not done the PCI stack finds the host router half-configured > causing the failure. Thanks for the explanation! > > > The other question I have is given that handling of GPE events that > > were active before being enabled is required at least for some set of > > devices (e.g. thunderbolt), what is a good way to solve the original > > problem that was being addressed by the patch being reverted i.e. > > stale events resulting in spurious wakes on wakeup GPEs. One way I can > > think of is clearing the status of GPEs when they are setup for > > wake(acpi_setup_gpe_for_wake). What do you think? > > Sounds good to me. I will work on this and test it out to see how it goes. Thanks!
