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.
