Re: [PATCH v5] PCI: Detect and trust built-in Thunderbolt chips

[Lukas Wunner <lukas@wunner.de>]

On Tue, Oct 29, 2024 at 07:15:24PM -0500, Bjorn Helgaas wrote:
> I asked on the v4 patch whether we really need to make all this
> ACPI specific, and I'm still curious about that, since we don't
> actually use any ACPI interfaces directly.

The patch works around a deficiency in a Microsoft spec which is
specifically for ACPI-based systems, not devicetree-based systems:

   "ACPI Interface: Device Specific Data (_DSD) for PCIe Root Ports
    In Windows 10 (Version 1803), new ACPI _DSD methods have been added
    to support Modern Standby and PCI hot plug scenarios."

    https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports

The deficiency is that Microsoft says the ExternalFacingPort property
must be below the Root Port...

   "This ACPI object enables the operating system to identify externally
    exposed PCIe hierarchies, such as Thunderbolt. This object must be
    implemented in the Root Port ACPI device scope."

...but on the systems in question, external-facing ports do not
originate from the Root Port, but from Downstream Ports.
So there's the Root Port (with the external facing property),
below that an Upstream Port and below that a Downstream Port
(which is the actual external facing port).

I'm not sure if Windows on ARM systems use ACPI or devicetree.
I'm also not sure whether the Qualcomm SnapDragon SoCs they use
have Thunderbolt built-in, in which case they won't need a
discrete Thunderbolt controller.  If they don't use discrete
Thunderbolt controllers or if they don't use ACPI, they can't
exhibit the problem.

In any case I haven't heard of any Windows on ARM systems being
affected by the issue.

So it boils down to:  Should we compile the quirk in just in case
ARM-based ACPI systems with discrete Thunderbolt controllers and
problematic ACPI tables show up, or should we constrain it to x86,
which is the only known architecture that actually needs it right now.

My recommendation would be the latter because it's easy to move
code around in the tree, should other arches become affected,
but in the meantime we save memory and compile time on anything
not x86.

Thanks,

Lukas