### System details

MacBook Air 2020 (MacBookAir9,1, A2179, T2), Broadcom BCM4377b Wi-Fi/Bluetooth, Omarchy 4.0.3, kernel 7.2.4-arch1-Watanare-T2-1-t2

### What's wrong?

Two bugs on this machine, both from the BCM4377 combo chip. I've got working fixes for both, with the full diagnosis and install/rollback steps, here:
https://github.com/austinsomer/omarchy-a2179-t2-bluetooth-suspend-fix

Filing as an issue first so you can decide how (or whether) this fits into `install/hardware/apple/fix-t2.sh`. Happy to open a PR if that's useful.

#### 1. Bluetooth never powers on after boot

`hci_bcm4377` is loaded (thanks to #5145) and `hci0` exists, but the controller never comes up. `bluetoothctl power on` fails with `org.bluez.Error.Failed`. This happened on every boot I checked (5 boots, kernels 7.1.8 and 7.2.4):

```
Bluetooth: hci0: command 0x0c56 tx timeout
Bluetooth: hci0: Opcode 0x0c56 failed: -110
bluetoothd: Failed to set mode: Authentication Failed (0x05)
```

Every boot also logs a DMA write to address 0 from the Bluetooth function right before the driver probes it:

```
DMAR: [DMA Write NO_PASID] Request device [0000:73:00.1] fault addr 0x0 [fault reason 0x05] PTE Write access is not set
```

The chip seems to flake on its first initialization. Unbinding and rebinding `hci_bcm4377` after boot brings it up, though the first rebind often fails with `probe with driver hci_bcm4377 failed with error -110` and a second attempt works. Firmware (matches AdityaGarg8/Apple-Firmware), rfkill and bluez config are all fine.

Fix: a oneshot service that retries the unbind/bind (up to 5 times) until bluez reports the controller powered. It has worked on every boot since I installed it.

#### 2. Suspend never succeeds

Suspend had never once worked on this install. Thousands of attempts, all aborted the same way, and `brcmfmac` is the only device ever named:

```
PM: suspend entry (deep)
brcmfmac 0000:73:00.0: brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate
brcmfmac 0000:73:00.0: PM: failed to suspend: error -5
PM: Some devices failed to suspend, or early wake event detected
```

systemd then retries with s2idle, which fails the same way. With the lid closed, logind keeps retrying about every 30 seconds (371 failed attempts in one 3-hour lid-closed stretch), so the laptop stays awake and warm in a bag.

With `brcmfmac` unloaded, deep suspend and resume work fine with the `mem_sleep_default=deep` / `pm_async=off` defaults from #6562, and the `t2bce` bridge, keyboard, trackpad and audio all come back. Two things I had to learn the hard way while making that into a hook:

- Reloading `brcmfmac` the instant the system wakes hard-crashed the machine (it got to the lock screen, then rebooted, with no logs). Deferring the reload about 15 seconds avoids this.
- `hci_bcm4377` has to be unloaded too. Left bound, it wakes up hung (`hci0: command 0x0c01 tx timeout` at resume), and about a minute later the Bluetooth function raises a PCIe error. DPC then cuts the link to the whole chip, so Wi-Fi dies as well until reboot:

  ```
  pcieport 0000:00:1c.0: AER: Multiple Uncorrectable (Non-Fatal) error message received from 0000:73:00.1
  pcieport 0000:00:1c.0: DPC: containment event, status:0x1f01: unmasked uncorrectable error detected
  brcmfmac 0000:73:00.0: AER: can't recover (no error_detected callback)
  hci_bcm4377 0000:73:00.1: AER: can't recover (no error_detected callback)
  ```

Fix: a `system-sleep` hook that unloads `brcmfmac_wcc`, `brcmfmac` and `hci_bcm4377` before sleep, then 15 seconds after wake reloads `brcmfmac` and reruns the Bluetooth rebind service from part 1. It's only been through one full lid-close cycle so far (about 6 minutes of deep sleep, with Wi-Fi traffic and a Bluetooth scan checked afterward), so I'd treat it as early. It's also only tested on this model. #6862 shows at least one other T2 model failing suspend differently, so this probably wants gating to the BCM4377 rather than all T2 Macs.