Skip to content

Harden Bluetooth tests against transient QCA controller initialization failures seen on the first CI attempt. - #553

Merged
Bhargav-qcom (bhargav0610) merged 3 commits into
qualcomm-linux:mainfrom
smuppand:fix/bluetooth-first-boot-recovery
Aug 27, 2026
Merged

Harden Bluetooth tests against transient QCA controller initialization failures seen on the first CI attempt.#553
Bhargav-qcom (bhargav0610) merged 3 commits into
qualcomm-linux:mainfrom
smuppand:fix/bluetooth-first-boot-recovery

Conversation

@smuppand

Copy link
Copy Markdown
Contributor

Harden Bluetooth tests against transient QCA controller initialization failures seen on the first CI attempt.

Changes

  • Require an active Bluetooth service and a valid non-zero BD address.
  • Add bounded rfkill and service recovery attempts.
  • Prevent public-addr configuration with invalid addresses.
  • Bound potentially hanging bluetoothctl operations.
  • Apply recovery handling to firmware, power, scan, and pairing suites.
  • Use the shared testcase result API.
  • Expose recovery timing through LAVA parameters.

Bluetooth controllers can appear before QCA firmware initialization has completed, leaving an all-zero BD address and causing the first CI run to fail while a rerun passes. Existing readiness checks accepted service and HCI presence alone, and nested bluetoothctl polling could consume most of the LAVA timeout.

Require an active service and a valid non-zero controller address, add bounded rfkill and service recovery attempts, and prevent public-addr setup for invalid addresses. Route controller, scan, and power queries through bounded helpers so a stalled BlueZ command cannot exhaust the job timeout.

Signed-off-by: Srikanth Muppandam <[email protected]>
QCA firmware initialization can leave an HCI device present with an all-zero address during the first boot. BT_FW_KMD_Service and BT_ON_OFF previously continued from that incomplete state or skipped missing BlueZ controller visibility, producing failures that disappeared on rerun.

Gate both suites on the shared bounded runtime recovery, retain the recovered adapter, and fail only after recovery is exhausted. Use the shared result API and expose recovery timing through the LAVA parameters for deterministic CI behavior.

Signed-off-by: Srikanth Muppandam <[email protected]>
The scan and pairing suites could start while the Bluetooth service and QCA controller were only partially initialized. A missing controller was treated as a skip in some paths, while repeated unbounded setup calls made first-attempt failures expensive.

Require bounded runtime recovery before scanning or pairing, reuse the validated adapter, and keep result files machine-readable through the shared result API. Normalize argument handling and LAVA parameters so recovery and scan timing can be tuned consistently.

Signed-off-by: Srikanth Muppandam <[email protected]>
@bhargav0610
Bhargav-qcom (bhargav0610) merged commit 6122d03 into qualcomm-linux:main Aug 27, 2026
14 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