docs(bluetooth): say what tlp resume does on the resume edge

The hook's header and its test docstring said the resume edge has no owner, which contradicted the later paragraph on tlp resume replaying the saved rfkill state. Both now say the replay puts bluetooth back where it was at suspend and applies no policy, so a block present at suspend stays.

2 files changed, 14 insertions, 9 deletions

diff --git a/scripts/zz-bluetooth-resume b/scripts/zz-bluetooth-resume
index ce05578..4b51dae 100755
--- a/scripts/zz-bluetooth-resume
+++ b/scripts/zz-bluetooth-resume
@@ -5,13 +5,16 @@
 # A systemd-sleep hook. Two things break bluetooth across sleep on a TLP
 # laptop, and nothing else on the machine fixes either one.
 #
-#   1. The rfkill soft-block is not restored. systemd-rfkill would do it, and
+#   1. The rfkill soft-block is not cleared. systemd-rfkill would do it, and
 #      it is masked here deliberately -- it fights TLP's radio handling, so
 #      configure_tlp_power masks it and TLP owns radios instead. TLP's own
-#      sleep hook runs `tlp resume`, but its setting is
-#      DEVICES_TO_ENABLE_ON_STARTUP: startup, not resume. TLP has no ON_RESUME
-#      at all, so the resume edge has no owner. WiFi survives only because
-#      NetworkManager unblocks itself; bluetooth has no equivalent.
+#      sleep hook runs `tlp resume`, but that only puts bluetooth back where
+#      it was at suspend and applies no policy: its enable setting is
+#      DEVICES_TO_ENABLE_ON_STARTUP, startup not resume, and TLP has no
+#      ON_RESUME at all. So a block present at suspend stays, and so does one
+#      that a controller re-probed after that replay comes up with. WiFi
+#      survives only because NetworkManager unblocks itself; bluetooth has no
+#      equivalent.
 #
 #   2. The controller comes back wedged from a hibernate. It reports powered
 #      and unblocked while scanning finds nothing whatever -- zero devices
diff --git a/tests/bluetooth-resume/test_bluetooth_resume.py b/tests/bluetooth-resume/test_bluetooth_resume.py
index 6d8ed87..62fd24f 100644
--- a/tests/bluetooth-resume/test_bluetooth_resume.py
+++ b/tests/bluetooth-resume/test_bluetooth_resume.py
@@ -3,11 +3,13 @@
 Two things break bluetooth across a sleep cycle on a TLP laptop, and nothing
 else on the machine fixes either.
 
-The rfkill soft-block is not restored. systemd-rfkill would do it, but it is
+The rfkill soft-block is not cleared. systemd-rfkill would do it, but it is
 masked deliberately -- it fights TLP's radio handling, so TLP owns radios
-instead. TLP's own sleep hook runs `tlp resume`, and its setting is
-DEVICES_TO_ENABLE_ON_STARTUP: startup, not resume. There is no ON_RESUME in
-TLP's vocabulary, so the resume edge has no owner at all. WiFi survives only
+instead. TLP's own sleep hook runs `tlp resume`, but that only puts bluetooth
+back where it was at suspend and applies no policy: its setting is
+DEVICES_TO_ENABLE_ON_STARTUP, startup not resume, and there is no ON_RESUME in
+TLP's vocabulary. A block present at suspend stays, and so does one that a
+controller re-probed after that replay comes up with. WiFi survives only
 because NetworkManager unblocks itself; bluetooth has no equivalent.
 
 The controller also comes back wedged from a hibernate. It reports powered and