Is suspend / hybernate supposed to work?

[RayBB]

On my 2020 MacBook air suspend doesn't seem to work at all. It just pops you right back to the login screen and then the wifi is disabled too.

Is it supposed to work?

If not, perhaps we can add it to the readme.

[RishonDev]

Patches are being worked on. As of now deqrocks, has worked on a script as a workaround.

[deqrocks]

On my 2020 MacBook air suspend doesn't seem to work at all. It just pops you right back to the login screen and then the wifi is disabled too.

Is it supposed to work?

If not, perhaps we can add it to the readme.

Unload brcmfmac, brcmfac_wcc and hci_bcm4377 with a systemd sevice like stated in the wiki.

[RayBB]

@deqrocks where in the wiki does it mention a systemd service with hci_bcm4377 ?

I see this systemd service for the fedora guide that is related but not mentioning that specifically.
https://wiki.t2linux.org/distributions/fedora/faq/#my-wi-fi-stops-working-after-suspending

Will adding these unloads fix theissue of suspend putting you on the login screen right away?

[deqrocks]

@deqrocks where in the wiki does it mention a systemd service with hci_bcm4377 ?

I see this systemd service for the fedora guide that is related but not mentioning that specifically. https://wiki.t2linux.org/distributions/fedora/faq/#my-wi-fi-stops-working-after-suspending

Will adding these unloads fix theissue of suspend putting you on the login screen right away?

https://wiki.t2linux.org/guides/postinstall/ and go to Suspend Workaround on the bottom. Replace apple-bce with hci_bcm4377. Or use the suspend fix script from my repos. It will do that for you. https://github.com/deqrocks/t2-suspend-fix-script

[RayBB]

Here's a relevant PR where folks are working on this for another distro. Lots of activity there.
omacom/omarchy#5998

[deqrocks]

That looks like an AI race for the most sloppiest workaround in my admittedly brutally honest opinion.

[wook7240]

Adding measured data on the suspend workaround, since I couldn't find
concrete numbers anywhere and one of the failure modes is invisible in logs.

System

• MacBookAir9,1 (2020, Ice Lake), BCM4377b
• Linux Mint 22.3, kernel 7.1.8-1-t2-noble
• bluez 5.72
• Kernel cmdline: pm_async=off intel_iommu=on iommu=pt mem_sleep_default=s2idle

Baseline: without any workaround, suspend aborts

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

The system wakes immediately and both WiFi and Bluetooth are left broken.
The usual fix is to unbind the drivers in a systemd-sleep hook.

Measured cost of each step

operation	time
brcmfmac unbind	0.70 s
hci_bcm4377 unbind	10.32 s
hci_bcm4377 bind	5.50 s (returned failure)
brcmfmac bind	0.11 s
modprobe -r brcmfmac_wcc brcmfmac	0.70 s
modprobe brcmfmac	0.14 s

Lid close -> PM: suspend entry:

hook variant	delay
unbind both (common workaround)	12.3 s
unbind WiFi only	1.3 s
unbind both + disconnect first	13.3 s

So essentially the entire delay is the hci_bcm4377 unbind. Unloading the
modules instead of PCI-unbinding made no difference for the WiFi side.

Finding 1: the Bluetooth unbind cannot be dropped, and it fails silently

Dropping only the hci_bcm4377 unbind makes suspend enter in 1.3 s and
the D3 timeout does not come back — so the WiFi unbind alone is what
prevents the suspend abort.

But after resume the Bluetooth controller is wedged:

Bluetooth: hci0: command 0x0406 tx timeout
Bluetooth: hci0: Opcode 0x0c24 failed: -110

repeating every ~2 s indefinitely. bluetoothctl show still prints a
controller (cached by bluetoothd) and /sys/class/bluetooth/hci0 still
exists, so it looks healthy at a glance, but no command completes.

This is the part worth flagging: Bluetooth produces no D3 / suspend error
at all. Unlike brcmfmac, which loudly logs the enter_D3 timeout, the
Bluetooth function just stops responding. Anyone reasoning from the logs
alone will conclude the Bluetooth unbind is unnecessary. It isn't.

Finding 2: PCI unbind never disconnects paired devices

unbind yanks the controller without sending an HCI Disconnect, so paired
audio devices don't learn the link is gone. With headphones connected,
closing the lid produced no disconnect tone at all; the tone finally played
after resume, ~90 s later, when the device's own timeout expired. Until
then the headphones could not be handed over to a phone.

