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, 6 insertions, 4 deletions

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