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
