Bluetooth: hci_qca: Convert timeout from jiffies to ms

[shuaz-shuai]

Since the timer uses jiffies as its unit rather than ms, the timeout value must be converted from ms to jiffies when configuring the timer. Otherwise, the intended 8s timeout is incorrectly set to approximately 33s.

To improve readability, embed msecs_to_jiffies() directly in the macro definitions and drop the _MS suffix from macros that now yield jiffies values: MEMDUMP_TIMEOUT, FW_DOWNLOAD_TIMEOUT, IBS_DISABLE_SSR_TIMEOUT, CMD_TRANS_TIMEOUT, and IBS_BTSOC_TX_IDLE_TIMEOUT.

IBS_WAKE_RETRANS_TIMEOUT_MS and IBS_HOST_TX_IDLE_TIMEOUT_MS are intentionally left unchanged. Their values are stored in the struct fields wake_retrans and tx_idle_delay, which hold ms values at runtime and can be modified via debugfs. The msecs_to_jiffies() conversion happens at each call site against the field value, so it cannot be embedded in the macro.

Wake timer depends on commit c347ca1

Link: https://lore.kernel.org/all/20260511135837.3967550-1-shuai.zhang@oss.qualcomm.com/
Cc: stable@vger.kernel.org
Fixes: d841502 ("Bluetooth: hci_qca: Collect controller memory dump during SSR")
Reviewed-by: Paul Menzel pmenzel@molgen.mpg.de
Acked-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org

CRs-Fixed: 4498534

[shashim-quic]

• Prefix appropriate tag in subject
• add Link: in commit log

[knaveen-qc]

PR #578 — validate-patch

PR: #578

Verdict	Issues	Detailed Report
⚠️	0	Full report

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: PR #578 — FROMLIST: Bluetooth: hci_qca: Convert timeout from jiffies to ms
Upstream: https://lore.kernel.org/all/20260511135837.3967550-1-shuai.zhang@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

---

Step 1 — PR & Lore Link

PR changes one file: drivers/bluetooth/hci_qca.c. Lore link found:
https://lore.kernel.org/all/20260511135837.3967550-1-shuai.zhang@oss.qualcomm.com/

The message-ID timestamp (20260511135837 UTC) matches the patch Date: header (Mon, 11 May 2026 21:58:37 +0800 = 13:58:37 UTC). Single-patch posting (suffix -1-). ✅

---

Step 2 — Upstream Lore Fetch

Network access is restricted in this environment; b4 is not installed and curl cannot reach lore.kernel.org. The lore patch could not be fetched for direct diff comparison. All analysis below is based on the pr.patch content and internal consistency checks.

---

Step 3 — Upstream Patch Status

Cannot query lore.kernel.org directly. However, the commit message contains:

• Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> — Bartosz is a recognised hci_qca/Bluetooth maintainer; an Acked-by from a subsystem maintainer is a strong acceptance signal.
• Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>

Community verdict: ⏳ Decision Pending (inferred) — The FROMLIST: prefix indicates the patch has been posted but not yet merged into Linus's tree at the time of PR submission. The Acked-by from the subsystem maintainer suggests it is on a positive trajectory, but merge cannot be confirmed without network access.

---

Step 4 — PR Diff

Single commit, single file, 10 hunks, 16 additions / 17 deletions in drivers/bluetooth/hci_qca.c.

---

Step 5 — Normalisation

Lore patch unavailable for comparison. Internal consistency of the PR diff was verified manually (see Step 7).

---

Step 6 — Commit Message Analysis

Subject line (⚠️ WARNING — inverted wording):
The subject reads:

FROMLIST: Bluetooth: hci_qca: Convert timeout from jiffies to ms

However, the patch body states:

"the timeout value must be converted from ms to jiffies when configuring the timer"

And the diff confirms macros are renamed from _MS (millisecond values) to jiffies values (embedding msecs_to_jiffies()). The subject line has the conversion direction backwards. The correct subject should be:

FROMLIST: Bluetooth: hci_qca: Convert timeout from ms to jiffies

Body: Rationale is well-preserved and accurate — explains the bug (8 s intended, ~33 s actual), the fix approach (embed msecs_to_jiffies() in macros), and which macros are intentionally left unchanged (IBS_WAKE_RETRANS_TIMEOUT_MS, IBS_HOST_TX_IDLE_TIMEOUT_MS). ✅

Fixes tag: Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") — properly formatted. ✅

Authorship (FROMLIST: rules): From: = Shuai Zhang <shuai.zhang@oss.qualcomm.com> and Signed-off-by: = same person. For FROMLIST:, the submitter may be the same as the lore author; the lore author's Signed-off-by: is present. ✅

Dependency note: Wake timer depends on commit c347ca17d62a — this is an informal prose note, not a structured Depends-on: tag. The dependency is documented but not in a machine-readable form. ⚠️ Minor.

Backport note: Not applicable (this is FROMLIST:, not BACKPORT:). N/A

Co-developed-by: Not present. ✅

---

Step 7 — Diff Content (Internal Consistency)

Since the lore patch is unavailable, the diff is assessed for internal correctness and self-consistency.

Hunk 1 — Macro redefinitions (@@ -48,13 +48,12 @@):
All five macros correctly embed msecs_to_jiffies() and drop the _MS suffix. IBS_DISABLE_SSR_TIMEOUT is correctly redefined as (MEMDUMP_TIMEOUT + FW_DOWNLOAD_TIMEOUT) — both of which now yield jiffies, so the sum is valid. The ordering of FW_DOWNLOAD_TIMEOUT and IBS_DISABLE_SSR_TIMEOUT is corrected (previously IBS_DISABLE_SSR_TIMEOUT_MS was defined before FW_DOWNLOAD_TIMEOUT_MS, which it depended on — a latent forward-reference issue now resolved). ✅

Hunks 2–6 — Call-site updates (remove msecs_to_jiffies() wrappers):
All call sites that previously wrapped the _MS macros with msecs_to_jiffies() are updated to use the new jiffies-valued macros directly. Consistent and correct. ✅

Hunk 7 — wait_timeout type change (u32 → unsigned long):
wait_timeout is changed from u32 to unsigned long to correctly hold a jiffies value (jiffies are unsigned long on all architectures). This is a necessary and correct companion change. ✅

