_PS0method before restoring the device. The first attempt was to add the following:
PXSXdevice (the Thunderbolt NHI). Originally the code waited on just
RP05to start up and that worked 50% of the time because
PXSXtakes a little bit longer to settle and we only made the race closer.
Notify (_SB.PCI0.RP09.UPSB.DSB0.NHI0, Zero). We know (from reading the ACPI specifications) that
_GPE._Lxxare level-triggered events (in order words an interrupt wire is tripped). We know that
Notifywith the second argument of zero means that it's notifying a change in the bus state. So from this we deduce that the OSX kernel expects a notification on the
NHI0device when the hotplug wire is tripped.
Notifycalls into the kernel itself and the hotplug is handled.
RP05. We look for any
_GPEthat triggers a
RP05with the second argument of zero because we know that the code will be related in some way to bus state changes. There is only one candidate:
_GPE._E20calls the local method
NTFYwhich eventually calls
Notify (_SB.PCI0.RP05, Zero). It seems like the reason why hot-plug doesn't work is that OSX expects an notification on the NHI device (
RP05.UPSB.DSB0.NHI0) while the NUC notifes the root device (
RP05). To resolve this disconnect (haha get it) in the understanding, we can patch
NTFYto alert the right device.
RP05.PXSX.DSB0.NHI0), we can refer to it with
Notify. Since we can only add, not replace, ACPI objects, we need to use Clover's patching capabilities. We rename the original
XTFYas the name is unused, and we get it out of the way. Then we implement
Notifythat happens in
_WAK(called on wakeup).
_WAKcalls local method
RWAKwhich eventually wakes up the right port if there is a device connected:
XWAK. Now we can re-write
RWAKinto our own implementation with the right changes but it's a lot of code (and a lot unrelated to TB3) and we might mess up something else. Instead what we do is call the original
RWAKin our new
RWAKfirst and then do the TB3 notification stuff as well.