Re: [REGRESSION 5.0.8] Dell thunderbolt dock broken (xhci_hcd and thunderbolt)

[Furquan Shaikh]

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!