Native USB 2.0 / USB 3.0 on Skylake

[RehabMan]

Hi @RehabMan

I agree with your comment. Your kext and @ammulder 's procedure works perfectly.

May I ask how the two procedures differ? Yours and @cnrd 's ? How the two approach the problem?

The reason I ask is partly because of my earlier post on this thread #49. Your kext is about 130k in length. My self-generated aml file using @ammulder 's method is 697 bytes, which I've happily been using with your kext without problem from El Cap to Sierra. @cnrd 's post creates an aml file 11k in length, which surprised me.

Is either a technically better method? Or just two equally valid paths to the same end?

USB ports are defined by the ACPI spec (primarily _UPC and _PLD).

port-count and ports when injected into ioreg are Apple's way to override ACPI definition of active USB ports. Apple uses this mechanism with their own products.

So, you have a choice for fixing USB when your ACPI code is wrong. First choice: fix the incorrect code in ACPI. Second choice: override it by injecting port-count and ports.

Apple uses AppleUSBMergeNub to do the injection. You can use the same mechanism that Apple does... Or you can use USBInjectAll.kext which can be configured through ACPI. The end result is the same... injected ports and port-count to override ACPI _UPC/_PLD.

 

[UtterDisbelief]

USB ports are defined by the ACPI spec (primarily _UPC and _PLD).

port-count and ports when injected into ioreg are Apple's way to override ACPI definition of active USB ports. Apple uses this mechanism with their own products.

So, you have a choice for fixing USB when your ACPI code is wrong. First choice: fix the incorrect code in ACPI. Second choice: override it by injecting port-count and ports.

Apple uses AppleUSBMergeNub to do the injection. You can use the same mechanism that Apple does... Or you can use USBInjectAll.kext which can be configured through ACPI. The end result is the same... injected ports and port-count to override ACPI _UPC/_PLD.

Thank you @RehabMan

So the port capabilities and location description are being either modified using a patch via Apple's own kext or USBInjectAll ? Think I understand that now. So our friend @cnrd is using the Apple kext and modifying the spec and injecting later than your method, which is earlier in the boot sequence?

Forgive me asking. It's not too important. Just me keen to learn a little. I've had absolutely no problems with your own method for a long time, just wondered what the difference was.

 

[RehabMan]

So the port capabilities and location description are being either modified using a patch via Apple's own kext or USBInjectAll ?

The port and port-count properties can be used to override the (presumably incorrect) data in ACPI.
It does not matter how you inject those properties in ioreg, as long as they are injected before the native kexts look for them. This is why USBInjectAll.kext as well as AppleUSBMergeNub do such injections in IOService:robe.

As to whether you use USBInjectAll.kext or AppleUSBMergeNub to inject the properties... does not matter. It is the same mechanism and same result. I prefer to use the USBInjectAll.kext approach, as I think it is easier to document the ports in an SSDT vs. an Info.plist and it is also not bound to the SMBIOS in use.

Think I understand that now. So our friend @cnrd is using the Apple kext and modifying the spec and injecting later than your method, which is earlier in the boot sequence?

The method described in this thread focuses on "fixing" _UPC and _PLD in ACPI instead of trying to override it with ioreg injections. Because _UPC and _PLD are a bit complex, some may find that more difficult to accomplish. In fact, I think most people following this guide don't really understand what they are doing, as they have likely not read the ACPI spec. To the degree that the subject ACPI files follow a certain pattern (depends on who coded it)... in this case a pattern used by whoever provided the ACPI code for Gigabyte, one can follow a "cookbook" instruction like this. But, of course, such a procedure will not be generic as other computers may have used a different BIOS/UEFI firmware vendor. In that case, you would have to gain an understanding of _UPC and _PLD in order to effectively fix the broken code there.

It is for this reason (the complexity of fixing _PLD and _UPC) and the fact that it is very difficult to fix via Clover hotpatching... that use the "override" mechanism using USBInjectAll.kext.

 

