From d6c51ae3ae0cd51b3f3832e831e1d2c28f6b2276 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Tue, 6 Oct 2026 01:41:47 -0600 Subject: 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. --- tests/bluetooth-resume/test_bluetooth_resume.py | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'tests/bluetooth-resume') 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 -- cgit v1.2.3