Currently because OSX does not know if a non-PCI device triggered the GPE, it will assume that every non-PCI and non-PCI power management enabled device triggered the GPE. Then it prioritizes user initialized wakeups above all else. If you have a Ethernet controller with the same GPE, then the "Network" wakeup type (which is a dark wake) will be inhibited by the "User" wakeup type (by the fake device).
A more "advanced" workaround will create a fake PCI device with fake power management registers. On wakeup, the request to read the PMSC register will be intercepted to return PM_Enable & PM_Status to be true only if USB was the cause. If an Intel bug prevents seeing the PM_Status for XHCI controller, then we might have to read every single device hooked up to the GPE and deduce a USB wakeup if everyone returns false.
Currently because OSX does not know if a non-PCI device triggered the GPE, it will assume that every non-PCI and non-PCI power management enabled device triggered the GPE. Then it prioritizes user initialized wakeups above all else. If you have a Ethernet controller with the same GPE, then the "Network" wakeup type (which is a dark wake) will be inhibited by the "User" wakeup type (by the fake device).
A more "advanced" workaround will create a fake PCI device with fake power management registers. On wakeup, the request to read the PMSC register will be intercepted to return PM_Enable & PM_Status to be true only if USB was the cause. If an Intel bug prevents seeing the PM_Status for XHCI controller, then we might have to read every single device hooked up to the GPE and deduce a USB wakeup if everyone returns false.