Hunk 8 — qca_suspend assignment:
wait_timeout is now assigned IBS_DISABLE_SSR_TIMEOUT or FW_DOWNLOAD_TIMEOUT (both jiffies), and the subsequent msecs_to_jiffies(wait_timeout) call is removed. Semantically correct. ✅

---

Step 8 — File Paths and Symbols

Single file drivers/bluetooth/hci_qca.c — path matches the expected upstream location. All renamed macros (MEMDUMP_TIMEOUT, FW_DOWNLOAD_TIMEOUT, IBS_DISABLE_SSR_TIMEOUT, CMD_TRANS_TIMEOUT, IBS_BTSOC_TX_IDLE_TIMEOUT) are consistently applied across all 10 hunks. ✅

---

Step 9 — Dependency Completeness

The commit message notes: "Wake timer depends on commit c347ca17d62a". This dependency is not formally tagged (no Depends-on: trailer). The referenced commit is not included in this PR. If c347ca17d62a is not already present in the target branch, this patch may not apply cleanly or may introduce a regression in the wake timer path. ⚠️

---

Step 10 — qcom-next Presence

No git binary available and network is restricted; clone of https://github.com/qualcomm-linux/kernel could not be attempted.

⏭️ Skipped — Could not fetch qcom-next; verify manually.

---

Commit Message

Check	Status	Note
Subject matches upstream	⚠️	Subject says "from jiffies to ms" but patch converts "from ms to jiffies" — direction is inverted
Body preserves rationale	✅	Bug description, fix approach, and intentional exclusions all documented
Fixes tag present/correct	✅	Fixes: d841502c79e3 (...) properly formatted
Authorship preserved	✅	FROMLIST: — From: = lore author; lore author's Signed-off-by: present
Backport note	N/A	Not a backport
Co-developed-by misuse	✅	Not present
Dependency documented	⚠️	c347ca17d62a noted in prose only; no formal Depends-on: tag

Diff

File	Status	Notes
drivers/bluetooth/hci_qca.c	✅	10 hunks internally consistent; macro renames, call-site cleanup, and u32→unsigned long type fix all correct

Upstream Patch Status

Commit	Community Verdict
Bluetooth: hci_qca: Convert timeout from ms to jiffies	⏳ Decision Pending — FROMLIST: with Acked-by: from subsystem maintainer (Bartosz Golaszewski); merge status unconfirmable without network access

Dependency Check

• ⚠️ Dependency on commit c347ca17d62a (wake timer) noted informally in commit body — not a formal Depends-on: tag; verify this commit is present in the target branch before merging.
• ✅ No missing header/helper changes within the single-file diff.

qcom-next Presence

Commit	Status
Bluetooth: hci_qca: Convert timeout from ms to jiffies	⏭️ Skipped — no git binary and network restricted; verify manually

Issues

1. Subject line direction inverted (⚠️ WARNING): The subject reads "Convert timeout from jiffies to ms" but the patch body and diff both confirm the conversion is from ms to jiffies (macros embed msecs_to_jiffies(), dropping the _MS suffix). The subject should read: FROMLIST: Bluetooth: hci_qca: Convert timeout from ms to jiffies. This is likely a copy-paste or wording error in the subject.
2. Informal dependency note (⚠️ minor): Wake timer depends on commit c347ca17d62a is written as free-form prose. A structured Depends-on: <sha> trailer would be more machine-readable and easier to track.

Recommendation

The diff content is internally correct and the fix is sound. The only actionable issue before merging is the inverted subject line — it should be amended to FROMLIST: Bluetooth: hci_qca: Convert timeout from ms to jiffies. Optionally, convert the dependency note to a formal Depends-on: trailer and confirm commit c347ca17d62a is present in the target branch. Once the subject is corrected, the patch is ready to merge.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260511135837.3967550-1-shuai.zhang@oss.qualcomm.com/
2. Lore link matches PR commits: Cannot confirm (network restricted; lore patch not fetchable) — diff is internally self-consistent and the message-ID metadata matches the patch author/date
3. Upstream patch status: ⏳ Decision Pending — FROMLIST: with Acked-by: from hci_qca maintainer Bartosz Golaszewski; likely on track for merge but not yet confirmed
4. PR present in qcom-next: ⏭️ Skipped — verify manually

[knaveen-qc]

PR #578 — checker-log-analyzer

