T2 MacBook suspend/resume + TouchBar (tiny-dfr) fix (kernel 7.x)

[fellow-11]

Overview

Working suspend/resume setup with automatic TouchBar restoration, tested on a MacBook Pro 16,1 (2019) with kernel 7.0.5-arch1-Watanare-T2-1-t2.

⚠️ Power consumption during sleep has not been tested.

Hardware

• MacBook Pro 16,1 (2019)
• AMD RX 5500M + Intel UHD 630 iGPU
• Touch Bar

The Problem

T2 modules (apple_bce, hid_appletb_kbd, hid_appletb_bl) must be unloaded before suspend and reloaded after resume, otherwise the system hangs or fails to resume properly.

On kernels 6.12.31+, appletbdrm fails to rebind to the TouchBar USB device after module reload. This was confirmed in t2linux/wiki#635 and reproduced on kernel 7.0.5. The root cause appears to be a USB communication timeout during appletbdrm_probe(), which appears to mean the TouchBar device isn't ready when the driver tries to initialize it.

The fix, discovered by @xing0r in that issue, is to force USB re-enumeration by resetting bConfigurationValue to 0 then back to 2, giving the device time to reset properly before tiny-dfr starts.

Solution

0. Disable hibernation and configure suspend

In /etc/systemd/logind.conf, set the sleep operation to suspend:

SleepOperation=suspend
HandlePowerKey=SleepOperation
HandleLidSwitch=SleepOperation
HandleLidSwitchExternalPower=SleepOperation
HandleLidSwitchDocked=SleepOperation

Note: If you want the laptop to stay on when docked (lid closed with external monitor), use HandleLidSwitchDocked=ignore instead.

In /etc/systemd/sleep.conf, enable suspend and disable hibernation:

AllowSuspend=yes
AllowHibernation=no
AllowSuspendThenHibernate=no

Then reload:

sudo systemctl daemon-reload

1. Suspend service - unload T2 modules before sleep

/etc/systemd/system/suspend-fix-t2.service:

[Unit]
Description=Fix T2 suspend
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl stop tiny-dfr
ExecStart=-/usr/bin/rmmod -f hid_appletb_kbd
ExecStart=-/usr/bin/rmmod -f hid_appletb_bl
ExecStart=-/usr/bin/rmmod -f appletbdrm
ExecStart=-/usr/bin/rmmod -f apple_bce
RemainAfterExit=yes

[Install]
WantedBy=sleep.target

2. Resume service - reload modules and restore TouchBar

/etc/systemd/system/resume-fix-t2.service:

[Unit]
Description=Reload T2 modules after resume
After=suspend.target

[Service]
Type=oneshot
ExecStart=/usr/bin/sleep 4
ExecStart=/usr/bin/modprobe apple_bce
ExecStart=/usr/bin/sleep 4
ExecStart=/usr/bin/modprobe hid_appletb_bl
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/modprobe hid_appletb_kbd
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/bash -c "echo 0 > /sys/bus/usb/devices/7-6/bConfigurationValue"
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/bash -c "echo 2 > /sys/bus/usb/devices/7-6/bConfigurationValue"
ExecStart=/usr/bin/sleep 3
ExecStart=/usr/bin/systemctl restart tiny-dfr

[Install]
WantedBy=suspend.target

Enable both services:

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

3. Hyprland lid switch binding

In ~/.config/hypr/hyprland.conf:

bindl = , switch:on:Lid Switch, exec, systemctl suspend

4. Disable TouchBar USB autosuspend (workaround for long suspends)

Create /etc/udev/rules.d/99-touchbar-power.rules:

SUBSYSTEM=="usb", ATTR{idVendor}=="05ac", ATTR{idProduct}=="8302", ATTR{power/control}="on", ATTR{power/autosuspend_delay_ms}="-1"

Then reload udev:

sudo udevadm control --reload-rules
sudo udevadm trigger

Important: find your TouchBar USB path

The resume service hardcodes 7-6 as the TouchBar USB path. This may be different on your machine. If it doesn't match, the TouchBar won't restore after resume. Find your path with:

