Thanks for the explanation! I still don't fully understand how that would work for my use case. Perhaps it would be better for me to describe the case I am trying to protect against. To rehash, this quirk was written for devices with discrete Thunderbolt controllers. For example, CometLake_CPU -> AlpineRidge_Chip -> USB-C Port This device has the ExternalFacingPort property in ACPI. My quirk relabels the Alpine Ridge chip as "fixed" and external-facing, so that devices attached to the USB-C port could be labeled as "removable" Let's say we have a TigerLake CPU, which has integrated Thunderbolt/USB4 capabilities: TigerLake_ThunderboltCPU -> USB-C Port This device also has the ExternalFacingPort property in ACPI and lacks the usb4-host-interface property in the ACPI. My worry is that someone could take an Alpine Ridge Chip Thunderbolt Dock and attach it to the TigerLake CPU TigerLake_ThunderboltCPU -> USB-C Port -> AlpineRidge_Dock If that were to happen, this quirk would incorrectly label the Alpine Ridge Dock as "fixed" instead of "removable". My thinking was that we could prevent this scenario from occurring if we filtered this quirk not to apply on CPU's like Tiger Lake, with integrated Thunderbolt/USB4 capabilities. ExternalFacingPort is found both on the Comet Lake ACPI and also on the Tiger Lake ACPI. So I can't use that to distinguish between CPUs which don't have integrated Thunderbolt, like Comet Lake, and CPUs with integrated Thunderbolt, like Tiger Lake. I am looking for something that can tell me if the device's Root Port has the Thunderbolt controller upstream to it or not. Is there anything like that? Or perhaps should I add a check which compares the name of the device's CPU with a list of CPUs that this quirk can be applied to? Or is there some way I can identify the Thunderbolt controller, then determine if it's upstream or downstream from the root port? Or are Alpine Ridge docks not something to worry about at all?