PR: #578
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/26071699588

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 warning: WARNING: Unknown commit id 'c347ca17d62a' in commit body
dt-binding-check	⏭️	No changes in Documentation/devicetree/bindings
dtb-check	⏭️	No changes in Devicetree
sparse-check	✅	hci_qca.c checked, no sparse warnings; pvr_rogue_fwif_check.h errors are pre-existing tree issues unrelated to this PR
check-uapi-headers	✅	No UAPI header changes
check-patch-compliance	✅	FROMLIST: prefix + Link: present; compliance script passed
tag-check	✅	Commit subject starts with FROMLIST:
qcom-next-check	N/A	PR targets qcom-6.18.y, not qcom-next

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: FROMLIST: Bluetooth: hci_qca: Convert timeout from jiffies to ms (#578)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/26071699588

Target branch: qcom-6.18.y (not qcom-next / qcom-next-staging → tag-check applies)

Checker	Result	Summary
checkpatch	❌	1 warning: WARNING: Unknown commit id 'c347ca17d62a' in commit body
dt-binding-check	⏭️	No changes in Documentation/devicetree/bindings
dtb-check	⏭️	No changes in Devicetree
sparse-check	✅	hci_qca.c checked, no sparse warnings; pvr_rogue_fwif_check.h errors are pre-existing tree issues unrelated to this PR
check-uapi-headers	✅	No UAPI header changes
check-patch-compliance	✅	FROMLIST: prefix + Link: present; compliance script passed
tag-check	✅	Commit subject starts with FROMLIST:
qcom-next-check	N/A	PR targets qcom-6.18.y, not qcom-next

---

❌ checkpatch

Root cause: checkpatch flagged a WARNING: Unknown commit id 'c347ca17d62a' because the commit body contains a bare SHA reference (Wake timer depends on commit c347ca17d62a) that checkpatch cannot resolve in the CI checkout.

Failure details:

WARNING: Unknown commit id 'c347ca17d62a', maybe rebased or not pulled?
#22:
Wake timer depends on commit c347ca17d62a

88e0d7bdee81e6c02d675d4658a22d2d7fc35246 total: 0 errors, 1 warnings, 0 checks, 101 lines checked

Commit 88e0d7bdee81 ("FROMLIST: Bluetooth: hci_qca: Convert timeout from jiffies to ms") has style problems, please review.

Root cause detail: The commit message body contains the line:

Wake timer depends on commit c347ca17d62a

checkpatch treats bare 12-hex-digit tokens in commit bodies as SHA references and warns when they cannot be resolved. The SHA c347ca17d62a is not present in the shallow CI checkout of qcom-6.18.y.

Fix: Replace the bare SHA with a full Link: or descriptive reference that checkpatch won't try to resolve as a local commit. Options:

1. Preferred — expand to a lore URL or full 40-char SHA with a Link: tag:

   Wake timer depends on:
   Link: https://lore.kernel.org/all/<message-id-of-c347ca17d62a>/
   

2. Minimal — quote the SHA so checkpatch doesn't treat it as a bare commit reference, e.g. wrap it in backticks or add context so it isn't a standalone 12-hex token on the line.

Then amend the commit:

git rebase -i <base_sha>   # mark commit as 'edit'
# edit the commit message
git commit --amend
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --summary-file --ignore FILE_PATH_CHANGES --git 6964936c9bfc3337aa8ba8a0fb25021d06e5ce04..5e046a8bb78c370d341ab3eb293f35ad528e5cb6

---

Verdict

1 blocker to fix before merge: amend the commit message to remove or properly reference the bare SHA c347ca17d62a that triggers the checkpatch Unknown commit id warning. All other checkers pass or were correctly skipped.

[qcomlnxci]

Test jobs on 88e0d7b

• Job 101900 on lemans-evk
• Job 101901 on monaco-evk
• Job 101896 on qcs615-ride
• Job 101899 on qcs6490-rb3gen2
• Job 101902 on qcs8300-ride
• Job 101897 on qcs9100-ride-r3
• Job 101898 on x1e80100-crd

[qcomlnxci]

Test Matrix

Test Case	lemans-evk	monaco-evk	qcs615-ride	qcs6490-rb3gen2	qcs8300-ride	qcs9100-ride-r3	x1e80100-crd
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	⚠️ skip	◻️
Ethernet	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
OpenCV	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	❌ Fail	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️
gpdsp_remoteproc	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	✅ Pass	❌ Fail	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
smmu	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

[knaveen-qc]

LAVA Failed Case Triage Summary

PR: #578

Job 101896 | SoC qcs615-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101896

Failed test cases in LAVA job 101896 (SoC: qcs615-ride).

  Case 1: ** Probe_Failure_Check — Firmware Dependency Failure (`regulatory.db` absent from rootfs)

1. Failed case: ** Probe_Failure_Check — Firmware Dependency Failure (regulatory.db absent from rootfs)
2. Root cause: ** The faux_driver regulatory (cfg80211 subsystem) fails to load regulatory.db with error -2 (ENOENT) at boot time (~8.274s) because the wireless-regdb firmware file is absent from the qcs615-ride LAVA rootfs under /lib/firmware/; the Probe_Failure_Check test script detects this single journal entry and reports FAIL.
3. Possible fix: Install the wireless-regdb package (providing /lib/firmware/regulatory.db) into the qcs615-ride LAVA rootfs build recipe; re-trigger the CI job to confirm Probe_Failure_Check passes with 0 matched lines.
4. Detail analysis attachment: failed_case_job101896_1_detailed.md

  Case 2: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The smmu test script asserts that the Venus video codec sub-devices aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder each have an independent IOMMU group attachment, but on qcs615-ride the Venus driver uses the "non legacy binding" model where only the parent aa00000.video-codec device is attached to IOMMU group 7 — the child sub-devices are not separately enumerated in sysfs, causing two [FAIL] Critical master is missing iommu_group attachment assertions and a final FAIL=2 result.
3. Possible fix: Update the smmu test script to recognise the "non legacy binding" Venus topology on qcs615-ride — either accept that the parent aa00000.video-codec being in an IOMMU group is sufficient for the video codec check, or add a platform-specific allowlist entry for qcs615-ride that skips the video-decoder/video-encoder sub-device IOMMU group check; this PR (hci_qca Bluetooth timer fix) is unrelated and does not require any kernel change.
4. Detail analysis attachment: failed_case_job101896_2_detailed.md

  Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The qcs615-ride board's USB host port (xhci-hcd, bus 1, 1 port) enumerated only the Linux Foundation 2.0 root hub (ID 1d6b:0002) with no external USB peripheral device attached or detected; the test script requires at least one non-hub USB device to pass.
3. Possible fix: Verify that a functional USB peripheral device (e.g. USB storage or HID device) is physically connected to the qcs615-ride board's USB host port before the test runs; if the board has no USB host port wired to an external connector in this LAVA lab setup, mark USBHost as a known infrastructure skip for this board/lab configuration.
4. Detail analysis attachment: failed_case_job101896_3_detailed.md

  Case 4: ** shmbridge — Suppressed (Known Benign)

1. Failed case: ** shmbridge — Suppressed (Known Benign)
2. Root cause: ** The shmbridge test detected qcom_scm-related error strings in the kernel log (repeated qcom,fastrpc DSP errors from 62400000.remoteproc) and failed on that basis; however, per Rule 1 of lava-known-benign-failures.md, shmbridge failures are unconditionally classified as known CI infrastructure noise and do not indicate a kernel regression.
3. Possible fix: No action required — suppress this result as known benign; the failure is not caused by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578 (a Bluetooth hci_qca timer fix) and is unrelated to qcom_scm or shmbridge functionality.
4. Detail analysis attachment: failed_case_job101896_4_detailed.md

  Case 5: ** 0_qcom-next-ci-premerge-tests

1. Failed case: ** 0_qcom-next-ci-premerge-tests
2. Root cause: ** The lava-test-shell timeout of 376 seconds expired while the BT_ON_OFF test was waiting for btpower to confirm hci0 powered-on after an OFF→ON cycle; the WCN6855 firmware re-download (hpbtfw21.tlv + hpnv21.b206 via QCA6698 path) consumed ~2s of the remaining budget and the test script never emitted its final LAVA_SIGNAL_TESTCASE result before LAVA killed the shell. The pervasive qcom,fastrpc 62400000.remoteproc … dsp information is incorrect err: -1 messages are pre-existing benign noise on qcs615-ride (ADSP fastrpc probe-time error) and did not cause the timeout.
3. Possible fix: Increase the lava-test-shell timeout for the qcom-next-ci-premerge test plan on qcs615-ride from 376 s to at least 600 s (10 min) in the LAVA job definition to accommodate the full test suite including BT firmware re-download during power cycling; re-trigger the CI job to confirm.
4. Detail analysis attachment: failed_case_job101896_5_detailed.md

  Case 6: ** lava-test-shell

1. Failed case: ** lava-test-shell
2. Root cause: ** The BT_ON_OFF test on qcs615-ride (WCN6855/QCA6698 via UART) stalled after the BT power-on cycle: firmware download completed successfully (QCA setup on UART is completed at ~435 s kernel time) but the HCI device never transitioned to Powered=yes, causing the btpower script to hang and exhaust the remaining 376 s LAVA test-shell timeout. The PR modifies hci_qca.c timer macros (converting _MS raw-ms values to embedded msecs_to_jiffies() jiffies values), and the IBS_BTSOC_TX_IDLE_TIMEOUT change is the most likely trigger: if any call site that previously consumed a ms value now receives a jiffies value (or the conversion is applied twice), the IBS TX-idle timer fires at the wrong time, stalling the IBS state machine after firmware download and preventing the controller from becoming ready.
3. Possible fix: Audit every call site of IBS_BTSOC_TX_IDLE_TIMEOUT (and the other renamed macros) in hci_qca.c to confirm no double-conversion occurs; if a call site was already wrapping the old _MS value in msecs_to_jiffies(), remove that wrapper now that the macro embeds the conversion — then re-run the BT_ON_OFF test on qcs615-ride to confirm Powered=yes is reached after power-on.
4. Detail analysis attachment: failed_case_job101896_6_detailed.md

  Case 7: ** lava-test-retry

1. Failed case: ** lava-test-retry
2. Root cause: ** The lava-test-shell 376-second timeout expired while the BT_ON_OFF test was mid-execution on qcs615-ride (WCN6855/QCA6698 via hci_qca): the BT power-on cycle had just completed firmware download (QCA setup on UART is completed at kernel time ~435 s) but the test script had not yet emitted its LAVA_SIGNAL_TESTCASE result before LAVA's outer shell timeout fired; the cumulative runtime of all preceding tests left insufficient budget for BT_ON_OFF to finish.
3. Possible fix: Increase the lava-test-shell (and lava-test-retry) timeout in the LAVA job definition from 376 seconds to at least 480 seconds to give the BT_ON_OFF test adequate time to complete its ON/OFF/ON cycle and report results; additionally, investigate whether the PR's shortened CMD_TRANS_TIMEOUT / FW_DOWNLOAD_TIMEOUT (now correctly in jiffies, ~10× shorter than before) is causing the hci_qca driver to take longer to settle after firmware load on WCN6855, contributing to the tight timing.
4. Detail analysis attachment: failed_case_job101896_7_detailed.md

  Case 8: ** job

1. Failed case: ** job
2. Root cause: ** The lava-test-shell timed out after 376 seconds because the BT_ON_OFF test case stalled waiting for the BT power-ON cycle to complete — the test had successfully powered OFF hci0 (QCA6698/wcn6855 on UART) and then issued a power-ON, which triggered hci_qca firmware re-download (qca/QCA6698/hpbtfw21.tlv + hpnv21.b206); the LAVA test-shell timeout (6m16s) expired while the BT stack was still completing setup, leaving no LAVA_SIGNAL_TESTCASE result for BT_ON_OFF and causing LAVA to mark the entire test run as failed.
3. Possible fix: Re-trigger the CI job to determine if this is a transient timing issue; if it recurs, increase the lava-test-shell timeout from 6m16s to at least 10–12 minutes in the LAVA job definition to accommodate the full BT_ON_OFF cycle (OFF + firmware re-download on power-ON) on qcs615-ride, and investigate whether the PR's corrected FW_DOWNLOAD_TIMEOUT (now properly 3 s in jiffies instead of ~33 s) causes the firmware download path to time out prematurely during the power-ON re-init.
4. Detail analysis attachment: failed_case_job101896_8_detailed.md

Job 101897 | SoC qcs9100-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101897

Failed test cases in LAVA job 101897 (SoC: qcs9100-ride).

  Case 1: ** Remoteproc Boot Failure — PAS/SCM init error -22 (EINVAL)

1. Failed case: ** Remoteproc Boot Failure — PAS/SCM init error -22 (EINVAL)
2. Root cause: ** On qcs9100-ride (sa8775p), qcom_scm_pas_init_image() returns -EINVAL (-22) for all five remoteproc instances (cdsp0, cdsp1, gpdsp0, gpdsp1, adsp) because the SCM driver logs qcom_scm firmware:scm: qseecom: untested machine, skipping at boot (log line 1399), indicating the sa8775p machine ID is absent from the qseecom support table, blocking PAS-based firmware authentication for every qcom_q6v5_pas-managed subsystem.
3. Possible fix: Add the sa8775p machine/SoC ID to the qseecom tested-machine list in drivers/firmware/qcom/qcom_scm.c (or ensure the correct non-qseecom SCM call path is used for sa8775p PAS init); this is a pre-existing platform issue unrelated to PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578.
4. Detail analysis attachment: failed_case_job101897_1_detailed.md

  Case 2: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error

1. Failed case: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error
2. Root cause: ** qcom_q6v5_pas returns error -22 (-EINVAL) from qcom_scm_pas_init_image() for qcom/sa8775p/adsp.mbn because qcom_scm qseecom initialization was skipped at boot (qseecom: untested machine, skipping), leaving the PAS authentication SCM service unavailable; ADSP remoteproc4 never transitions from offline to running.
3. Possible fix: Add the sa8775p machine ID to the qseecom tested-machines allowlist in drivers/firmware/qcom/qcom_scm.c so that qcom_scm_pas_init_image() can authenticate DSP firmware images; verify by confirming all DSP subsystems reach running state on next boot. This failure is not introduced by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578 (which only modifies Bluetooth HCI timer macros) — do not block the PR on this result.
4. Detail analysis attachment: failed_case_job101897_2_detailed.md

  Case 3: ** Remoteproc Boot Failure — PAS/SCM EINVAL on firmware initialization

1. Failed case: ** Remoteproc Boot Failure — PAS/SCM EINVAL on firmware initialization
2. Root cause: ** qcom_scm reports qseecom: untested machine, skipping for the sa8775p (qcs9100-ride) SoC, causing qcom_scm_pas_init_image() to return -EINVAL (-22) when qcom_q6v5_pas attempts to initialize the gpdsp0/gpdsp1 firmware images via the PAS/SCM path, leaving both remoteproc instances permanently offline.
3. Possible fix: Add the sa8775p SoC ID to the qseecom tested-machine list in drivers/firmware/qcom/qcom_scm.c (or the relevant qseecom allowlist), so that qcom_scm_pas_init_image() proceeds correctly for this platform; re-run the LAVA job to confirm gpdsp0/gpdsp1 reach running state.
4. Detail analysis attachment: failed_case_job101897_3_detailed.md

  Case 4: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error -22 (EINVAL) on all subsystems

1. Failed case: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error -22 (EINVAL) on all subsystems
2. Root cause: ** All 5 remoteproc subsystems (gpdsp0, gpdsp1, cdsp0, cdsp1, adsp) fail to start on qcs9100-ride because qcom_q6v5_pas returns -EINVAL at the PAS firmware initialization step, caused by the SCM/qseecom driver logging untested machine, skipping — the qcs9100 SoC is not in the qseecom allowlist, so the TrustZone-side PAS authentication path is skipped/rejected, leaving all remoteprocs in offline state.
3. Possible fix: Add qcs9100 to the qseecom machine allowlist in the SCM driver (or ensure the correct qcom_scm firmware/TZ image that supports qcs9100 PAS authentication is flashed); this is a pre-existing platform integration issue unrelated to the PR under test — the PR (hci_qca.c Bluetooth timer fix) does not affect remoteproc and should not be blocked on this failure.
4. Detail analysis attachment: failed_case_job101897_4_detailed.md

  Case 5: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Two pre-existing probe/firmware errors triggered the check: (1) the Aquantia AQR115C PHY at MDIO address 0x08 (stmmac-0:08) fails probe with -EINVAL because the qcs9100-ride-sx DT node for that PHY is missing the required firmware-name property; (2) cfg80211 fails to load regulatory.db with -ENOENT because the CI test rootfs image does not include the regulatory database firmware file — neither failure is introduced by the PR under test.
3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node at MDIO address 0x08 in arch/arm64/boot/dts/qcom/qcs9100-ride.dtsi (or equivalent board DTS), and include regulatory.db in the CI rootfs firmware packaging; neither fix is related to the PR (drivers/bluetooth/hci_qca.c) which should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job101897_5_detailed.md

  Case 6: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The SMMU test fails because two critical DMA masters — aa00000.video-codec (qcom-iris video codec) and interconnect-lpass-ag-noc (LPASS audio interconnect) — are absent from all IOMMU groups at test time; the video-codec device never attached because the qcom-iris driver repeatedly failed firmware download with error -22 (EINVAL) for qcom/vpu/vpu30_p4_s6_16mb.mbn, and the LPASS interconnect node has no IOMMU group attachment on this qcs9100-ride configuration.
3. Possible fix: Ensure qcom/vpu/vpu30_p4_s6_16mb.mbn is present and valid in the LAVA test rootfs for qcs9100-ride (fixing the video-codec IOMMU attachment), and verify the qcs9100-ride DTS includes an iommus property for interconnect-lpass-ag-noc or update the SMMU test's critical-master list to exclude devices not expected to be IOMMU-mapped on this platform; this failure is pre-existing and unrelated to PR578 (which only modifies drivers/bluetooth/hci_qca.c).
4. Detail analysis attachment: failed_case_job101897_6_detailed.md

  Case 7: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The USBHost test failed because no physical USB peripheral device is connected to the qcs9100-ride board's USB host port in the LAVA lab environment; lsusb enumerated only three Linux Foundation root hub entries (1d6b:0002/1d6b:0003) with no functional device attached, causing the test script to report "Only USB hubs detected, no functional USB devices."
3. Possible fix: Attach a physical USB peripheral (e.g., USB storage or HID device) to the qcs9100-ride board's USB host port in the LAVA lab rig, or mark USBHost as a known infrastructure-dependent test and suppress it when no USB device is wired to the board.
4. Detail analysis attachment: failed_case_job101897_7_detailed.md

  Case 8: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)

