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

[Furquan Shaikh]

On Thu, May 2, 2019 at 4:48 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Apr 30, 2019 at 11:37:48AM +0200, Rafael J. Wysocki wrote:
> > On Tue, Apr 30, 2019 at 11:00 AM Mika Westerberg
> > <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> > >
> > > +Rafael, Furquan and linux-acpi
> > >
> > > (The original thread is here https://lore.kernel.org/lkml/s5hy33siofw.wl-tiwai@xxxxxxx/T/#u)
> > >
> > > On Tue, Apr 30, 2019 at 10:39:00AM +0200, Michael Hirmke wrote:
> > > > Hi Takashi,
> > > >
> > > > [...]
> > > > >>> I also have XPS 9370 but not that particular dock. I will check tomorrow
> > > > >>> if I can reproduce it as well.
> > > > >>
> > > > >> There aren't too many changes between 5.0.7 and 5.0.8 that touch
> > > > >> PCI/ACPI. This is just a shot in the dark but could you try to revert:
> > > > >>
> > > > >>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gi
> > > > >>   t/commit/?h=linux-5.0.y&id=da6a87fb0ad43ae811519d2e0aa325c7f792b13a
> > > > >>
> > > > >> and see if it makes any difference?
> > > >
> > > > >OK, I'm building a test kernel package with the revert in OBS
> > > > >home:tiwai:bsc1133486 repo.  A new kernel will be
> > > > >kernel-default-5.0.10-*g8edeab8:
> > > > >  http://download.opensuse.org/repositories/home:/tiwai:/bsc1133486/standard/
> > > >
> > > > >Michael, once when the new kernel is ready, please give it a try.
> > > >
> > > > as far as I can see, state is back to normal with this kernel.
> > > > No more error messages or crashing modules and all devices seem to work
> > > > as expected.
> > > > Only thing is, that the external devices connected to the Thunderbolt
> > > > dock are coming up a little bit slower than with 5.0.7 - but this is
> > > > nothing, I'd worry about.
> > >
> > > Thanks for testing.
> > >
> > > Rafael, it seems that commit c8b1917c8987 ("ACPICA: Clear status of GPEs
> > > before enabling them") causes problem with Thunderbolt controllers if
> > > you boot with device (dock) connected.
> > >
> > > I think the reason is the same that got fixed in v4.14 with commit
> > > ecc1165b8b74 ("ACPICA: Dispatch active GPEs at init time") which the
> > > above commit essentially undoes if I understand it correctly.
> >
> > OK, I'll queue up a revert of that one then, thanks!
> >
> > Erik, I think that commit c8b1917c8987 has been picked up by the
> > upstream ACPICA already.  If I'm not mistaken, it needs to be reverted
> > from there as well.
>
> I've queued the revert up in the stable trees as it has hit Linus's tree
> now, and will push out a new round of stable kernels soon.
>
> thanks,
>
> greg k-h

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?

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?