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.

1 files changed, 8 insertions, 5 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