1. Failed case: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
2. Root cause: ** The shmbridge test script performs a grep over the current-boot kernel log for any qcom_scm-related string and incorrectly classifies the benign informational message qcom_scm firmware:scm: qseecom: untested machine, skipping as an error; this is a known false-positive in the CI environment on qcs9100-ride and is unrelated to the PR under test.
3. Possible fix: No action required — suppress this result per Rule 1 of lava-known-benign-failures.md; the shmbridge test is known CI infrastructure noise and does not indicate a kernel regression introduced by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578.
4. Detail analysis attachment: failed_case_job101897_8_detailed.md

Job 101898 | SoC x1e80100

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101898

Failed test cases in LAVA job 101898 (SoC: x1e80100).

  Case 1: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure — the LAVA dispatcher timed out downloading the 43 MB kernel Image artifact from S3 (qli-prd-kernel-gh-artifacts.s3.us-west-2.amazonaws.com) at step 1.3.1, with only 40% (17 MB) transferred in 300 s (~0.057 MB/s) before the hard timeout fired: "http-download timed out after 300 seconds".
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 300 s to 600 s and the download-retry block timeout from ~10 min to 15 min in the LAVA job definition for the x1e80100 Image download step.
4. Detail analysis attachment: failed_case_job101898_1_detailed.md

  Case 2: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure — the http-download action at stage 1.3.1 timed out after exactly 300 seconds while downloading the 43 MB kernel Image artifact from S3 (qualcomm-linux/kernel-config/26083305673-1/Image); the transfer stalled at ~0.06 MB/s (only 17 MB of 43 MB transferred in 300 s), exhausting the single configured retry attempt and aborting the job before the x1e80100 CRD board was ever powered on.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 300 s to 600 s and the download-retry block timeout from ~10 min to 15 min in the LAVA job definition to accommodate S3 bandwidth variability on the worker network path.
