Hi, On Thu, Apr 25, 2024 at 05:16:24PM -0400, Esther Shimanovich wrote: > Thank you for all your help! > > On Tue, Apr 23, 2024 at 1:33 AM Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > > The other way I think is something like this: > > > > - If it does not have "usb4-host-interface" property (or behind a port > > that has that). These are all tunneled (e.g virtual). > > > > - It is directly connected to a PCIe root port with > > "ExternalFacingPort" and it has sibling device that is "Thunderbolt > > NHI". This is because you can only have "NHI" on a host router > > according to the USB4 spec. > > > I did find one example of a docking station that uses the DSL6540 > chip, which has PCI IDs defined in include/linux/pci_ids.h: > #define PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_NHI 0x1577 > #define PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE 0x1578 > It seems like it has an NHI, despite being in an external, removable > docking station. This appears to contradict what you say about only > having "NHI" on a host router. I am assuming that by host router, you > mean the fixed discrete, fixed thunderbolt chip, or the thunderbolt > controller upstream to the root port. Please correct me if I got > anything wrong! So it goes same way with other discrete chips from Intel at least. It is the same silicon but the NHI is disabled on device routers. That said, it is entirely possible for a "malicious" device to pretend to have one so we need to be careful. > Looking at 18-241_ThunderboltController_Brief_HI.pdf, it seems like > these Alpine Ridge chips can be used either on a computer or a > peripheral. (Expected usage: Computer or peripheral) Yes as above. Most our chips are such. > So I'm not sure if finding an NHI would guarantee that the device is > not a peripheral. My original question was how to distinguish a > Thunderbolt controller that is on a removable peripheral, like a > docking station-- from one that is a discrete chip fixed to a computer > or upstream to the root port. Yes that's the problem. We can figure that out from full USB4 system by looking at the "usb4-host-interface" ACPI _DSD properties of the tunneled PCIe Root/Downstream ports. But this does not work with the pre-USB4 hosts so that requires some sort of heuristics, unfortunately. > So unless I am misunderstanding something, it appears that my only > option is waiting for Lukas's patches. Please correct me if that is > not the case! I think with Lukas' patches (Lukas please correct me if I got that wrong) you can find out the PCIe ports which have their link going over a tunnel. His series works with pre-USB4 devices so that should cover your case. (In addition to "usb4-host-interface" ACPI _DSD property there is a special router operation that allows extracting the same PCIe downstream port mapping that Lukas' patches are doing from DROM so this should also allow identify all tunneled links.) This way you can identify the xHCI (well and NHI) that are not behind PCIe tunnel so that should mean they are really part of the host system (being soldered or plugged to the PCIe slot or so). If I understood right this is what you were looking for, correct?