for dev in /sys/bus/usb/devices/*/; do
  echo "$dev: $(cat $dev/idProduct 2>/dev/null) - driver: $(readlink $dev/driver 2>/dev/null | xargs basename 2>/dev/null)"
done

Look for product ID 8302, that's the TouchBar display device. Replace 7-6 in the resume service and manual fallback below with your actual path.

Manual fallback

If the TouchBar doesn't restore after resume, run:

echo 0 | sudo tee /sys/bus/usb/devices/7-6/bConfigurationValue
sleep 1
echo 2 | sudo tee /sys/bus/usb/devices/7-6/bConfigurationValue
sleep 3
sudo systemctl restart tiny-dfr

Unknowns

• Power consumption during sleep has not been measured.
• Only tested on MacBook Pro 16,1 (2019). Results may vary on other T2 models.
• The timing delays in the resume service are conservative and may be reducible.

Tested up to 9 hours successfully with the udev workaround. A proper kernel fix might be added. For now, I'll be looking out for it and will update this discussion ASAP.

References

• Omarchy lid/sleep/suspend issue on MacBook (bug + solution to be tested) #1840 - original T2 suspend/TouchBar issue report on Omarchy
• Fix suspend/sleep on T2 MacBooks #5129 - open Omarchy PR for an official T2 suspend/TouchBar fix (unmerged at time of writing)
• TouchBar appletbdrm the module reload functionality is broken, not the initial loading!  t2linux/wiki#635 - appletbdrm rebinding failure on kernel 6.12.31+; source of the USB re-enumeration workaround used in this solution

Claude (Anthropic) helped me find relevant discussions and issues, and helped put everything together.

[ghrubi]

Thanks for this and I'll try it on my machine. This is the last missing piece for a perfectly functional 2019 MacBook Pro 16,1!
I have the fans working properly, touchpad disable-while-typing enabled, touchbar screen and keyboard brightness controls working, and even the touchbar brightness working.

[fellow-11]

You're welcome. Please let me know if it works for your machine.

[ghrubi]

This is working well! Thanks again for your work!

[xing0r]

Great write-up! I especially appreciate that you adapted the fix from an gentoo OpenRC/elogind setup to systemd — that's exactly what makes it useful for Omarchy users.

One thing I wouldn't have thought of myself: you correctly identified that the USB path isn't fixed. On my machine it was 5-6, on yours it's 7-6 — good catch to include the detection command rather than hardcoding it.

I also have to admit that when the issue sat untouched for almost a year, I started thinking I might be the only person actually using suspend on an Intel T2 Mac under Linux. Glad to see that's not the case!

best regards xing0r

[fellow-11]

Update: The fix works for short suspends but fails after long suspends if hibernation is enabled. The issue is AllowSuspendThenHibernate=yes in /etc/systemd/sleep.conf. With AllowSuspendThenHibernate=yes, the system transitions to hibernate after a set amount of time, which causes the BCE controller to drop power to the TouchBar USB device in a way it can't recover from.
Make sure hibernation is disabled in /etc/systemd/sleep.conf:

AllowHibernation=no
AllowSuspendThenHibernate=no
#HibernateDelaySec=10

After this change, suspend-only works. Tested with a 26 minute suspend.

Reliability over longer suspend periods (hours, overnight) is unknown. Once tested, I will add it to the original discussion.

[fellow-11]

Tested with a 4 hour suspend, worked perfectly. Gonna try tonight for a full 8 hour suspend.

[fellow-11]

8.5 hour suspend test: TouchBar did not restore after resume. The fix works reliably for shorter suspends (tested up to 4 hours) but fails after very long suspends. Root cause appears to be the T2 chip cutting power to the TouchBar USB device after extended periods, which can't be recovered without a reboot. Investigation ongoing.

[xing0r]

36 days uptime — kernel 6.18.31-gentoo-t2
Suspend active most of the time, sometimes 2–3 days at a stretch. Longest uninterrupted suspend: ~1 week.

Just wanted to share some encouraging data points. My machine (MacBook Pro 2020 Intel — last Intel model before the M1) has been running for 36 days uptime, spending most of that time in suspend. The longest uninterrupted suspend I've had was around one week, with the TouchBar recovering correctly every time.

That said, I wouldn't want to suggest this translates directly to your setup — different distro, different kernel, different MacBook model. Just meant as motivation to keep digging: analyzing logs, testing edge cases, etc. Long suspends can work on T2 hardware.

---

One more thing worth mentioning: I've used the workaround script before and it does work, but I'm currently reverting the commit that introduced the regression instead. If you're building your own kernel, this is straightforward:

cd /usr/src/linux   # your kernel source directory
curl -s "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=bfc66c4c28041ffb199fbbdbeedf336a4ef25356" | patch -R -p1

What this actually does and why it helps the T2:

Commit bfc66c4c removed a synchronization guard (a device_lock() mutex) from the driver core that ensured a device finishes initializing before anything else can query its state.

On resume from suspend, the T2 chip's TouchBar driver (appletbdrm) has to re-initialize through really_probe(). Without the guard, udev can query the device's state at exactly the wrong moment — before initialization is complete — which breaks the probe with -ETIMEDOUT and leaves the TouchBar dead. This race is much more likely on resume than on boot, because resume triggers a lot of concurrent activity (udev events firing, services restarting, network coming up) that creates the exact timing window needed to hit the bug.

Why was the guard removed in the first place?

The device_lock() approach could trigger lockdep warnings about circular lock dependencies in subsystems like CXL (Compute Express Link, mostly server/datacenter hardware) and VFIO. Those reports are real and reproducible on the affected hardware, which is why upstream has been trying to find a synchronization mechanism that works without holding device_lock() across uevent_show(). There have been several attempts (including an synchronize_rcu()-based fix that was later reverted because it caused hung-task issues with VFIO) — at the time of writing, the situation upstream is not fully resolved.

The key point for T2 users: the deadlock path that motivated removing the guard requires hardware/subsystems that simply don't exist on a MacBook. No CXL, no VFIO module juggling during sysfs reads. So reverting bfc66c4c trades a theoretical risk we can't actually hit for fixing a regression that hits us on every resume. 36 days of uptime with frequent long suspends and no issues bear this out in practice.

regards

[xing0r]

@fellow-11 — for your specific situation with the linux-t2 Arch kernel from NoaHimesaka1873, the cleanest path forward would probably be to open an issue or PR over at linux-t2-arch asking the maintainers to include the revert of bfc66c4c in the official package.

That way you wouldn't have to build your own kernel, and every other T2 Omarchy/Arch user would automatically get a working TouchBar after resume — including after long suspends where the bConfigurationValue workaround can't recover the device (probably because the TouchBar is fully powered down at that point and the userspace re-configure can't bring it back; the kernel's own resume path can, but only if the synchronization guard is in place).

You can point them to my comment above for the technical explanation: what bfc66c4c removed and why, why upstream removed it (CXL/VFIO lockdep concerns), and why those deadlock paths simply aren't reachable on T2 hardware. The relevant bits in short:

• bfc66c4c removed a device_lock() mutex from the driver core that ensured devices finish probing before their state can be queried.
• On resume, this creates a race where udev can interrupt appletbdrm's probe and leave the TouchBar in -ETIMEDOUT.
• The race is much more likely on resume than boot, and even more so on long suspends where the TouchBar has fully powered down and needs a full re-init.
• The deadlock that motivated removing the guard requires CXL or VFIO subsystem activity — neither exists on a MacBook.
• Reverting it on the T2 kernel trades a theoretical risk we can't trigger for fixing a regression every T2 user hits.

The patch itself is just:

curl -s "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=bfc66c4c28041ffb199fbbdbeedf336a4ef25356" | patch -R -p1

If the maintainers are open to it, this becomes a one-line addition to their patch set and everyone benefits. Worth a try at least — and if they have concerns about including it, that conversation alone would be valuable for understanding the upstream situation better.

regards

[fellow-11]

Found a workaround for the long suspend issue. Adding a udev rule to disable USB autosuspend for the TouchBar device fixed it, and I tested successfully with a 9 hour suspend.

Create /etc/udev/rules.d/99-touchbar-power.rules:

SUBSYSTEM=="usb", ATTR{idVendor}=="05ac", ATTR{idProduct}=="8302", ATTR{power/control}="on", ATTR{power/autosuspend_delay_ms}="-1"

Then reload udev:

sudo udevadm control --reload-rules
sudo udevadm trigger

Note: this is a workaround, @xing0r identified the actual root cause in the comments above. I've opened an issue on the linux-t2-arch repo requesting the revert: NoaHimesaka1873/linux-t2-arch#182

[juanjodarko]

Thanks for this write up @fellow-11 I'm testing it on my machine later today and will report back on results. Installed yesterday on my Macbook 16 2019 and was looking for a solution to this

[voioo]

This is awesome, will test on Macbook Pro 2019 13 inch asap and let you guys know. 🍻

[voioo]

Tested this on a 2019 T2 MacBook Pro 13" on Omarchy / Arch T2 kernel 7.0.10-arch1-Watanare-T2-2-t2.

The Touch Bar / tiny-dfr part from this discussion works for me, but I also needed to extend the suspend/resume units for the Broadcom Wi-Fi/Bluetooth device.

On my machine the relevant PCI functions are:

0000:01:00.0 -> Wi-Fi      -> brcmfmac
0000:01:00.1 -> Bluetooth -> hci_bcm4377
0000:06:00.0 -> Thunderbolt USB controller -> xhci_hcd

The important bit was not treating Wi-Fi and Bluetooth as the same thing. Wi-Fi recovery was already needed and working via brcmfmac, but Bluetooth still failed to reconnect after resume until I added a Bluetooth-only unbind/bind plus bluetooth.service restart.

My current working additions are below.

In suspend-fix-t2.service, before unloading the T2 modules:

ExecStart=-/usr/bin/bash -c 'if [ -L /sys/bus/pci/devices/0000:06:00.0/driver ]; then echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind; fi'
ExecStart=-/usr/bin/bash -c 'if [ -L /sys/bus/pci/devices/0000:01:00.0/driver ]; then echo 0000:01:00.0 > /sys/bus/pci/drivers/brcmfmac/unbind; fi'
ExecStart=-/usr/bin/bash -c 'if [ -L /sys/bus/pci/devices/0000:01:00.1/driver ]; then echo 0000:01:00.1 > /sys/bus/pci/drivers/hci_bcm4377/unbind; fi'

In resume-fix-t2.service, after restarting tiny-dfr:

ExecStart=-/usr/bin/bash -c 'if [ ! -L /sys/bus/pci/devices/0000:06:00.0/driver ]; then echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/bind; fi'
ExecStart=-/usr/bin/bash -c 'if [ ! -L /sys/bus/pci/devices/0000:01:00.0/driver ]; then echo 0000:01:00.0 > /sys/bus/pci/drivers/brcmfmac/bind; fi'
ExecStart=-/usr/bin/bash -c 'if [ ! -L /sys/bus/pci/devices/0000:01:00.1/driver ]; then echo 0000:01:00.1 > /sys/bus/pci/drivers/hci_bcm4377/bind; fi'
ExecStart=-/usr/bin/systemctl restart bluetooth
ExecStart=-/usr/bin/bash -c 'sleep 8; networkctl status wlan0 --no-pager | /usr/bin/grep -q "State: routable" || /usr/bin/systemctl restart iwd'

I tested the Bluetooth part without suspending first:

sudo bash -c 'echo 0000:01:00.1 > /sys/bus/pci/drivers/hci_bcm4377/unbind; sleep 2; echo 0000:01:00.1 > /sys/bus/pci/drivers/hci_bcm4377/bind'
sudo systemctl restart bluetooth.service

That immediately brought Bluetooth back, and adding the same sequence to the resume service made Bluetooth reconnect properly after suspend.

Also worth noting: on my machine the Touch Bar USB path is 5-6, not 7-6, so the existing warning about detecting the path is important.

Current result: suspend/resume works, Touch Bar comes back, Wi-Fi comes back, and Bluetooth comes back.

[jjohnson]

Saw this discussion after being active in #4695. Have been working on a different approach in PR #5998 that avoids force removal (rmmod -f), hardcoded sleeps, and USB bConfigurationValue resets entirely — clean aaudio unbind + ordered module lifecycle.

Already confirmed working on MacBookPro15,4 and MacBookAir8,1 with deep sleep (no s2idle workarounds needed). The 16,1 dGPU model is the one we haven't tested yet — would be great if someone here could try it.

@fellow-11 — the appletbdrm probe failure you're seeing after long suspends might be addressed by our approach since we reload appletbdrm through clean module management rather than force removal. And the kernel revert @xing0r found (bfc66c4c) looks complementary regardless.

[Keloran]

whilst not perfect I have increased support in my fork of tiny-dfr it appears to have all the bits needed to resume/restore

Ive also added a few more features e.g. hyprland window title, workspace number, weather, sliders for volume/brightness/backlight

again its not perfect, but it appears to work pretty well, saying this the t2-mbp that ive been building this on is not my daily driver