4. Detail analysis attachment: failed_case_job101898_2_detailed.md

  Case 3: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. During stage 1.3.1 http-download, the 43 MB kernel Image artifact download from S3 (qualcomm-linux/kernel-config/26083305673-1/Image) stalled at ~40 % (17 MB) and hit the hard 300 s per-attempt timeout; with only 1 retry configured, download-retry failed immediately, propagating the InfrastructureError — not caused by the PR patch.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 300 s to 600 s and the download-retry block timeout from the current ~10 min to 15 min in the LAVA job definition to accommodate the observed ~0.06 MB/s degraded S3 throughput for the 43 MB Image artifact.
4. Detail analysis attachment: failed_case_job101898_3_detailed.md

  Case 4: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** The LAVA dispatcher's http-download of the 43 MB kernel Image artifact from S3 (qualcomm-linux/kernel-config/26083305673-1/Image) stalled at ~57 KB/s and hit the hard 300-second timeout at step 1.3.1, triggering InfrastructureError: http-download timed out after 300 seconds; the kernel was never delivered to the x1e80100-crd board.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 300 s to 600 s and the download-retry block timeout from ~6 m 13 s to 15 min in the LAVA job definition to accommodate degraded S3 egress bandwidth.
4. Detail analysis attachment: failed_case_job101898_4_detailed.md

