XHC USB Kext Creation Guideline

[kgp]

Total revision of my former XHC USB Kext Creation Guideline

Note that I just finished a major revision of my former XHC USB Kext Creation Guideline in the spirit of the 10.14.1 com.apple.driver.usb.AppleUSBXHCI USB port limit kernel patch flaw.

Enjoy and have fun,

 

[RehabMan]

the port limit patch would be just required for the initial XHC USB kext creation.

No.
My guide works without any port limit patch.

 

[kgp]

No.
My guide works without any port limit patch.

Well the XHC USB kext approach can also live quite well without any port limit patch. All HS ports are always fully implemented, thus one can still fully investigate and define the HS port properties within the kext at first place and even already drop some of the HS ports, if necessary. The first four SS-Ports are usually assigned to two internal USB3.0 connectors, and as SS01 is usually also always implemented, it is easy to figure out, which SS ports, out of the 6 SS-ports, to likely drop in addition. Anyway after properly implementing and dropping some of the 14 HS ports, at least four out of six SS-ports will be already fully implemented by OSX after boot and you already posses all necessary information to drop the correct SS-ports, if desired.

Thus, no big deal either, even in case that the port limit patch approach fails, like actually under 10.14.1. However, I am not a friend of dropping ports and I definitely prefer to have all onboard USB connectors fully available. Unfortunately, the latter is not possible at present, with the failing port limit patch under 10.14.1.

Anyway, all above comments just for clarification and without any intention or aim to enter in direct competition with your appreciated usbinjectall.kext and SSDT approach.

Best wishes,

KGP

 

[RehabMan]

Well the XHC USB kext approach can also live quite well without any port limit patch. All HS ports are always fully implemented, thus one can still fully investigate and define the HS port properties within the kext at first place and even already drop some of the HS ports, if necessary. The first four SS-Ports are usually assigned to two internal USB3.0 connectors, and as SS01 is usually also always implemented, it is easy to figure out, which SS ports, out of the 6 SS-ports, to likely drop in addition. Anyway after properly implementing and dropping some of the 14 HS ports, at least four out of six SS-ports will be already fully implemented by OSX after boot and you already posses all necessary information to drop the correct SS-ports, if desired.

Thus, no big deal either, even in case that the port limit patch approach fails, like actually under 10.14.1. However, I am not a friend of dropping ports and I definitely prefer to have all onboard USB connectors fully available. Unfortunately, the latter is not possible at present, with the failing port limit patch under 10.14.1.

Anyway, all above comments just for clarification and without any intention or aim to enter in direct competition with your appreciated usbinjectall.kext and SSDT approach.

Best wishes,

KGP

You should never plan to use the port limit patch (if one existed) long term.
Short term only for port discovery is fine, but not after that (drop required ports to get within the limit).
But you don't need the port limit patch at all, not even during discovery, as my guide proves (it does not depend on any port limit patch, not even during port discovery).

Either method for final port injection (kext or USBInjectAll.kext + SSDT) is equivalent/same result. No preference either way.

Although I find the USBInjectAll more flexible:
- can publish an SSDT with all ports, but then disable additional ports with kernel flags for personal reasons
- can change SMBIOS without changing kext Info.plist content (USBInjectAll matches on all known SMBIOS)
- can add appropriate comments (describing ports/locations/etc) in the SSDT-UIAC.dsl

 

[kgp]

You should never plan to use the port limit patch (if one existed) long term.
Short term only for port discovery is fine, but not after that (drop required ports to get within the limit).
But you don't need the port limit patch at all, not even during discovery, as my guide proves (it does not depend on any port limit patch, not even during port discovery).

Either method for final port injection (kext or USBInjectAll.kext + SSDT) is equivalent/same result. No preference either way.

Although I find the USBInjectAll more flexible:
- can publish an SSDT with all ports, but then disable additional ports with kernel flags for personal reasons
- can change SMBIOS without changing kext Info.plist content (USBInjectAll matches on all known SMBIOS)
- can add appropriate comments (describing ports/locations/etc) in the SSDT-UIAC.dsl

I felt always comfortable with the port limit patch and I personally don't like to drop ports if not necessary. I never faced any issue this way. Anyway, 10.14.1 now forces us to drop ports anyway.