Sending a normal disconnect before unbinding fixes that:

for MAC in $(timeout 5 bluetoothctl devices Connected 2>/dev/null | awk '{print $2}'); do
    timeout 5 bluetoothctl disconnect "$MAC" >/dev/null 2>&1 || true
done
sleep 1

Headphones now release ~1 s after the lid closes. Note this does not
reduce the 10.3 s unbind — that cost is fixed and unrelated to whether a
link is up. It is purely a usability fix.

Finding 3: boot-time probe failure has two distinct modes

hci_bcm4377 0000:73:00.1: probe with driver hci_bcm4377 failed with error -110

happens intermittently at boot, in two forms:

• A. /sys/class/bluetooth is empty — the driver detached cleanly
• B. the node still exists but the controller does not respond
  (bluetoothctl show -> No default controller available), preceded by
  failed to destroy transfer ring N / failed to destroy completion ring N,
  one per second for ~10 s

Recovery scripts that test only for the existence of /sys/class/bluetooth
handle A and silently skip B. A check that also requires the driver binding
(/sys/bus/pci/drivers/hci_bcm4377/0000:73:00.1) and an actual controller
response is needed. Recovery for B is unbind -> PCIe FLR -> bind.

Warning about boot-time recovery services

I added a oneshot service that checks Bluetooth health at boot and resets the
PCI function if needed. If it happens to run while a suspend is starting, it
sees the sleep hook's unbind, concludes the controller is dead, and issues an
FLR reset on 73:00.1 mid-suspend. That hard-hangs the machine — no shutdown
record, power button gives a cold boot. Anything doing PCI resets at boot
should first check that no suspend is in progress, or run late enough to be
clearly separated from it.

Hook currently in use

#!/bin/bash
WIFI="0000:73:00.0"
BT="0000:73:00.1"

case "$1" in
  pre)
    for MAC in $(timeout 5 bluetoothctl devices Connected 2>/dev/null | awk '{print $2}'); do
        timeout 5 bluetoothctl disconnect "$MAC" >/dev/null 2>&1 || true
    done
    sleep 1
    echo "$WIFI" > /sys/bus/pci/drivers/brcmfmac/unbind 2>/dev/null || true
    echo "$BT"   > /sys/bus/pci/drivers/hci_bcm4377/unbind 2>/dev/null || true
    ;;
  post)
    echo "$WIFI" > /sys/bus/pci/drivers/brcmfmac/bind 2>/dev/null || true
    sleep 2
    echo "$BT"   > /sys/bus/pci/drivers/hci_bcm4377/bind 2>/dev/null || true
    sleep 1
    rfkill unblock bluetooth 2>/dev/null || true
    ;;
esac

Stopping NetworkManager in the hook turned out to be unnecessary — it already
transitions to ASLEEP on its own (manager: NetworkManager state is now ASLEEP),
and removing it changed nothing about WiFi reconnecting after resume.

Suspend is reliable with this, 13 s to enter.

Practical impact

In day-to-day use none of this actually hurts. You rarely suspend within a
minute of booting, and you rarely close the lid only to reopen it seconds
later — closing the lid usually means you are moving somewhere. So the ~13 s
entry delay is effectively invisible, and the boot-window hazard is trivial to
avoid. I'm leaving my setup as it is rather than adding more moving parts.

The numbers above are mainly so that anyone hitting this knows what the
workaround actually costs, and why the Bluetooth unbind cannot be removed
even though the logs make it look optional.

Happy to test patches on this hardware if that would help.

[deqrocks]

Don't use AI to file issues. Dont use s2idle. Use deep. Remove all AI slop scripts and run this:

sudo tee /etc/systemd/system/t2-suspend-fix.service >/dev/null <<'EOF'
[Unit]
Description=Unload and Reload Modules for Suspend and Resume
Before=sleep.target
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes

ExecStart=-/usr/bin/modprobe -r brcmfmac_wcc
ExecStart=-/usr/bin/modprobe -r brcmfmac
ExecStart=-/usr/bin/modprobe -r hci_bcm4377


ExecStop=-/usr/bin/modprobe hci_bcm4377
ExecStop=-/usr/bin/modprobe brcmfmac
ExecStop=-/usr/bin/modprobe brcmfmac_wcc

[Install]
WantedBy=sleep.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable t2-suspend-fix.service