### System details

2021 16" MacBook Pro, Apple M1 Max, 32GB RAM (MacBookPro18,2 / apple,j316c), Broadcom BCM4387 [14e4:4433], Asahi Linux on Arch Linux ARM aarch64, linux-asahi 7.1.6.asahi1-1, Omarchy 4.0.0

### What's wrong?

With Wi-Fi firmware loading and `wlan0` present, no network can be joined. Scanning lists everything in range. Connecting hangs, times out, and NetworkManager reports it like a wrong password. After a couple of attempts the chip stops answering the driver, so scanning dies too, and only a driver reload or a reboot brings it back.

Not to be confused with the other Apple Silicon Wi-Fi problem, which gives no `wlan0` at all: that one comes from `omarchy_hooks.conf` reassigning `HOOKS` and dropping Asahi's `asahi` initcpio hook, already reported in #6876. Everything here is with firmware loading correctly.

The cause is `install/hardware/apple/fix-brcmfmac-supplicant.sh`, which writes `options brcmfmac feature_disable=0x82000` for any Apple machine matching a `brcmfmac` PCI ID from `brcm_hw_ids.h`. Two of those nine IDs are Apple Silicon parts, not Intel Macs:

| ID | Constant | Hardware |
|---|---|---|
| `4425` | `BRCM_PCIE_4378_DEVICE_ID` | BCM4378, M1 |
| `4433` | `BRCM_PCIE_4387_DEVICE_ID` | BCM4387, M1 Pro/Max/Ultra, M2 |

On a BCM4387 the flag does the opposite of its job. It is meant to fix a WPA handshake that never completes, and instead it stops association happening at all. Without the flag the same machine joins the same AP normally.

#6652 flagged this risk itself, with "The chip-ID list is derived, not tested", and asked for confirmation from an `iMac19,x` or a 2017 MacBook Pro. This is confirmation, from the other end of the list.

#### Reproduce

1. Apple Silicon Mac on Asahi, with vendor firmware loading so `wlan0` exists and scanning works.
2. Confirm `/etc/modprobe.d/brcmfmac.conf` contains `options brcmfmac feature_disable=0x82000`, written by the script at install time or by `migrations/1786391100.sh` on an existing install. Reboot.
3. Try to join a WPA2/WPA3 transition-mode AP. It never associates, then the chip wedges.
4. Remove `/etc/modprobe.d/brcmfmac.conf`, reboot, and join the same AP again. It works.

#### Logs

```
wpa_supplicant: wlan0: Trying to associate with aa:bb:cc:00:00:01 (SSID='<redacted>' freq=2462 MHz)
wpa_supplicant: FT: Invalid key management type (2)
wpa_supplicant: wlan0: Authentication with aa:bb:cc:00:00:02 timed out.
ieee80211 phy0: brcmf_msgbuf_query_dcmd: Timeout on response for query command
ieee80211 phy0: brcmf_msgbuf_tx_ioctl: Failed to reserve space in commonring
ieee80211 phy0: brcmf_cfg80211_scan: scan error (-12)
```

Same on 2.4 GHz and 5 GHz, against several BSSIDs, under NetworkManager, iwd and a hand-written `wpa_supplicant` config alike. Forcing plain WPA2-PSK on the client does not help while the flag is set. The AP is a UniFi mesh in WPA2/WPA3 transition mode with PMF optional and 802.11r on, which is the case the quirk targets.

#### Evidence

Across boots on this machine, with the flag set association never completes and the kernel logs 188, 583 and 669 `brcmf_msgbuf_query_dcmd: Timeout` lines. Without it there are none, and it connects 6 to 11 seconds after boot. Reloading in place with `modprobe brcmfmac feature_disable=0`, same AP and same profile in the same session, connected immediately and then roamed across four BSSIDs including one that had been failing minutes earlier.

#### Suggested fix

```diff
-    lspci -nn | grep -E "14e4:(43ba|43bb|43bc|43a3|43dc|4464|4488|4425|4433)" >/dev/null; }; then
+    lspci -nn | grep -E "14e4:(43ba|43bb|43bc|43a3|43dc|4464|4488)" >/dev/null; }; then
```

An `[[ $(uname -m) == x86_64 ]]` guard would also work and would survive future IDs being added. I have no BCM4378 to test, so dropping `4425` is precautionary rather than confirmed.

Workaround until then: a later-sorting drop-in wins, since the kernel keeps the last value for a scalar parameter.

```
# /etc/modprobe.d/zz-brcmfmac-keep-offload.conf
options brcmfmac feature_disable=0
```

Full `omarchy debug` output available on request. I left it out because it runs to 3280 lines and carries a username, MAC and SSID throughout.

Thanks for the #6652 work. This is a narrow follow-up rather than a complaint: the quirk is clearly right for the hardware it was tested on, and the ID list just reaches two parts nobody had one of.