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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Oct 30, 2024 at 12:11:33PM +0100, Lukas Wunner wrote:
> 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.

Well they can do whatever they want without us knowing ;-) This problem
does not happen even in x86 Windows probably because they do something
similar than this patch.

> 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.

IMHO this should be made generic enough that allows device tree based
systems to take advantage of this right from the get-go. Note also there
is already "external-facing" device tree property that matches the ACPI
one defined in Documentation/devicetree/bindings/pci/pci.txt.