- Jul 3, 2014
- Dell XPS 9360 (KabyLake R)
- Intel i7 8550U
- Intel UHD 620
- Mobile Phone
I was under the impression that something like a well-placed Notify() would trigger a rescan, but I'm not sure with the way Apple did things.
@KNNSpeed, I looked at leveraging Notify() in ACPI, but I am not sure if macOS picks this information up. Sofar I haven't seen any sign that it does.
With regards to the Thunderbolt device population, I did see PCI identifiers used in the AppleThunderbolt.kext driver code.
My Dell XPS 9630 comes with a "8086:1576 DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]".
macOS supports the "8086:1575 DSL6340 Thunderbolt 3 NHI [Alpine Ridge 2C 2015]" natively. So we can experiment with leveraging the FakePCIID technique to see if that causes more Thunderbolt elements to attach and/or Thunderbolt to show natively.
I will look into the link you posted, thanks for that. I think it might be possible to listen for ACPI events from a kext driver which is attached to the IOPCI2PCIBridge of the Thunderbolt controller port and hopefully trigger a re-scan if/when necessary.
Doing this in a driver could end up being more re-usable across all ACPI WMI supporting laptops with Thunderbolt without requiring extensive ACPI patching. But documentation on PCIDevice rescanning in macOS is sketchy at best.
In my DSDT I had some problems with XTBT calling TBFF, which freezes my machine if Thunderbolt force-power is enabled.
Removing the entire XTBT function gives the functionality described above because its always on.
Note that not dropping the standard SSDT for USB-C actually make all ports appear, there is no specific requirement to build the Thunderbolt device tree or name the Thunderbolt node NHI0. At least no requirement that I have discovered as of yet.