The problems, as I understand it (which is pretty dimly), are these:
- Your motherboard manufacturer enumerates the available USB ports, but they might be lying to you (errors in the DSDT)
- You can attempt to manually verify the available USB ports, but your eyes might be lying to you (overlooking unconnected headers or USB ports assigned to m.2 slots, and etc.)
- Even with the correct list of available ports, Apple may have overridden the selection based on your system definition (for controllers in the DSDT named "XHC1" and etc.)
- Even if you rename your controllers to avoid that, there are hard limits to the number of USB ports per controller, aggravated by all USB3 ports being double-counted
- Even if you reallocate ports across controllers to avoid that, somehow the motherboard manufacturer may have defeated that by some kind of hardwiring preventing certain ports from being associated with certain controllers
It seems like #1 is the main problem as far as an automated Clover solution goes -- Clover could automatically do stuff based on the DSDT information it sees, but if that information is wrong, Clover might not end up doing anything useful.
Is that a fair summary?
Clover can't really do much about this based on DSDT because DSDT is often inaccurate many times due to the DSDT not knowing what OS it is running on, or just because the OEM made a mistake (eg. not recognizing Linux/Windows when running on Darwin). Windows either interprets _UPC differently than 10.11 or doesn't use it at all (or has workarounds like crazy).
It goes something like this:
- DSDT contains information on USB ports, and ports on built-in USB hubs
- DSDT may be wrong
- Apple may have found DSDT wrong in several Apple products, so they implemented a mechanism to override DSDT (port injectors)
- The Apple port injectors are matched on ACPI name of the controller and SMBIOS
- The Apple port injectors will override your DSDT (correct or not) if the port injectors match
- Renaming the controllers to prevent a match can be used to avoid the Apple provided port injectors, in which case, the system falls back on DSDT (which still may be wrong)
- After the ports are renamed, should your DSDT provide inaccurate details about the USB port topology, you can create a port injector just like Apple did for their own computers (you could also fix DSDT _UPC, but it is easier to do a port injector)
- Regardless, there is a limit of 15 ports per controller (or hub)
- USB3 ports count as two when both the USB2 and USB3 component are routed to the XHC controller
- USB2 ports can be routed from XHC to EHC via registers on the XHC chip
- The built-in drivers have support for this routing (muxing), but it is not well understood (there is a relationship between special DSDT methods and USB port injector data)
- FakePCIID_XHCIMux.kext can be used to force the USB2 component on XHC to EHC
- FakePCIID_XHCIMux.kext can block writes to the USB2 routing registers when such writes occur in the OS X USB drivers.
- BIOS settings affect what FakePCIID_XHCIMux does (it honors BIOS setting for the USB2 port routing mask)
- FakePCIID_XHCIMux.kext cannot block writes that occur from ACPI space (evidently AppleACPIPlatform.kext doesn't go through IOPCIDevice to do these writes)
- As a result, it is possible to have DSDT breaking things as it relates to USB2 port routing, especially on wake from sleep
- Such writes to the port routing registers from ACPI space can be fixed by ACPI patches (disabling XWAK/ESEL/XSEL), or sometimes by simulating a certain version of Windows (_OSI->XOSI mapping)
So... solutions employed depend on what conditions are actually happening.
Solutions:
- BIOS settings for USB2 port routing on XHC ("auto" vs. "smart auto" vs. "enabled")
- renaming EHCx->EH0x to avoid built-in port injectors
- FakePCIID_XHCIMux to enforce USB2 port routing on XHC
- DSDT patches to simulate Windows (various versions) when running Darwin
- DSDT patches to avoid writes to port routing registers on XHC (nullifying XWAK, ESEL, XSEL)
- custom port injectors to match actual port configuration