The XHC USB approach was originally published in German by Brumbear on 16 August 2017 in the Hackintosh-Forum.de. It is not my approach, thus there is nothing I have to defend here. I basically made it accessible to the English speaking community in this forum within my iMacPro X299 macOS High Sierra guide by this time. Later on, in January 2018, I outsourced it to this actual thread within a simply copy and paste as my iMacPro guide was steadily growing. Some initial consistencies and flaws in the introduction, tracing back to Brumbear's original German guidelines have been clarified and fixed thanks to your valid interaction in January 2018. I do not understand why now suddenly pops up again all this discussion.

From my personal experience and based on the respective user feedback all over the years, the XHC Usb kext approach works without any issue and is fully adoptable without any restrictions. I consider the XHC USB kext approach simply as some interesting and also valid alternative approach to your anyway widely accepted, appreciated and frequently applied USBInjectAll approach, which actually is not topic of any debate or discussion. I also do not see any reason why you would have to justify or defend anything here at this place, now or in the future.

Given all your former and actual interventions along this thread, I have the feeling that you do not feel very comfortable with this alternative approach or there exists a basic misunderstanding concerning my intentions . Thus, I really don't know what to do in this situation. Anyway, be ensured that I am not interested in any escalation of this current unfortunate discussion.

I am open to any solution that could remove some apparent tension, which was anyway never my intention.

Kind regards,

KGP

 

[RehabMan]

I felt always comfortable with the port limit patch

You shouldn't.
It is clearly causing a buffer overrun/array bounds overwrite (I have seen multiple instances of it in helping people on these forums).

The degree of the problems it will cause depend on what data and how much is being trashed beyond the fixed size array.

Anyway, 10.14.1 now forces us to drop ports anyway.

The tightened restrictions are a good thing, IMHO.

The XHC USB approach was originally published in German by Brumbear on 16 August 2017 in the Hackintosh-Forum.de. It is not my approach, thus there is nothing I have to defend here. I basically made it accessible to the English speaking community in this forum within my iMacPro X299 macOS High Sierra guide by this time. Later on, in January 2018, I outsourced it to this actual thread within a simply copy and paste as my iMacPro guide was steadily growing. Some initial consistencies and flaws in the introduction, tracing back to Brumbear's original German guidelines have been clarified and fixed thanks to your valid interaction in January 2018. I do not understand why now suddenly pops up again all this discussion.

From my personal experience and based on the respective user feedback all over the years, the XHC Usb kext approach works without any issue and is fully adoptable without any restrictions. I consider the XHC USB kext approach simply as some interesting and also valid alternative approach to your anyway widely accepted, appreciated and frequently applied USBInjectAll approach, which actually is not topic of any debate or discussion. I also do not see any reason why you would have to justify or defend anything here at this place, now or in the future.

Given all your former and actual interventions along this thread, I have the feeling that you do not feel very comfortable with this alternative approach or there exists a basic misunderstanding concerning my intentions . Thus, I really don't know what to do in this situation. Anyway, be ensured that I am not interested in any escalation of this current unfortunate discussion.

I am open to any solution that could remove some apparent tension, which was anyway never my intention.

Kind regards,

KGP

No tension intended.

Either approach to USB port injection (SSDT+USBInjectAll or USB injector kext) works, after all they both do exactly the same thing. Those that think there is a fundamental difference between the two methods probably don't understand it well enough to know that the same thing is going on in either case (injection of port-count, and ports in ioreg).

I have used both at various times in most of my guides. The advantages of the USBInjectAll approach (already documented in my last reply), are enough for me to stick with it for my own use/guides.

My only point in replying was to correct your false assertion that the port limit patch was required for port discovery.
If you read my guide, you will find it is not a requirement.
Keep in mind that my guide was recently updated (to not depend on a port limit patch for discovery), so if your opinion of it is based on an older version, you should re-read it. Even if a port limit patch is discovered for 10.14.1+, I will keep with the guide as-is (without port limit patch dependencies) as it is one less thing to chase down with each update.

 

[kgp]