Job 101899 | SoC qcs6490-rb3gen2

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101899

Failed test cases in LAVA job 101899 (SoC: qcs6490-rb3gen2).

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** The 33c0000.pinctrl (TLMM pinctrl controller at 0x33c0000 on QCS6490/SC7280) remained stuck in deferred probe with unknown reason throughout boot, blocking the entire audio subsystem dependency chain (3240000.codec → 3250000.soundwire → sound/snd-sc8280xp, and 3370000.codec); additionally, xhci-pci-renesas hard-failed with -ENOENT due to missing renesas_usb_fw.mem firmware in the rootfs — both failures are pre-existing and unrelated to the PR's Bluetooth timer fix in hci_qca.c.
3. Possible fix: Investigate why 33c0000.pinctrl never resolves its deferred probe (check for a missing or broken pinctrl provider dependency in the DT or a regression in the TLMM driver for SC7280/QCS6490), and add renesas_usb_fw.mem to the LAVA rootfs image (or suppress xhci-pci-renesas probe failure if the Renesas USB host is not present/used on rb3gen2); this PR should not be blocked on these pre-existing failures.
4. Detail analysis attachment: failed_case_job101899_1_detailed.md

  Case 2: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The Renesas xHCI PCIe USB host controller (pci 0001:04:00.0, ID 1912:0014) failed to probe with -ENOENT because firmware file renesas_usb_fw.mem is absent from the rootfs, leaving no functional USB host controller and causing the USBHost test to find zero enumerated devices.
3. Possible fix: Add the Renesas xHCI firmware file renesas_usb_fw.mem to the rootfs image (under /lib/firmware/) used for qcs6490-rb3gen2 LAVA jobs, or install the firmware-misc-nonfree / linux-firmware package that provides it.
4. Detail analysis attachment: failed_case_job101899_2_detailed.md

  Case 3: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)

1. Failed case: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
2. Root cause: ** The shmbridge test script's keyword scan for qcom_scm-related errors in the boot log matched the benign informational message qcom_scm firmware:scm: qseecom: untested machine, skipping (emitted at boot on qcs6490-rb3gen2 because qseecom is not validated for this SoC variant); this is a known CI test script false-positive, not a kernel regression, and is unconditionally suppressed per Rule 1 of the known-benign-failures policy.
3. Possible fix: No action required — suppress this result per Rule 1; the shmbridge failure is known CI infrastructure noise on qcs6490-rb3gen2 and does not indicate any kernel regression introduced by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578.
4. Detail analysis attachment: failed_case_job101899_3_detailed.md

  Case 4: ** `0_qcom-next-ci-premerge-tests`

