fix(bluetooth): recover a controller that wedges across resume on Apple Silicon

[n0mahd]

Addresses the resume half of #338 (upstream AsahiLinux/linux#604). The "Bluetooth keyboard cannot wake" half is separate and is not touched here.

Problem

On Apple Silicon Macs the Broadcom Bluetooth firmware can wedge across s2idle. After resume the controller stops answering HCI commands: the kernel logs hci0: command 0x0c01 tx timeout every couple of seconds, every connect fails, and neither the bar toggle nor bluetoothctl power on brings it back. From the user's side, a device that was paired and working yesterday won't connect after the lid is opened. Only unbinding and rebinding hci_bcm4377 clears it.

Fix

omarchy-bluetooth-resume-fix, run by a oneshot service ordered after the sleep targets. It follows the same pattern as fix-wifi-resume.sh for the Wi-Fi half of the same chip.

• It rebinds only when the tx timeout signature appears after the last PM: suspend entry, so on machines and kernels where the bug doesn't happen it does nothing, and it stops acting by itself if the bug is ever fixed upstream.
• It reads from the suspend entry marker because the kernel logs PM: suspend exit after device resume, behind the timeouts, and because timeouts that get written to the journal before the service starts must still be counted.
• It leaves a soft-blocked radio alone (the off state that omarchy-bluetooth-power sets) and reports an unbound driver instead of guessing an address.
• It is installed for BCM4378 (14e4:5f69, verified) and BCM4387 (14e4:5f71, same failure reported in Clamshell s2idle: Bluetooth keyboard cannot wake; lid-open resume wedges hci_bcm4377 #338 / Bar Bluetooth toggle (rfkill) hangs BRCM4387 firmware; cannot power adapter back on #302). BCM4388 is left out on purpose: the only report for it is the rfkill path that fix(bluetooth): power off adapters via BlueZ before rfkill block to prevent PCIe driver lockup #380 handles.
• migrations/1789670852.sh installs it on existing machines, and does nothing if another user on the machine already installed it.

Testing

• Shell tests: test/shell.d/bluetooth-resume-fix-test.sh, 8 cases, all pass: no timeouts leaves the controller alone, timeouts trigger a rebind, timeouts logged before the service starts are still counted, falls back when the suspend marker is missing, leaves a blocked or absent radio alone, reports an unbound driver.
• Hardware: M1 MacBook Air (J313, BCM4378). Pointed at a real resume wedge (79 tx timeouts in one boot), it detected the wedge and the controller was back 0s after the rebind, without a reboot.
• bin/omarchy commands --check passes, and every bin/omarchy-* passes its syntax check. In ./test/all, the only failures are three tests that need an omarchy-pkgs checkout (package-build-contract, settings-package-units, unowned-system-paths), and they fail the same way on quattro.

Not covered

A wedge that happens while the machine is awake (seen once on the same machine). This only runs after resume.

🤖 Generated with Claude Code

[oliverlukschander]

BCM4388 (14e4:5f72) wedges across resume on its own too — no rfkill involved.

MacBook Pro 16" M2 Pro (t6020), Aurora kernel 7.1.12, stock hci_bcm4377: 2 of the 7 suspends in this machine's journal (09-25, 09-27; s2idle via lid and via F6, sleeps from 15 s to 3 h 50 m) ended with exactly this PR's signature during device resume — hci0: command 0x0c01 tx timeout, then Opcode 0x0c1a / 0x202d / 0x2041 failed: -110 and Unable to disable LL privacy (the hci_resume_sync() sequence), all before PM: suspend exit. The firmware itself was gone (all ten control-ring messages timed out at modprobe -r), and modprobe -r hci_bcm4377 && modprobe hci_bcm4377 brought it back without a reboot, which is what this PR's rebind does. The Wi-Fi function on the same chip (01:00.0) resumed normally each time. One more reason to cover it: the blocked resume callback holds PM: suspend exit back by ~8 s (the four 2 s HCI timeouts), so the whole wake is slower until the rebind.

So the 5f72 exclusion (and the test that asserts it) could go. Happy to test a revision on this machine.

[malik-na]

Thanks @n0mahd. The Apple Silicon packages moved to omacom/omarchy-mac-pkgs, so this is ported there as omacom/omarchy-mac-pkgs#21, with you as co-author. It also covers BCM4388 after @oliverlukschander's report above. I'll close this one when that merges.