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.

1 files 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).