Comment 11 for bug 1726299

(In reply to Bjorn Helgaas from comment #2)
> Thanks, Lukas. Help me understand the scenario here. It looks like the
> adapter was hot-added.

In the dmesg output it can be seen that the adapter was present on boot, then unplugged and replugged. This is also what Acelan Kao wrote above.

> If the firmware is responsible for configuring
> things behind the adapter, there must be a hook where firmware gets invoked.
> Is the ACPI Bus Check event that hook? Does that mean we must use acpiphp
> (not pciehp) to support these Thunderbolt devices?

I'm only familiar with the situation on Macs, where all of this happens natively: There's an EFI driver to configure tunnels to devices already attached on boot, and there's an OS driver which takes over after ExitBootServices. These drivers recognize when a Thunderbolt device is hotplugged and set up PCI- and DisplayPort-tunnels. Once a PCI-tunnel is set up, pciehp sees a hotplug event. It's important to understand this distinction because most people think Thunderbolt is just PCIe to external devices: It's a packet switching technology and one has to set up PCIe tunnels to actually communicate with devices. Think of it like an MPLS path.

On non-Macs the tunnels are set up by a firmware component dubbed Intel Connection Manager which runs in System Management Mode. When a device is hotplugged, somehow an SCI occurs and the ICM code is executed. To the best of my knowledge, PCI devices are *not* handled by pciehp but by acpiphp.

To make matters even more complicated, Macs newer than 2015 that are booted with Windows will reconfigure the Thunderbolt controller to be managed by ICM rather than natively. This is done by AML code in the DSDT, it writes to a number of MMIO registers of the Thunderbolt controller.

All of this is almost completely undocumented. There's some introductory docs at Apple:
https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/Basics/Basics.html

Other than that I think the only public source are various Thunderbolt-related patents by Intel, Apple et al.

> I'm trying to figure out
> if we can log more intelligent messages for this situation. The current
> stuff in dmesg is pretty hard to interpret.

It's kind of hard to improve them as we know so little about all that. :-(