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

[Lukas Wunner <lukas@wunner.de>]

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

I meant Linux on "Windows on ARM" machines. :)

This article claims that UEFI+ACPI is used to boot Windows,
but Qualcomm recommends devicetree is used for Linux:

https://www.heise.de/en/news/Snapdragon-X-notebooks-Ditch-Windows-Install-Linux-9781461.html


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

The workaround implemented by Esther's patch (only) becomes necessary
because OEMs followed Microsoft's spec blindly and put the property
below the Root Port, instead of the Downstream Port.

Devicetree-based systems are not bound by Microsoft's spec, so do not
*have* to fall into the same trap.

Thanks,

Lukas