Not quite but kinda. They use the same vendor. There are actually a few folks who use the same chips but produce different firmware (was broadcom, infineon, c

Not quite but kinda. They use the same vendor. There are actually a few folks who use the same chips but produce different firmware (was broadcom, infineon, cypress, cypress bought broadcom's IP, and then cypress was later bought by infineon so now it's broadcom, infineon, and infineon) The firmware features and interaction is heavily versioned/compatible over the years. Without writing 80 pages (only like 3), the easiest mildly incorrect way to think about it is these chips are just arm cores running some firmware, and the driver is reading/writing variables in the core's memory through an interface for variables, and also sending ioctl commands to the cores (getting/setting a variable is actually an ioctl). So there are commands like like "join this ssid" or "here's some roaming preferences". The firmware does stuff with that, and eventually you get wifi packets sent over a ringbuffer. Yay! You can even, with fun work, gdb the arm cores on the chip, from the host. Or memory dump them, or set tracepoints, or whatever the hell. Anyway, the firmware on all of these chips, from all vendors, since basically forever, supports the same way to send ioctls and read/write named variables. They have, over the years, changed which the "current" way to do a thing is. Like for example, they may change the standard way to get the list of available channels, because the old way can't support 6G or whatever. So it will go from "read the chanspecs variable" to "read the chan_info_list" variable. The old way will still often work for years, with whatever limitation exists on it (IE the old way will give you the old format structure, the new way gives you a different structure with whatever new info they added). Sometimes you can combine old things to make new features work, sometimes you have to use the new way. These days they often change structures rather than commands, and version the structures (enjoy these 12 different versions of btc stats: https://android.googlesource.com/kernel/google-modules/wlan/bcmdhd/bcm4398/+/refs/heads/android-gs-shusky-5.15-android14-d1/include/wlioctl.h#11201 https://android.googlesource.com/kernel/google-modules/wlan/... or these 6 versions of roaming profiles https://android.googlesource.com/kernel/google-modules/wlan/bcmdhd/bcm4398/+/refs/heads/android-gs-shusky-5.15-android14-d1/include/wlioctl.h#20847 https://android.googlesource.com/kernel/google-modules/wlan/...) Kidding aside, this is actually good! It's a sane way to handle this, and i'm glad they started doing it. What has happened here (most likely) is that the way to set the SAE key in the old drivers became "old and busted", and eventually deprecated by all vendors. It used to be done, shockingly, by setting an variable named "sae_password" in the core (the variables are named with strings). This no longer works. Nowadays, you are instead supposed to fill in a versioned structure with key type/info and call an IOCTL command (named SET_WSEC_PMK) instead (what gets to be an iovar vs an ioctl vs you name it is ... scattershot) If you try to set the sae_password variable, on something newer, the firmware will tell you "unsupported". It's nice about it, mind you. Where does asahi come in: So Apple's chips have to use the SET_WSEC_PMK path because sae_password is unsupported. It also turns out that the old sae_password method was being kept around because people thought it worked with the older cypress chips. But that's exactly what Rachel is saying doesn't work. Hector's patch makes it use the SET_WSEC_PMK in all cases, which i expect fixes it. If not, you just have to figure out what version structure/command was supposed to be working at the time for this chip. It'll either be an older version of the SET_WSEC_PMK structure, or a slightly different command. THe firmware for some of these chips in this timeframe is actually published as part of the asus gpl sources, so i would bet you can just go tell what it wants you to do to set the WPA3 key. In that sense, fixing this should be easier than anyone thinks- assuming hector's patch doesn't just fix it, it's almost certainly 1-2 lines of code to make it work if it supports SAE offload. If the chip doesn't support builtin SAE offload (rare), you can still tell it "i have an external supplicant, please send me the auth frames and such and i'll take care of it". It's not that hard, that is probably like 50-100 lines of code, and very straightforward. If you want to see exactly what happens, build a kernel with BRCMDEBUG and BRCM log tracing options installed, and then modprobe with debug=1101828 (it's just an of a reasonable set of debug bits) Then you can watch it boot the arm chips in the wifi chipset, get the firmware console display (the firmware's own logging is read back over the pcie bus), and then you can watch the iovars and commands fly back and forth and what the firmware says to each one. you will see lots of feature testing and other things. Some things it gets told are unsupported and may try a different way, some it fails, etc. I am working on better handling the myriad of structure/command/etc versions in the driver (which should have been done years ago), so that eventually it can handle the past few years of chips and structures properly.