So I've spent way too much time trying to get this adapter to work, and here's what I discovered. I have an XPS 13 9360 laptop, BIOS 2.8.2, Thunderbolt NVM 21.0, and kernel 4.17.14. The Thunderbolt security is disabled in BIOS, and all access control settings are as relaxed as possible.

First, a few words about the adapter.

I have opened it, which was remarkably complicated. If you want to do so, I suggest using a rotary tool with an abrasive disc to first cut off the end caps of the adapter body, then cut it longitudally using three cuts, two on the sides and one below (the top is where the lightning bolt is). The adapter has a copper shield glued to the plastic, so don't afraid if you hit metal, you can't harm the PCB yet.

Now, you are staring at a 0.5 mm thick metal can spot welded in something like 80 places and soldered to the PCB through four protrusions. You will need to grind away every weld to separate the halves of the can, and then grind away the PCB protrusions. This needs to be done carefully because there are critical components less than 0.5 mm from the metal can.

Now, you are looking at a huge mass of thermal compound, something similar to silicone. It cannot be chemically removed (with anything I tried, anyway) and I recommend using a small plastic spatula to cut and scrape it until all necessary areas are exposed. It does not adhere strongly to PCB solder mask or components anyway, it just gets stuck in crevices.

My adapter PCB has the following markings: 09 C1646 820-00689-A. The bottom of the adapter has the power supply but no logic. It has a lot of test points but I have not been able to identify any activity on them by probing with an oscilloscope while doing USB software resets. 

The top of the adapter houses logic as well as one more power supply. All of the ICs appear to carry Apple-proprietary markings. The USB PD controller is marked (TI logo) CD3215B03 6ACKCTT G1 010, identical to the photo in [1]. This is likely a remarked TI TPS65983 [2]; they have an identical ball pattern. The PD controller has an SWD debug port that is routed to an unpopulated Apple-proprietary debug header on the PCB. Although it doesn't seem to be documented by TI in [2], these PD controllers usually have a Cortex-M0 core inside. The PD controller has no built-in flash, but I haven't yet been able to identify the type (SPI or I2C) or part number of the flash IC.

The IC near the Thunderbolt connector is marked CD3211 A1 TI 5AI CKSN, which is yet another case of Apple-proprietary markings. It is in a VQFN-20 package. The only TI chip with a Thunderbolt function in a VQFN-20 package is TPS22981, and a continuity check of ground pins in the pinout appear to confirm the match.

The others aren't very interesting. There's a Fairchild FET bearing Apple-proprietary markings, and a Linear buck bearing Apple-proprietary markings, but they aren't really relevant.

Now, let's talk about software.

Under the assumption stated above in the thread that this is an ACPI hotplug issue, I've disassembled DSDT [3] and reverse-engineered much of the Thunderbolt hotplug code. It consists of two general parts, the wrapper for communicating with the SMI handler, and a bastardized version of PCI enumeration code that, upon detecting a hotplug, tells the OS to rescan the bus.

Some ACPI endpoints of interest are: \_SB.TBFP (Bool), which forcibly disables the Alpine Ridge controller power savings, making the Thunderbolt NHI PCI device appear on the bus. (This is what the intel-wmi-thunderbolt module eventually pokes.) \_GPE.OSUP, which communicates with the SMM part of Thunderbolt hotplug code via a mailbox. \_GPE.XTBT, which is the body of the Thunderbolt hotplug handler. And \_GPE._E42, which invokes the hotplug handler and I'm guessing is triggered by EC or SMM.

After plugging the Apple adapter, you can invoke (e.g. via acpi_call.ko) \_SB.TBFP(1), which will cause the Thunderbolt NHI device to appear and enumerate [4]. (The log in [4] was taken with pci=realloc intel_iommu=off. For some reason it is only able to assign the bridge BARs if I supply both pci=realloc and intel_iommu=on, but this doesn't appear to affect anything else.)

As can be seen, only the root Thunderbolt switch is enumerated on the bus. Nothing else appears. This doesn't change if I plug the adapter before or after force-enabling the controller, if I boot with the adapter plugged in, whether there's a cable in the adapter, whether there's a Thunderbolt device on the other end of the cable, nothing.

After this, I thought that possibly a rescan of the Thunderbolt bus needs to be triggered through SMM. For this, the ACPI call \_GPE.TINIT 0x01 can be done. This actually generates an ACPI hotplug event, and Linux rescans the bus, but it doesn't generate a *Thunderbolt* hotplug event, which is what's necessary to update the Thunderbolt topology. On the other hand, given that the Thunderbolt hotplug events arrive via the NHI ring buffer, is ACPI involved here at all?Additionally, the thunderbolt module scans and configures every switch it can discover when it's loaded, and loading it well after the Thunderbolt NHI interface was force-enabled and the adapter plugged in doesn't let it discover anything beyond the root switch, so I suspect ACPI and SMM aren't at all at fault here.

The only remaining avenue that I see is to desolder the USB PD controller, read its firmware, and reverse-engineer it. In the thread [1] Dell support also appears to blame the Apple PD controller chip.

Unfortunately, there's an issue with it.

Let me say it straight. The TI documentation lists the minimum flash size for the USB PD firmware as 1 Mbyte. I am not going to reverse-engineer one megabyte of shitty vendor Thumb code. Also, everyone involved in Thunderbolt and USB C engineering is batshit insane. Every technology in this stack is opaque, overcomplicated, underdocumented, and has hidden dependencies on at least one (usually more) other opaque overcomplicated underdocumented technologies. I give up. I'm probably just going to take all the Thunderbolt hardware I bought in hoping to get it to work and put it in the trash, because the only thing I can feel towards it anymore is utter disgust.

Anyway, if someone else is interested in REing the adapter, I can probably dump its firmware with minimal effort, though I'm not set up for BGA and 0402 reworking right now and it'll probably destroy the PCB given the rather compact assembly, which is why I still haven't done it. Well, that, and what the previous paragraph says. But let me know.

[1]: https://store.rossmanngroup.com/c6-cd3215a-u3100.html
[2]: http://www.ti.com/lit/ds/symlink/tps65983.pdf
[3]: https://gist.github.com/whitequark/932717e712d4e89a0468c3351fb1bbf4
[4]: https://gist.github.com/whitequark/383a349ba6e7717b4f917baede7084e7