You shouldn't.
It is clearly causing a buffer overrun/array bounds overwrite (I have seen multiple instances of it in helping people on these forums).

The degree of the problems it will cause depend on what data and how much is being trashed beyond the fixed size array.



The tightened restrictions are a good thing, IMHO.



No tension intended.

Either approach to USB port injection (SSDT+USBInjectAll or USB injector kext) works, after all they both do exactly the same thing. Those that think there is a fundamental difference between the two methods probably don't understand it well enough to know that the same thing is going on in either case (injection of port-count, and ports in ioreg).

I have used both at various times in most of my guides. The advantages of the USBInjectAll approach (already documented in my last reply), are enough for me to stick with it for my own use/guides.

My only point in replying was to correct your false assertion that the port limit patch was required for port discovery.
If you read my guide, you will find it is not a requirement.
Keep in mind that my guide was recently updated (to not depend on a port limit patch for discovery), so if your opinion of it is based on an older version, you should re-read it. Even if a port limit patch is discovered for 10.14.1+, I will keep with the guide as-is (without port limit patch dependencies) as it is one less thing to chase down with each update.

You know that I personally used the kext approach over years and it was also always part of my iMacPro guides. That's why I have some preferences to stick to it also in the future. In all other remaining points we fully agree, also in the point that the port limit patch is not deemed necessary for the initial port discovery, independent from the USB approach applied. However, it facilitates the port discovery for not very experienced users. That's why I also initially proposed to perform the port discovery for the non-truncated kext under some macOS version with a working port limit patch, before subsequently truncating the kext for it's actual use under 10.14.1. Certainly all this can be also done by experienced users directly under 10.14.1 or any other macOS version without a working port limit patch and with or without using USBInjectall. I also agree in using truncated kexts now and in the future, not only because of some possible issues you describe above but mainly because of their independence from any USB port limit patch, which makes our systems even more vanilla. However, you know about the diversity of user feedback. There will be still users complaining about not being able to use all their USB ports and permanently asking for respective solutions. Therefore, I still would like to gather a collection of fully implemented board-specific kexts at first place and leave the subsequent kext truncation or utilisation of a port limit patch up to the user. However, I can of course implement some recommendations to use truncated kexts and to stay away from using port limit patches now and in the future. Let me also read your updated guide these days to see if I can catch or implement one or the other helpful input or advise.

Cheers, man!

KGP

 

[RehabMan]

You know that I personally used the kext approach over years and it was also always part of my iMacPro guides. That's why I have some preferences to stick to it also in the future. In all other remaining points we fully agree, also in the point that the port limit patch is not deemed necessary for the initial port discovery, independent from the USB approach applied. However, it facilitates the port discovery for not very experienced users. That's why I also initially proposed to perform the port discovery for the non-truncated kext under some macOS version with a working port limit patch, before subsequently truncating the kext for it's actual use under 10.14.1. Certainly all this can be also done by experienced users directly under 10.14.1 or any other macOS version without a working port limit patch and with or without using USBInjectall. I also agree in using truncated kexts now and in the future, not only because of some possible issues you describe above but mainly because of their independence from any USB port limit patch, which makes our systems even more vanilla. However, you know about the diversity of user feedback. There will be still users complaining about not being able to use all their USB ports and permanently asking for respective solutions. Therefore, I still would like to gather a collection of fully implemented board-specific kexts at first place and leave the subsequent kext truncation or utilisation of a port limit patch up to the user. However, I can of course implement some recommendations to use truncated kexts and to stay away from using port limit patches now and in the future. Let me also read your updated guide these days to see if I can catch or implement one or the other helpful input or advise.

Cheers, man!

KGP

Cheers indeed.

 

[franksanderdo]

Hi @kgp

I am cleaning some mess on my machine and with that I have finally worked on the XHC USB kext.
in case you like to extend your collection I have attached the full implementation for my ASRock X299m extreme4 mobo.

All the Best
Frank

 

[kgp]

Hi @kgp

I am some mess on my machine and with that I have finally worked on the XHC USB kext.
in case you like to extend your collection I have attached the full implementation for my ASRock X299m extreme4 mobo.

All the Best
Frank

Fantastic! Thanks, man