[UtterDisbelief]

The port and port-count properties can be used to override the (presumably incorrect) data in ACPI.
It does not matter how you inject those properties in ioreg, as long as they are injected before the native kexts look for them. This is why USBInjectAll.kext as well as AppleUSBMergeNub do such injections in IOService:robe.

As to whether you use USBInjectAll.kext or AppleUSBMergeNub to inject the properties... does not matter. It is the same mechanism and same result. I prefer to use the USBInjectAll.kext approach, as I think it is easier to document the ports in an SSDT vs. an Info.plist and it is also not bound to the SMBIOS in use.



The method described in this thread focuses on "fixing" _UPC and _PLD in ACPI instead of trying to override it with ioreg injections. Because _UPC and _PLD are a bit complex, some may find that more difficult to accomplish. In fact, I think most people following this guide don't really understand what they are doing, as they have likely not read the ACPI spec. To the degree that the subject ACPI files follow a certain pattern (depends on who coded it)... in this case a pattern used by whoever provided the ACPI code for Gigabyte, one can follow a "cookbook" instruction like this. But, of course, such a procedure will not be generic as other computers may have used a different BIOS/UEFI firmware vendor. In that case, you would have to gain an understanding of _UPC and _PLD in order to effectively fix the broken code there.

It is for this reason (the complexity of fixing _PLD and _UPC) and the fact that it is very difficult to fix via Clover hotpatching... that use the "override" mechanism using USBInjectAll.kext.

Excellent!

Thank you for taking the time to expand on this. It's appreciated.

For me and my latest project based on, yes, a Gigabyte board, both methods work well. @cnrd 's idea of a single script that does everything is a good one and will appeal to many, but I also like the idea of a much smaller (apparently) aml patch, and a kext that doesn't actually need to be in L/E or S/L/E.

 

[pbryanw]

It is a lot easier to simply use USBInjectAll.kext with a custom SSDT to configure the specific ports needed...

@RehabMan - Hehe, yes, I've now gone back to the USBInjectAll.kext with a custom SSDT solution. It's fun to tinker occasionally, but as you alluded to, I didn't know exactly what I was doing, and it's probably best to leave this to those with compatible motherboards. And thanks for your follow-up answers to @UtterDisbelief - it also helped my understanding of the differing solutions to this problem.

 

[HD-MAICO-XR]

I have not fully understood, but it works well for me.

All the USB 2 Port USB 3 port are operational and reliable now.

 

[LeadmaN]

I used this script and it worked however it also breaks my Apple wired keyboards USB ports delivering power to devices. With everything vanilla I have 14 HS USB ports and 1 SS port, but working power on my keyboards hub ports. With the script I have my custom ports working but the keyboard hub ports give a warning to put the device into a iMac USB port.

USBInjectAll also breaks the keyboard port power.

 

[phdparis]

i have been spending a lot of time getting the usb 3 ports to work on a ga z 170n wifi, following the diffrent solutions proposed.

my (stupid)) problem was that the usb 3.0 keys I had were not recognized

Using a lexar 16G solved the issue

So beware try with different keys

 

[JMacIV]

Hey guys,

Just ran this in an attempt to clean up my install. Build is in signature.

Everything seemed to go well. One question though - Now I have "DP" ports mixed in with my HS and SS ports. I had not seen that before and tried googling, but not sure what a DP port is. Just was hoping for some clarification. These DP02, 03 and 04 ports are USB 2.0/3.0 ports directly on my mobo. Ports are still working fine, just confused.

Thanks for all your hard work Cnrd! And Rehab and all the others

Edit: My build signature did not show. Gigabyte Z170X-Gaming 7 mobo, i7-6700k, Sierra 10.12.1, GTX 560 Ti (old, I know. Was laying around and reused), HD 530 disabled in BIOS.

 

[0815Typ]

My Mobo is a gigabyte Z170X UD5 TH and I was able to activate all USB ports, but the speed is far below expectations.

What could be the problem?