1. Failed case: ** 0_qcom-next-ci-premerge-tests
2. Root cause: ** The LAVA test runner completed all suites but three sub-tests reported FAIL — Probe_Failure_Check (deferred probe on 33c0000.pinctrl / audio codec chain and firmware load errors for regulatory.db and xhci-pci-renesas), USBHost (no USB devices enumerated), and shmbridge (false-positive: qcom_scm.download_mode=1 in the kernel command line matched the test's qcom_scm-error grep pattern) — causing LAVA to mark the overall test definition as failed via "Marking unfinished test run as failed" even though the test runner itself exited cleanly; none of these failures are introduced by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578 (which only touches drivers/bluetooth/hci_qca.c timer macros).
3. Possible fix: Investigate the 33c0000.pinctrl deferred probe chain (audio codec/soundwire dependency loop on qcs6490-rb3gen2) as a pre-existing kernel regression unrelated to this PR; fix the shmbridge test's grep pattern to exclude the qcom_scm.download_mode kernel cmdline match (false positive); and verify USB host hardware connectivity on the test board. Re-trigger the CI job to confirm the BT-related changes in PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578 do not affect these failures.
4. Detail analysis attachment: failed_case_job101899_4_detailed.md

Job 101900 | SoC lemans-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101900

Failed test cases in LAVA job 101900 (SoC: lemans-evk).

  Case 1: ** Probe_Failure_Check — Firmware Dependency False Positive (non-fatal early-boot ENOENT)

1. Failed case: ** Probe_Failure_Check — Firmware Dependency False Positive (non-fatal early-boot ENOENT)
2. Root cause: ** The Probe_Failure_Check dmesg scanner flags three pre-existing, non-fatal early-boot firmware load failures on the Lemans EVK (IQ-9075): regulatory.db and QCA BT firmware files qca/wcnhpbtfw21.tlv / qca/hpbtfw21.tlv all return ENOENT at T+7s because the files are absent from /lib/firmware at the time of the synchronous kernel firmware request, but both WiFi and Bluetooth subsystems recover and function correctly (BT_ON_OFF PASS, BT_SCAN PASS, WiFi_OnOff PASS); the test script does not suppress known-benign firmware misses when functional tests pass.
3. Possible fix: Add suppression rules to the Probe_Failure_Check test script for regulatory.db, qca/wcnhpbtfw21.tlv, and qca/hpbtfw21.tlv ENOENT patterns on Lemans EVK when the corresponding functional tests (WiFi_OnOff, BT_ON_OFF) pass; and/or ensure these firmware files are present in the rootfs /lib/firmware at boot time to eliminate the dmesg messages entirely.
4. Detail analysis attachment: failed_case_job101900_1_detailed.md

  Case 2: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The SMMU test script detected that aa00000.video-codec (Video) and interconnect-lpass-ag-noc (Audio) are absent from /sys/kernel/iommu_groups on lemans-evk; no SMMU hardware fault occurred — the kernel log explicitly passed the SMMU error scan, and all three SMMUv2 instances probed cleanly.
3. Possible fix: Update the SMMU test script's critical-master list to remove interconnect-lpass-ag-noc (an interconnect provider, not a DMA master — it will never have an IOMMU group) and replace aa00000.video-codec with its actual sub-devices iris_non_pixel.0 and iris_pixel.0 (which are correctly attached to IOMMU groups 20–21 on lemans-evk); alternatively, add an iommus DT property to the aa00000.video-codec node if the hardware requires it.
4. Detail analysis attachment: failed_case_job101900_2_detailed.md

  Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The USBHost test on lemans-evk (IQ-9075-EVK) failed because the test harness detected only USB hubs (Genesys Logic 05e3:0610 USB 2.0 hub on Bus 001 and 05e3:0625 USB 3.1 hub on Bus 002) and no functional USB peripheral device was physically connected to the board's USB host port at test time; the xhci-hcd controller and hub chain probed correctly, confirming this is a lab infrastructure gap, not a kernel regression.
3. Possible fix: Attach a functional USB peripheral device (e.g. USB mass storage or USB HID device) to the lemans-evk USB host port in the LAVA lab setup before re-triggering the job; if the board has no free host port, update the USBHost test script to accept a hub-only topology as a valid pass condition when no peripheral is expected in the CI rig.
4. Detail analysis attachment: failed_case_job101900_3_detailed.md

  Case 4: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)

1. Failed case: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
2. Root cause: ** The shmbridge test unconditionally fails in this CI environment due to known infrastructure noise; the test script flagged qcom_scm firmware:scm: qseecom: untested machine, skipping as a "qcom_scm-related error" in the kernel log, but this is a benign informational message emitted on every lemans-evk boot and is not a regression introduced by the PR.
3. Possible fix: No fix required — suppress this result per Rule 1 of lava-known-benign-failures.md; the shmbridge test result must not be used as a gate for PR578.
4. Detail analysis attachment: failed_case_job101900_4_detailed.md

  Case 5: ** WiFi_Firmware_Driver — Suppressed (Known Benign: WiFi Firmware False Positive — WiFi ON/OFF Passed)

1. Failed case: ** WiFi_Firmware_Driver — Suppressed (Known Benign: WiFi Firmware False Positive — WiFi ON/OFF Passed)
2. Root cause: ** The WiFi_Firmware_Driver test probed ath12k module load state before the driver had fully initialised on the lemans-evk board; however, the functional WiFi_OnOff test passed (interface wlp1s0 via ath11k/ath11k_pci toggled successfully), confirming WiFi firmware loaded correctly at runtime — this is a known false positive per suppression Rule 2.
3. Possible fix: No fix required; suppress this result as a known benign false positive — the WiFi stack is functional as confirmed by WiFi_OnOff PASS, and this failure is not introduced by the PR (which only modifies hci_qca.c Bluetooth timer macros).
4. Detail analysis attachment: failed_case_job101900_5_detailed.md

  Case 6: ** `0_qcom-next-ci-premerge-tests` — Test Suite Failure (sub-tests reported FAIL within a completed run)

1. Failed case: ** 0_qcom-next-ci-premerge-tests — Test Suite Failure (sub-tests reported FAIL within a completed run)
2. Root cause: ** The lava-test-shell completed normally (duration 00:07:24, <LAVA_TEST_RUNNER EXIT> received) but LAVA marked the overall test definition 0_qcom-next-ci-premerge-tests as failed because result_parse.sh found unresolved .res files and multiple sub-tests had already signalled FAIL: smmu (missing IOMMU group for aa00000.video-codec and interconnect-lpass-ag-noc), Probe_Failure_Check (BT firmware qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv load errors), shmbridge (stale qcom_scm errors in prior-boot kernel log), USBHost (only USB hubs detected), and WiFi_Firmware_Driver — none of which are caused by the PR's hci_qca.c timer-unit fix.
3. Possible fix: These are pre-existing platform/infra failures on the lemans-evk board unrelated to PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578; re-trigger the CI job to confirm reproducibility, and separately investigate the SMMU DT binding for aa00000.video-codec and interconnect-lpass-ag-noc on lemans-evk, the missing BT firmware blobs (qca/wcnhpbtfw21.tlv/qca/hpbtfw21.tlv) in the rootfs image, and the stale qcom_scm journal entry that triggers the shmbridge false-positive.
4. Detail analysis attachment: failed_case_job101900_6_detailed.md

Job 101901 | SoC monaco-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101901

Failed test cases in LAVA job 101901 (SoC: monaco-evk).

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** The Probe_Failure_Check test flagged two pre-existing, non-fatal Bluetooth firmware load errors (Direct firmware load for qca/wcnhpbtfw21.tlv failed with error -2 and qca/hpbtfw21.tlv failed with error -2) that appear in dmesg because the LAVA rootfs for monaco-evk does not include these QCA BT NV patch files; BT_ON_OFF passes, confirming the controller is fully functional without them.
3. Possible fix: Add qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv to the monaco-evk LAVA rootfs/firmware overlay, or update the Probe_Failure_Check test script to suppress known-benign BT firmware load errors (matching qca/.*btfw.*\.tlv) when the corresponding BT_ON_OFF functional test passes — mirroring the existing suppression logic in lava-known-benign-failures.md Rule 3.
4. Detail analysis attachment: failed_case_job101901_1_detailed.md

  Case 2: ** WiFi_OnOff

