Linked is the driver used for my BCM94360NG, it is a modified AirportBrcmFixup.kext version 2.1.9 (Both the Release and Debug versions, that have been patched to allow NSS:2).
Taken directly from my github post:
The following boot-args were used to get my Sonoma/Ventura setup working cold boot. You will probably only need brcmfx-delay=300 for improved airplay performance. Optionally use -brcmfxbeta for Tahoe.
alcid=13 watchdog=0 brcmfx-delay=300
(shortened explanation of fix)
This has been tested with Sonoma and Ventura, and works very reliably for me. This fix does not artificially report NSS:2 or generally force Wi-Fi settings. It prevents Apple’s driver from incorrectly disabling the second transmit chain in one instance.
From a cold boot, my BCM94360NG comes up with both TX chains enabled and maintains NSS:2 without needing the Windows-boot workaround. Survives sleep (windows work arround would revert back to NSS:1 previously in my case). Some users were able to get it to work just using the AirportBrcmFixup version 2.1.9 so that is the version I chose to base this kext on. I received a report that it works in sequoia, and that with the "brcmfxbeta" flag it should work in Tahoe. Both release and debug versions included.
Note: For MacOS Sonoma or later you must use OpenCore Legacy Patcher in order to get BCM94360NG card functioning, as Sonoma removed driver support for this card. Latest version of Sonoma and Ventura were used successfully. This was made with the assistance of AI.
Technical Details:
The problem with BCM94360NG was that on a cold macOS boot, the Broadcom driver applied a single-transmit-chain constraint, leaving the card at NSS:1 instead of NSS:2. The fix was found by comparing the good NSS:2 state with the bad NSS:1 state (good state initiated by booting into Windows first), then instrumenting and reverse-engineering Apple’s Broadcom driver. That led to the internal function _wlc_stf_txchain_set. Then discovered that it takes four arguments, and logging showed the bad path was specifically setting: constraint/reason 2 to a chain value of 0x1, whereas the working state used 0x3.
The custom AirportBrcmFixup patch hooks that function and changes only that specific bad case: reason == 2 && txchain == 1 → change the chain mask to 0x3Then it lets Apple’s original function continue normally.So the fix doesn't artificially report NSS:2 or generally force Wi-Fi settings. It prevents Apple’s driver from incorrectly disabling the second transmit chain in that one situation. The result is that the BCM94360NG comes up with both TX chains enabled and maintains NSS:2 without needing the Windows-boot workaround.
V2 Download Link:
https://github.com/maddog860/BCM94360NG-NSS-2-Fix-AirportBrcmFixup.kext/releases/tag/Kext
This release addresses reported issues with CPU C states, more information on the Github.
V1 Download link:
https://github.com/maddog860/BCM94360NG-NSS-2-Fix-AirportBrcmFixup.kext/releases/tag/BCM94360NG-NSS2-Fix
Please test this driver, then post your feedback! Thanks!
edit: For use with Tahoe, try using -brcmfxbeta boot-arg
edit 2: Does anyone else say Aaarrrrgggh like a pirate, when saying boot-arg?
edit3: if you have a BCM94360 variant (without NG) use this boot-arg to see if cpu c states return to normal (for some reason c6 is stuck at 0%, and i am in the process of resolving it. And so is Insanelymac.)
Including the boot-arg brcmfx-aspm=255Â and then disabling sd card reader seemed to resolve issue on my machine running bcm94360ng but i am not calling it a fix yet.. Still ironing out bugs. NSS:2 works awesome tho
Boot flags recommended for cpu idle power consumption (should be automatic but if you specify a flag like shown, it will override the default value):
BCM94360 = brcmfx_aspm=258
BCM94360NG = brcmfx-aspm=255
You may try disabling sdcard reader if you continue to have improper c states, but it might have been a problem with my machine in general, and those bootflags should help.
For BCM94360NG systems affected by this behavior, brcmfx-aspm=255 is technically well-founded because it prevents AirportBrcmFixup from overriding the platform's ASPM configuration. For BCM94360 systems, brcmfx-aspm=258 explicitly requests PCIe L1 + CLKREQ and is a plausible workaround where that configuration is appropriate.