Contribute
Register

USB-C Hotplug not working

Status
Not open for further replies.
I'm currently on Skylake with an Alpine Ridge TB chip (PID: 1575). I adapted the SSDT-TYPC for my system (see: https://gist.github.com/kprinssu/df56adffde5613ba469b56c01254ce9e).

I do have the chip being recognised but the Apple drivers are failing to initliased (as observed with the "Thunderbolt: No drivers are loaded." in the System Profiler). However, the drivers do enumerate devices the bus (attached an image and a copy of IOReg):
V6dER8p.png


Did you face a similar issue with your laptops?

I am pretty sure my issue is with Asus not implementing the "Legacy mode" for TB3 security (my laptop uses "UniqueID").
 

Attachments

  • TB3 (no drivers are loaded).zip
    823.5 KB · Views: 188
Last edited:
That's the issue I've always been having; nothing new there.
 
@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.

The Device ID for the NHI is 1575, the PCI bridges are 1576. I agree; I think a proper driver is the best way to go, unless we can figure out what Apple's drivers are looking for. In that thread you'll also find I posted a particular Thunderbolt-related ACPI table in which Apple left full debugging statements. o_O

It might be worth reiterating here that I have gotten Thunderbolt devices to enumerate by accident with SSDT-TYPC. Sometimes randomly plugging in a device will just enumerate (my relevant BIOS settings are in my build) and work. I have never been able to make it consistent or figure out why. Possibly something to do with the ICM (some sort of Intel connection manager) mentioned in the aforementioned ACPI table.
 
That's the issue I've always been having; nothing new there.

Hopefully, this will add more information into the mix. I contacted remote.syst3m from this thread over at insanelymac (www.insanelymac.com/forum/topic/320220-thunderbolt-3-info-unique-id-mode/). His reply for getting TB3 working was:

Actual Plug and Play. 100% Hotswap. I DO NOT boot with any TB devices attached.

You need to have a fully working smbios, _DSM methods in each XHCI controller, and in each _DSM iopcibridge you need to enable "PCIHotplugCapable".

I will work on patches.

This requires a DSDT with a fully detected system or it will not work for hotswap.
 
Well, for what it's worth, here are some SSDTs I made a while ago in attempts to mimic the way Apple's work. None of these work 100% for hotswap (the "In_use" one has the random behavior I described).

It's basically an attempt at porting the Apple SSDTs to my Dell.
 

Attachments

  • SSDT-TYPC_Variants.zip
    21.5 KB · Views: 262
Well, for what it's worth, here are some SSDTs I made a while ago in attempts to mimic the way Apple's work. None of these work 100% for hotswap (the "In_use" one has the random behavior I described).

It's basically an attempt at porting the Apple SSDTs to my Dell.
Thanks, I'll start digging myself.

My laptop doesn't even recognise the device at boot. Having the device plugged in makes macOS aware that there is TB hardware, but doesn't finish initialising the device. Hence, the "No drivers are loaded" message.
 
Just so you know, implementing the security features of Thunderbolt involves establishing an encrypted handshake between device and host. Apple did that differently than everyone else up until their most recent TB3 hardware (e.g. Skylake/Kaby Lake). This is why Windows and Mac devices had to be certified separately for the longest time. Unless you're using a DSL6340 or JHL6340, beware that the security features are implemented at a low level, and at the very minimum you'll have to write a driver to do Windows-->Mac security translation, which is probably more difficult than something like making an Optimus driver would be. I mean, it will probably solve the "can't use older Windows thunderbolt devices on Macs" problem, but it will take more than just a small hack to do that.

See here:
https://eischmann.wordpress.com/2017/06/29/thunderbolt-security-levels-and-linux-desktop/
Intel has since added Thunderbolt security support into the Linux kernel, too, so that would be your best bet if you do have a 6340.
 
Actual Plug and Play. 100% Hotswap. I DO NOT boot with any TB devices attached.

You need to have a fully working smbios, _DSM methods in each XHCI controller, and in each _DSM iopcibridge you need to enable "PCIHotplugCapable".

I will work on patches.

This requires a DSDT with a fully detected system or it will not work for hotswap.
I could fully confirm this message. Also got everything working with fullworking hotswap capability. Also have for every "pci-bridge"a _DSM in my SSDT. w/o all these _DSM's i won't have hotswap capabilities.
 
I could fully confirm this message. Also got everything working with fullworking hotswap capability. Also have for every "pci-bridge"a _DSM in my SSDT. w/o all these _DSM's i won't have hotswap capabilities.
Unfortunately r3mote_syst3m has not responded to my requests for taking a looking at his DSDT and IOReg. Would it be too much of a hassle to ask for a copy of yours?
 
But have you ever had the Thunderbolt ethernet devices showing up under Thunderbolt Local node?

The best I got on that front was being told "No driver detected" or something to that extent (i.e. Not the usual "No hardware found" message). I have had an Ethernet device show up as "Thunderbolt@0" in the Ethernet Cards tab. There should be a screenshot at that earlier link I posted. EDIT: Or see Mork's image above.

I don't think I understand how to use your kext, btw. I tried it and it didn't work. What's the correct usage scenario?
 
Status
Not open for further replies.
Back
Top