1. Failed case: ** WiFi_OnOff
2. Root cause: ** The firmware ramdisk deployed for the monaco-evk board (initramfs-firmware-qcs8300-ride-image-qcom-armv8a.cpio.gz) does not contain ath11k WiFi firmware blobs for the WCN6855 chip; without them ath11k_pci cannot register a PHY and no wlan interface appears.
3. Possible fix: Replace or supplement the firmware ramdisk in the LAVA job definition with one that includes the monaco-specific ath11k WCN6855 firmware blobs (e.g., ath11k/WCN6855/hw2.0/board-2.bin and firmware-2.bin), or add a monaco-evk firmware CPIO overlay alongside the existing qcs8300 ramdisk.
4. Detail analysis attachment: failed_case_job101901_2_detailed.md

  Case 3: ** `0_qcom-next-ci-premerge-tests`

1. Failed case: ** 0_qcom-next-ci-premerge-tests
2. Root cause: ** The overall test case was marked failed by LAVA because the test runner exited without sending LAVA_SIGNAL_ENDRUN (triggering "Marking unfinished test run as failed"), driven by two genuine sub-test failures: Probe_Failure_Check (BT firmware files qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv absent from the test ramdisk, error -2) and WiFi_OnOff (no WiFi interface appeared after 30 s — ath11k loaded but WiFi firmware missing from /lib/firmware on the monaco-evk test image); neither failure is introduced by PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578.
3. Possible fix: Ensure the monaco-evk test firmware ramdisk (initramfs-firmware-qcs8300-ride-image-qcom-armv8a.cpio.gz) includes the QCA BT patch firmware (qca/wcnhpbtfw21.tlv / qca/hpbtfw21.tlv) and the ath11k WiFi firmware for wcn6855; re-trigger the CI job to confirm PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578 is clean.
4. Detail analysis attachment: failed_case_job101901_3_detailed.md

Job 101902 | SoC qcs8300-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/101902

Failed test cases in LAVA job 101902 (SoC: qcs8300-ride).

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Two pre-existing driver probe failures on qcs8300-ride triggered the test: (1) faux_driver regulatory fails to load regulatory.db (error -2, ENOENT — file absent from rootfs firmware path), and (2) Aquantia AQR115C PHY at stmmac-0:08 fails to probe with error -22 (EINVAL) because of_property_read_string() for the firmware-name DT property returns -EINVAL, indicating the property is either absent or malformed in the qcs8300-ride DTS. Neither failure is related to the PR under test (drivers/bluetooth/hci_qca.c).
3. Possible fix: (1) Add regulatory.db to the LAVA test rootfs firmware overlay (/lib/firmware/) for qcs8300-ride, or suppress this known-missing firmware warning in the Probe_Failure_Check test script's filter list; (2) add or correct the firmware-name property in the qcs8300-ride DTS node for the Aquantia AQR115C PHY (stmmac-0:08), or add both signatures to the Probe_Failure_Check known-benign suppression list if they are confirmed pre-existing on this board.
4. Detail analysis attachment: failed_case_job101902_1_detailed.md

  Case 2: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The xHCI host controller on qcs8300-ride probed successfully and the USB 2.0 root hub was detected with 1 port, but no physical USB peripheral device was connected to the board's USB host port in the LAVA lab — lsusb returned only Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (the root hub itself), causing the test to fail with "Only USB hubs detected, no functional USB devices."
3. Possible fix: Connect a USB peripheral device (e.g., USB flash drive or USB-to-serial adapter) to the qcs8300-ride board's USB host port in the LAVA lab; this is a lab infrastructure gap unrelated to PR Bluetooth: hci_qca: Convert timeout from jiffies to ms #578.
4. Detail analysis attachment: failed_case_job101902_2_detailed.md

  Case 3: ** shmbridge

1. Failed case: ** shmbridge
2. Root cause: ** The shmbridge test is suppressed as known CI infrastructure noise (Rule 1 — unconditional); the test script incorrectly flagged a FAIL because it detected the kernel command line string qcom_scm.download_mode=1 as a "qcom_scm-related error" in the current-boot kernel log, even though qcom_scm probed successfully and no actual SCM error occurred.
3. Possible fix: No action required — suppress this result as a known benign false positive; the shmbridge test's log-scanning heuristic produces false positives on qcs8300-ride when qcom_scm.download_mode=1 is present in the kernel command line, and this failure is unrelated to the PR under test (Bluetooth hci_qca timer fix).
4. Detail analysis attachment: failed_case_job101902_3_detailed.md

  Case 4: ** `0_qcom-next-ci-premerge-tests`

1. Failed case: ** 0_qcom-next-ci-premerge-tests
2. Root cause: ** The LAVA test runner (lava-test-runner) exited after completing all test suites and emitting <LAVA_TEST_RUNNER EXIT>, but never sent a LAVA_SIGNAL_ENDRUN signal; LAVA dispatcher therefore marked the test definition UUID 101902_1.1.3.1 as an unfinished run and set its result to fail. The individual sub-test failures that contributed to the non-zero exit are pre-existing, PR-unrelated false positives: shmbridge falsely matched the kernel cmdline string qcom_scm.download_mode=1 as a "qcom_scm error"; Probe_Failure_Check flagged regulatory.db missing and AQR115C PHY probe failure (-EINVAL due to 2500base-x advertisement mismatch), both known platform-level issues on qcs8300-ride unrelated to the PR's Bluetooth hci_qca timer fix.
3. Possible fix: Re-trigger the CI job; the PR patch (drivers/bluetooth/hci_qca.c timer jiffies conversion) is unrelated to any of the observed failures. Additionally, update the shmbridge test script to exclude kernel cmdline matches when scanning for qcom_scm errors, and add regulatory.db and AQR115C PHY probe failures to the Probe_Failure_Check allowlist for qcs8300-ride.
4. Detail analysis attachment: failed_case_job101902_4_detailed.md