Skip to content

BT_ON_OFF: add Bluetooth power-on retry and failure diagnostics#466

Merged
abbajaj806 merged 2 commits into
qualcomm-linux:mainfrom
smuppand:bt-scan-fix
Jun 1, 2026
Merged

BT_ON_OFF: add Bluetooth power-on retry and failure diagnostics#466
abbajaj806 merged 2 commits into
qualcomm-linux:mainfrom
smuppand:bt-scan-fix

Conversation

@smuppand
Copy link
Copy Markdown
Contributor

Improve BT_ON_OFF reliability and failure triage for Bluetooth controller power-cycle validation.

The test now adds a configurable OFF-to-ON settle delay and controlled Power ON retry flow. This helps handle timing-sensitive QCA/WCN UART controllers that may not be ready immediately after Powered=no.

The PR also improves Bluetooth diagnostics so LAVA failures include enough evidence to distinguish controller recovery issues, firmware/NVM transfer failures, rfkill state problems, bluetoothd issues, and platform timing problems.

Failure mode now collects:

  • hciconfig -a
  • bluetoothctl list
  • bluetoothctl show
  • rfkill list
  • systemctl status bluetooth --no-pager
  • journalctl -u bluetooth -b --no-pager | tail -100
  • Bluetooth-related dmesg tail
  • scan_dmesg_errors output when a test path is provided
  • target-agnostic Bluetooth firmware candidates under QCA firmware roots

Firmware diagnostics are no longer hardcoded to QCA6698; the helper now scans generic QCA firmware locations and uses print_path_meta() when available to avoid fragile ls parsing.

Runner/suites/Connectivity/Bluetooth/BT_ON_OFF/[run.sh](http://run.sh/)

Add runtime-configurable controls:

  • BT_POWER_CYCLE_DELAY
  • BT_POWER_ON_ATTEMPTS
  • BT_POWER_ON_RETRY_DELAY
  • BT_RESTART_SERVICE_ON_RETRY

smuppand added 2 commits May 31, 2026 20:16
Enhance btloghcidiag() to support lightweight and failure diagnostic
modes.

The basic mode now keeps controller visibility diagnostics concise, while
failure mode collects deeper evidence including hciconfig -a,
bluetoothctl show/list, rfkill state, bluetooth.service status,
Bluetooth journal logs, Bluetooth-related dmesg, scan_dmesg_errors
output, and Bluetooth firmware candidates.

Make firmware discovery target-agnostic by scanning generic QCA firmware
locations instead of hardcoding a single QCA6698 path. Use existing
print_path_meta() when available to avoid fragile ls-based file listing.

This improves LAVA failure triage for QCA/WCN Bluetooth controller
recovery issues without adding noise to passing runs.

Signed-off-by: Srikanth Muppandam <smuppand@qti.qualcomm.com>
Add configurable OFF-to-ON settle delay and controlled power-on retry
handling to the BT_ON_OFF test.

Some QCA/WCN UART Bluetooth controllers may not recover immediately after
Powered=no. In LAVA this can lead to power-on failures during firmware or
NVM setup, such as HCI command timeouts, while the same image may pass in
a local setup.

The test now:
- waits before requesting Power ON after successful Power OFF
- retries Power ON using configurable attempt and delay values
- optionally unblocks Bluetooth through rfkill before retry
- optionally restarts bluetooth.service before retry
- captures full Bluetooth diagnostics on real failure paths
- keeps persistent failure to restore Powered=yes as a test failure
- reports retry recovery as PASS with warning

Update the BT_ON_OFF LAVA YAML to expose the new runtime knobs while
preserving the existing single BT_ON_OFF.res result flow.

Signed-off-by: Srikanth Muppandam <smuppand@qti.qualcomm.com>
Copy link
Copy Markdown
Contributor

@abbajaj806 abbajaj806 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@abbajaj806 abbajaj806 merged commit 29c99e3 into qualcomm-linux:main Jun 1, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants