From 73a2a5e6a7fd582bccab858b3b7e9a1c61e6e750 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Mon, 5 Oct 2026 23:02:17 -0600 Subject: docs(bluetooth): drop the claim that zz- orders the hook after TLP systemd-sleep runs every hook in parallel, so the prefix orders nothing. The comment now says where the settle still wins (a hibernate-class wake) and where the race with tlp resume's state replay stays open (a plain suspend), with the rfkill tell for it. --- scripts/zz-bluetooth-resume | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/scripts/zz-bluetooth-resume b/scripts/zz-bluetooth-resume index 4273339..ce05578 100755 --- a/scripts/zz-bluetooth-resume +++ b/scripts/zz-bluetooth-resume @@ -28,8 +28,14 @@ # A machine whose TLP config does not ask for bluetooth keeps it off, which is # what stops this from overriding a deliberate block at every wakeup. # -# The zz- prefix orders it after TLP's own hook, so `tlp resume` has finished -# before this runs. +# The zz- prefix buys no ordering: systemd-sleep runs every hook here in +# parallel (man systemd-sleep), so `tlp resume` may still be running when +# this starts, and its first act is to replay the rfkill state it saved at +# suspend. On a hibernate-class wake the settle between unload and load below +# usually lands the final unblock after that replay. A plain suspend has no +# settle and unblocks at once, so that race is open. The tell is `rfkill list +# bluetooth` reading "Soft blocked: yes" after a suspend cycle that was entered +# with bluetooth already blocked (a hook that never ran reads the same way). # # Test seams: BTR_RFKILL, BTR_MODPROBE, BTR_TLP_CONF, BTR_TLP_CONF_DIR, # BTR_SETTLE (seconds to wait between driver unload and load). -- cgit v1.2.3