[shuaz-shuai]

Firmware download on the WCN3988 sometimes fails and is retried:

Bluetooth: hci0: QCA TLV response size mismatch
Bluetooth: hci0: QCA Failed to request file: qca/apbtfw11.tlv (-84)

The vendor event answering the baudrate change command can arrive late and is then taken as the response of the last firmware segment, which waits for any vendor event. Its length is 2 instead of the expected 3:

< HCI Command: Vendor (0x3f|0x0000) plen 220 (last segment)

HCI Event: Vendor (0xff) plen 2
92 01

Drop and wait for this event on the WCN3988.

Link: https://lore.kernel.org/all/20261104095026.3414666-1-shuai.zhang@oss.qualcomm.com/
CRs-Fixed: 4730935

🤖 Generated with Claude Code

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4730935 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4730935

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[qlijarvis]

PR #1409 — validate-patch

PR: #1409

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20261104095026.3414666-1-shuai.zhang@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — diff content is faithful to lore; commit message body identical; extra Co-Authored-By: trailer in PR should be removed
3. Upstream patch status: ⏳ In review — Reviewed-by: Bartosz Golaszewski on 2026-11-04; all CI tests passed; no merge/applied signal yet; no NAK
4. PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1409 - FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event
Upstream commit: https://lore.kernel.org/all/20261104095026.3414666-1-shuai.zhang@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	✅	FROMLIST: prefix correctly added
Body preserves rationale	✅	Identical to lore patch
Fixes tag present/correct	N/A	No Fixes tag in upstream or PR
Authorship preserved	✅	From: matches lore author (Shuai Zhang)
Backport note (if applicable)	N/A	FROMLIST: commit, not a backport

Diff

File	Status	Notes
drivers/bluetooth/hci_qca.c	✅	Code changes identical; line number delta (1521→1523, 1556→1559) is context-only

Issues

• ⚠️ Extra trailer in PR: Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> is present in the PR commit but NOT in the upstream lore patch. This trailer should be removed before merging to maintain fidelity with the upstream submission.

Verdict

The patch faithfully represents the lore upstream in terms of code changes and commit message body. However, the PR contains an extra Co-Authored-By: trailer that is not present in the upstream submission. This should be removed to maintain exact correspondence with the lore patch. The FROMLIST: prefix and Link: tag are correctly added per Qualcomm kernel conventions.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20261104095026.3414666-1-shuai.zhang@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — diff content is faithful to lore; commit message body identical; extra Co-Authored-By: trailer in PR should be removed
3. Upstream patch status: ⏳ In review — Reviewed-by: Bartosz Golaszewski on 2026-11-04; all CI tests passed; no merge/applied signal yet; no NAK
4. PR present in qcom-next/topics: Yes — per integration_presence_report.md: "present - all checked added lines are present in qcom-next"

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 17bbb4b37bbc4fc5827b4667445a0c43967c0f48
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present

Final Status

overall_status: PASS
present_commits: 1/1
partial_commits: 0/1
missing_commits: 0/1
topics_checked_for_commits: 0/1
final_summary: PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

[qlijarvis]

PR #1409 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 warnings: non-standard signature format
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1409 - FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/41990346217

Checker	Result	Summary
checkpatch	❌	2 warnings: non-standard signature format
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMLIST: prefix

❌ checkpatch

Root cause: Non-standard signature trailer format in commit message.

Failure details:

WARNING: Non-standard signature: Co-Authored-By:
#24: 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

WARNING: 'Co-authored-by:' is the preferred signature form
#24: 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

041f72aff8cca35db8c98fcfd72551f8821f9c79 total: 0 errors, 2 warnings, 0 checks, 14 lines checked

The commit uses Co-Authored-By: (with capital 'A' and 'B') instead of the kernel-preferred Co-authored-by: (lowercase 'a' and 'b').

Fix:

git rebase -i e5518b697e88   # mark commit as 'edit'
# Edit the commit message to change:
#   Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
# to:
#   Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
git commit --amend
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git e5518b697e88..041f72aff8cc

Verdict

Fix 1 minor issue before merge: Change Co-Authored-By: to Co-authored-by: (lowercase 'a' and 'b') in the commit message trailer. This is a trivial formatting fix that takes seconds to correct with git commit --amend.

All other checkers passed or were correctly skipped (no relevant file changes). The code change itself is clean and the commit follows proper upstream contribution practices with FROMLIST: prefix and lore.kernel.org link.

[Shiraz Hashim (shashim-quic)]

Changed directory to /opt/actions-runner/_work/kernel-config/kernel-config/kernel
WARNING: Non-standard signature: Co-Authored-By:
#24:
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com

WARNING: 'Co-authored-by:' is the preferred signature form
#24:
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com

041f72a total: 0 errors, 2 warnings, 0 checks, 14 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.

Commit 041f72a ("FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event") has style problems, please review.

NOTE: Ignored message types: FILE_PATH_CHANGES

NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Refer checkpatch failures, perhaps you should use Assisted-by:

[shuaz-shuai]

Changed directory to /opt/actions-runner/_work/kernel-config/kernel-config/kernel
WARNING: Non-standard signature: Co-Authored-By:
#24:
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com
WARNING: 'Co-authored-by:' is the preferred signature form
#24:
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com
041f72a total: 0 errors, 2 warnings, 0 checks, 14 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
Commit 041f72a ("FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event") has style problems, please review.
NOTE: Ignored message types: FILE_PATH_CHANGES
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Refer checkpatch failures, perhaps you should use Assisted-by:

Thanks for pointing this out. I'll use Assisted-by: in my future PRs.

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	◻️
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	◻️
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	◻️
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	◻️
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

[qcomlnxci]

Test jobs on 041f72a

• multimedia Job 267738 on hamoa-iot-evk
• multimedia Job 267737 on lemans-evk
• multimedia Job 267736 on monaco-evk
• multimedia Job 267740 on purwa-iot-evk
• multimedia Job 267732 on qcs615-ride
• multimedia Job 267739 on qcs6490-rb3gen2
• multimedia Job 267733 on qcs8300-ride
• multimedia Job 267734 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 267735 on shikra-iqs-evk

[Shiraz Hashim (shashim-quic)]

will approve once right tag is used.

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 6f1ee6c

• multimedia Job 269748 on hamoa-iot-evk
• multimedia Job 269746 on lemans-evk
• multimedia Job 269744 on monaco-evk
• multimedia Job 269750 on purwa-iot-evk
• multimedia Job 269745 on qcs615-ride
• multimedia Job 269751 on qcs6490-rb3gen2
• multimedia Job 269747 on qcs8300-ride
• multimedia Job 269752 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269749 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1409

Job 269744 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — WiFi Driver Probe Failure (ath11k_pci)

1. Failed case: Probe_Failure_Check — WiFi Driver Probe Failure (ath11k_pci)
2. Root cause: WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image for Monaco EVK, causing MHI power-up to timeout (-110) and ath11k_pci probe to fail. This is a pre-existing image packaging issue unrelated to the PR (which modifies only Bluetooth HCI QCA driver for WCN3988).
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Monaco EVK rootfs image build recipe (likely in meta-qcom firmware package or linux-firmware). Verify the WCN6855 hw2.1 nfa765 variant firmware is included in the firmware deployment for Monaco platform.
4. Detail analysis attachment: failed_case_job269744_1_detailed.md

  Case 2: WiFi Driver Probe Failure — ath11k_pci

1. Failed case: WiFi Driver Probe Failure — ath11k_pci
2. Root cause: Missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image causes MHI power-up timeout (-110) during ath11k_pci driver probe on Monaco EVK with WCN6855 WiFi hardware.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image build recipe (likely in meta-qcom firmware package or linux-firmware). Verify the firmware file exists in the upstream linux-firmware repository or Qualcomm firmware package for WCN6855 hw2.1 nfa765 variant.
4. Detail analysis attachment: failed_case_job269744_2_detailed.md

  Case 3: WiFi_OnOff — WiFi Driver Probe Failure

1. Failed case: WiFi_OnOff — WiFi Driver Probe Failure
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to time out during PCIe WiFi device initialization.
3. Possible fix: Add the missing WCN6855 WiFi firmware files (specifically ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files) to the rootfs image for monaco-evk, or update the firmware search path in the ath11k driver to use an available firmware variant.
4. Detail analysis attachment: failed_case_job269744_3_detailed.md

  Case 4: ** WiFi Driver Probe Failure — Firmware Dependency Missing

1. Failed case: ** WiFi Driver Probe Failure — Firmware Dependency Missing
2. Root cause: ** WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the test image (error -2 ENOENT), causing MHI power-up timeout (error -110 ETIMEDOUT) and ath11k_pci probe failure on monaco-evk WCN6855 hardware.
3. Possible fix: Add the missing WiFi firmware files for WCN6855/hw2.1/nfa765 variant to the rootfs/firmware partition used in the LAVA test image; verify firmware package includes ath11k/WCN6855/hw2.1/nfa765/amss.bin and related files before re-running the test.
4. Detail analysis attachment: failed_case_job269744_4_detailed.md

Job 269745 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure (known benign)

1. Failed case: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure (known benign)
2. Root cause: The cfg80211 subsystem attempted to load the optional regulatory.db firmware file during WiFi driver initialization and failed with -ENOENT (error -2). This is a benign failure because: (1) regulatory.db is an optional wireless regulatory database used for region-specific WiFi channel restrictions, (2) cfg80211 falls back to compiled-in regulatory rules when the file is missing, (3) WiFi_OnOff and BT_ON_OFF functional tests both passed, confirming wireless functionality is intact, and (4) the actual device firmware (for WCN6855 Bluetooth/WiFi chip) loaded successfully as evidenced by "Bluetooth: hci0: setting up wcn6855" and subsequent successful wireless operations.
3. Possible fix: Suppress this failure as a known false positive. The Probe_Failure_Check test is overly sensitive and flags the regulatory.db load attempt as a probe failure, but this is expected behavior on systems without the optional regulatory database file installed. No kernel or PR changes are required. If the test must pass, install the wireless-regdb package in the rootfs to provide /lib/firmware/regulatory.db, but this is cosmetic and does not affect wireless functionality.
4. Detail analysis attachment: failed_case_job269745_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test logic error — the test incorrectly expects V4L2 video-decoder and video-encoder child devices to have separate IOMMU group attachments, but these are virtual devices created by the Venus video codec driver that correctly inherit DMA protection through the parent device (aa00000.video-codec) which is properly attached to IOMMU group 7. This is not a kernel bug or SMMU failure.
3. Possible fix: Update the smmu test logic to recognize that V4L2 video codec child devices (video-decoder, video-encoder) do not require separate IOMMU group attachments on qcs615-ride when the parent video-codec device is correctly attached. The test should check only the parent device for video codec IOMMU protection.
4. Detail analysis attachment: failed_case_job269745_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm device node not available

1. Failed case: KVM_Driver — /dev/kvm device node not available
2. Root cause: QCS615 SoC does not support ARM virtualization extensions (EL2/HYP mode); kernel message at boot confirms "kvm [1]: HYP mode not available", causing KVM driver initialization to fail and /dev/kvm device node to never be created. This is a hardware platform limitation, not a kernel regression.
3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as expected-to-skip for qcs615-ride in the LAVA test suite configuration, as this SoC lacks the required ARM virtualization hardware support (no EL2/HYP mode).
4. Detail analysis attachment: failed_case_job269745_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark KVM tests as "skip" or "not applicable" for qcs615-ride platform in LAVA job definition; alternatively, disable CONFIG_KVM for qcs615 defconfig since the hardware does not support virtualization.
4. Detail analysis attachment: failed_case_job269745_4_detailed.md

  Case 5: KVM_Infra — KVM Infrastructure Test Failure (Platform Limitation)

1. Failed case: KVM_Infra — KVM Infrastructure Test Failure (Platform Limitation)
2. Root cause: The QCS615 platform boots at EL1 (Exception Level 1) instead of EL2, preventing KVM initialization. The kernel message "kvm [1]: HYP mode not available" confirms that the CPU is not running in hypervisor mode, which is a prerequisite for KVM/virtualization support. CONFIG_KVM is enabled in the kernel configuration, but /dev/kvm cannot be created because the hardware/firmware does not provide EL2 access.
3. Possible fix: This is a platform/firmware limitation, not a kernel bug or PR-introduced regression. The PR changes only Bluetooth HCI driver code (hci_qca.c) and is unrelated to KVM. To enable KVM on QCS615: (1) verify the bootloader/firmware supports booting Linux at EL2 (requires PSCI firmware configuration or hypervisor stub), (2) update device tree to ensure CPUs use "psci" enable-method with EL2 entry, (3) if the platform does not support EL2 in production firmware, mark KVM tests as "skip" for this SoC in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job269745_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM module initialization failed because the qcs615-ride platform does not support ARM Hypervisor (EL2) mode — kernel logged "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The qcs615-ride board does not have EL2 (hypervisor) support enabled in firmware/bootloader. Either: (1) exclude KVM tests from the qcs615-ride test suite, or (2) if EL2 support is expected, verify bootloader configuration enables HYP mode and boots kernel at EL2.
4. Detail analysis attachment: failed_case_job269745_6_detailed.md

Job 269746 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test case flags firmware load errors in dmesg, but all failures are benign: (1) Bluetooth firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) fail initial direct load but Bluetooth driver successfully loads firmware via fallback mechanism (BT_ON_OFF test passes); (2) regulatory.db file is absent but cfg80211 successfully uses compiled-in X.509 certificates for regulatory data (WiFi_OnOff test passes). No actual driver or functionality failures exist.
3. Possible fix: Suppress this test failure as a false positive. The Probe_Failure_Check test should be updated to exclude benign firmware load failures where: (a) Bluetooth firmware errors when BT_ON_OFF passes, (b) regulatory.db errors when built-in certs are loaded and WiFi_OnOff passes. Alternatively, package the optional firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv, regulatory.db) in the rootfs to eliminate the initial load failures.
4. Detail analysis attachment: failed_case_job269746_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on lemans-evk is not attached to any IOMMU group, indicating missing or incorrect device tree iommus property for this device on the SA8775P (lemans) platform.
3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/sa8775p.dtsi to attach it to the appropriate SMMU context bank; this is a pre-existing platform DT issue unrelated to the PR under test (Bluetooth HCI change).
4. Detail analysis attachment: failed_case_job269746_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test infrastructure issue — test definition marked as "unfinished" despite successful kernel boot and test execution completion; LAVA dispatcher logged "Marking unfinished test run as failed" after test runner exited with <LAVA_TEST_RUNNER EXIT> signal.
3. Possible fix: This is a LAVA test infrastructure/configuration issue, not a kernel regression introduced by PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409. Re-trigger the LAVA job to verify if this is a transient infrastructure issue. If the issue persists, review the LAVA test definition for 0_qcom-next-ci-premerge-tests to ensure proper completion signaling and verify that all expected tests are configured to run.
4. Detail analysis attachment: failed_case_job269746_3_detailed.md

Job 269747 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check — False Positive (Benign Firmware Load Message)

1. Failed case: ** Probe_Failure_Check — False Positive (Benign Firmware Load Message)
2. Root cause: ** The test flagged a benign cfg80211 regulatory.db firmware load failure (error -2 / ENOENT) that occurs when the optional regulatory database file is not present in /lib/firmware. cfg80211 successfully falls back to compiled-in regulatory rules, and all WiFi and Bluetooth functionality is fully operational (WiFi_Firmware_Driver, WiFi_OnOff, BT_FW_KMD_Service, BT_ON_OFF, and BT_SCAN all passed).
3. Possible fix: Suppress this specific firmware load error pattern in the Probe_Failure_Check test logic. Add an exception rule: if the error is "regulatory: Direct firmware load for regulatory.db failed with error -2" AND both WiFi_Firmware_Driver and WiFi_OnOff tests pass, classify as benign and do not fail Probe_Failure_Check. Alternatively, package the regulatory.db file in the rootfs to eliminate the message entirely.
4. Detail analysis attachment: failed_case_job269747_1_detailed.md

  Case 2: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: /dev/kvm device node is not present on qcs8300-ride despite CONFIG_KVM=y and CONFIG_VIRTUALIZATION=y being enabled in the kernel configuration. The KVM subsystem did not initialize at boot, likely because the platform does not support EL2/VHE (Virtualization Host Extensions) or KVM initialization was silently skipped due to missing hardware virtualization support on this SoC.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR only modifies Bluetooth hci_qca driver). If KVM support is required on qcs8300-ride: (1) verify the SoC hardware supports ARMv8 virtualization extensions (EL2/VHE), (2) check bootloader configuration to ensure the kernel is booted at EL2, (3) review early boot logs for any KVM initialization messages or silent failures, (4) if hardware supports it but KVM is not initializing, enable CONFIG_ARM64_VHE and ensure no bootloader restrictions prevent EL2 operation. If KVM is not expected to work on this platform, suppress this test case for qcs8300-ride in the CI configuration.
4. Detail analysis attachment: failed_case_job269747_2_detailed.md

  Case 3: KVM_EL2_DTB — /dev/kvm device node not available

1. Failed case: KVM_EL2_DTB — /dev/kvm device node not available
2. Root cause: KVM is not available on qcs8300-ride because the system is running as a guest under the Gunyah hypervisor (nested virtualization not supported). The kernel has CONFIG_KVM=y but KVM cannot initialize when running under a hypervisor without nested virtualization support. The test failure is expected platform behavior, not a regression introduced by PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (which only modifies Bluetooth hci_qca driver for WCN3988).
3. Possible fix: Mark KVM tests as expected-fail or skip for qcs8300-ride platform in the LAVA test suite, as this SoC runs under Gunyah hypervisor where KVM is architecturally unavailable. The PR changes are unrelated and safe to merge.
4. Detail analysis attachment: failed_case_job269747_3_detailed.md

  Case 4: KVM_Infra — Platform Limitation (Gunyah Hypervisor Active)

1. Failed case: KVM_Infra — Platform Limitation (Gunyah Hypervisor Active)
2. Root cause: The qcs8300-ride platform boots under Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-3fe287d48"), which means the kernel runs as a guest VM without EL2 access. KVM requires EL2 (hypervisor mode) to create /dev/kvm and cannot function when the system is already running under a hypervisor. CONFIG_KVM is enabled but the KVM driver cannot initialize because nested virtualization is not supported.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM tests are not applicable to this platform configuration. Either: (1) Skip KVM tests on qcs8300-ride in the LAVA job definition, or (2) Use a different boot configuration that does not load Gunyah hypervisor if KVM testing is required on this hardware.
4. Detail analysis attachment: failed_case_job269747_4_detailed.md

  Case 5: LAVA Test Infrastructure Issue — Test marked as unfinished despite successful completion

1. Failed case: LAVA Test Infrastructure Issue — Test marked as unfinished despite successful completion
2. Root cause: LAVA dispatcher marked the test run "0_qcom-next-ci-premerge-tests" as failed with "Marking unfinished test run as failed" despite the test runner successfully completing and exiting with "<LAVA_TEST_RUNNER EXIT>". The kernel booted successfully, all tests executed, and the test runner completed normally, but LAVA's internal state tracking flagged the run as incomplete.
3. Possible fix: Re-trigger the LAVA job. This is a LAVA infrastructure state-tracking issue, not a kernel or test failure. If the issue persists, check the LAVA job definition for missing test completion signals or timeout configurations that may cause LAVA to prematurely mark the run as unfinished.
4. Detail analysis attachment: failed_case_job269747_5_detailed.md

Job 269748 | SoC hamoa-evk

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

Failed test cases in LAVA job 269748 (SoC: hamoa-evk).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two pre-existing platform issues on hamoa-evk: (1) qcom_qseecom_uefisecapp probe fails with -EBUSY due to secure world resource unavailability, a known platform limitation; (2) regulatory.db firmware file missing from rootfs, though WiFi functional tests pass indicating proper operation with built-in regulatory data.
3. Possible fix: These are not PR-introduced regressions. For production: (1) Add regulatory.db to rootfs firmware directory if regulatory compliance requires it, or suppress this benign failure since WiFi operates correctly with compiled-in certificates; (2) Investigate qcom_qseecom_uefisecapp requirements for hamoa-evk or mark as expected failure if UEFI secure app is not supported on this platform.
4. Detail analysis attachment: failed_case_job269748_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec on hamoa-evk (x7181) is not attached to any IOMMU group, indicating the device either failed to probe, is missing from the device tree, or the video codec driver is not loaded/configured for this platform.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (Bluetooth hci_qca changes). The video codec device tree node or driver needs investigation on hamoa-evk. Since all other critical masters (UFS, GPU, USB, Display) are correctly attached to IOMMU groups and no SMMU/IOMMU errors appear in dmesg, the kernel SMMU subsystem is functional. Recommend: (1) verify aa00000.video-codec device node exists in hamoa-evk device tree, (2) check if video codec driver (qcom-iris or qcom-venus) is enabled in kernel config and successfully probed, (3) if the device is intentionally disabled on this platform, update the SMMU test's critical master list to exclude it for hamoa-evk.
4. Detail analysis attachment: failed_case_job269748_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed with "HYP mode not available" because the system is running as a guest under the Gunyah hypervisor (gunyah-mobile-1f99e07c2), which occupies EL2. KVM requires direct EL2 access to provide virtualization, which is unavailable when Linux runs as a guest VM. This is a platform configuration issue, not a kernel bug.
3. Possible fix: This test should be skipped on Hamoa IoT EVK when running under Gunyah hypervisor. Add a test precondition check: if /sys/hypervisor/type exists and contains "gunyah", or if dmesg contains "Gunyah based bootup", skip KVM tests with result=skip rather than fail. Alternatively, configure the LAVA job to exclude KVM tests for Gunyah-based boot configurations.
4. Detail analysis attachment: failed_case_job269748_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the hamoa-evk platform is running under the Gunyah hypervisor at EL1 (guest mode), and KVM requires EL2 (hypervisor mode) to function; nested virtualization is not supported in this configuration.
3. Possible fix: Exclude KVM tests from the hamoa-evk LAVA test suite, or run KVM tests only on bare-metal configurations where the kernel boots directly at EL2 without an underlying hypervisor.
4. Detail analysis attachment: failed_case_job269748_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed with "HYP mode not available" because the Gunyah hypervisor (gunyah-mobile-1f99e07c2) is already running at EL2 on the Hamoa EVK platform, preventing KVM from taking control of the hypervisor layer; CONFIG_KVM is enabled in the kernel but /dev/kvm cannot be created without EL2 access.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression (the PR only modifies Bluetooth hci_qca driver). To enable KVM testing on Hamoa EVK: either (1) boot without the Gunyah hypervisor to allow KVM direct EL2 access, or (2) skip KVM tests on platforms where Gunyah is the primary hypervisor, or (3) use nested virtualization if Gunyah supports exposing virtual EL2 to the primary VM (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job269748_5_detailed.md

  Case 6: ** KVM Infrastructure Test Failure — Missing /dev/kvm Device Node

1. Failed case: ** KVM Infrastructure Test Failure — Missing /dev/kvm Device Node
2. Root cause: ** KVM driver initialization aborted because HYP (EL2 hypervisor) mode is not available on the Hamoa IoT EVK platform. The kernel message kvm [1]: HYP mode not available indicates the platform does not provide EL2 access required for KVM virtualization, either due to hardware limitations or firmware/bootloader configuration that boots the kernel at EL1 without hypervisor support.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The Hamoa EVK does not support KVM virtualization in its current firmware/hardware configuration. To resolve: (1) Skip KVM tests on Hamoa platform in CI test matrix, OR (2) Update Hamoa firmware/bootloader to enable EL2 access if the hardware supports it, OR (3) Accept this as a known platform limitation and mark KVM tests as "not applicable" for Hamoa.
4. Detail analysis attachment: failed_case_job269748_6_detailed.md

Job 269749 | SoC shikra-iqs-evk

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

Failed test cases in LAVA job 269749 (SoC: shikra-iqs-evk).

  Case 1: GIC Test Script Bug — Hardcoded 8-CPU Assumption on 4-CPU Platform

1. Failed case: GIC Test Script Bug — Hardcoded 8-CPU Assumption on 4-CPU Platform
2. Root cause: The GIC test script at /lava-269749/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh line 75 attempts to parse timer interrupt counts for CPUs 0-7, but shikra-iqs-evk has only 4 CPUs (0-3). When the script tries to extract columns 5-8 from /proc/interrupts (which only has 4 columns), it passes non-numeric strings ("GICv3", "Level", "arch_timer") to bash integer comparison, causing [: GICv3: integer expected errors and false test failures for CPUs 4-7.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo and only validate timer interrupts for CPUs that actually exist, instead of hardcoding a loop over CPUs 0-7.
4. Detail analysis attachment: failed_case_job269749_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test infrastructure issue — Probe_Failure_Check test detected pre-existing probe failures on shikra-iqs-evk platform (missing firmware files for ucsi_ccg USB-C controller and regulatory.db, TPM hardware timeout, and audio subsystem deferred probes) that are unrelated to the PR changes (Bluetooth hci_qca driver).
3. Possible fix: Suppress this test failure as a known platform limitation for shikra-iqs-evk, OR add missing firmware files (ccg_secondary.cyacd2, regulatory.db) to the rootfs and resolve audio DT dependencies. The PR itself is correct and should be merged — Bluetooth functional tests (BT_FW_KMD_Service, BT_ON_OFF) passed.
4. Detail analysis attachment: failed_case_job269749_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test environment configuration issue, not a kernel regression introduced by PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409. The PR modifies only Bluetooth HCI QCA driver code (drivers/bluetooth/hci_qca.c) and has no relationship to PCIe or the QPS615 hardware. To resolve: (1) add TC956X_Firmware_PCIeBridge.bin to the rootfs firmware directory, (2) build and install the tc956x_pcie_eth out-of-tree driver module for the test kernel, or (3) mark this test as SKIP when the QPS615 hardware/firmware is not provisioned on the target board.
4. Detail analysis attachment: failed_case_job269749_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controllers on shikra-iqs-evk are configured in gadget (device) mode instead of host mode; no USB host controller drivers (dwc3/xhci) probed during boot, and no USB root hubs are exposed to userspace, causing the USBHost validation test to fail with "no USB root hubs are exposed and no inactive device role could be confirmed".
3. Possible fix: This is a pre-existing board/platform configuration issue unrelated to PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (which only modifies Bluetooth hci_qca driver). The USB device tree configuration for shikra-iqs-evk needs to be updated to enable host mode (dr_mode = "host" or "otg") instead of gadget mode, or the test expectation should be adjusted to skip USB host validation on boards where USB is intentionally configured as gadget-only.
4. Detail analysis attachment: failed_case_job269749_4_detailed.md

  Case 5: BT_SCAN (suppressed — known benign: BT firmware false positive — BT_ON_OFF passed)

1. Failed case: BT_SCAN (suppressed — known benign: BT firmware false positive — BT_ON_OFF passed)
2. Root cause: Test infrastructure failure — BT_SCAN test failed to discover nearby Bluetooth devices in the LAVA lab environment, but the Bluetooth stack is fully functional as evidenced by BT_ON_OFF test passing (power on/off cycles completed successfully with hci0 adapter operational).
3. Possible fix: No fix required. Per LAVA Known Benign Failure Suppression Rule 3, when BT_ON_OFF passes, a BT_SCAN failure is a known false positive caused by the test environment lacking discoverable Bluetooth devices or timing issues in the test harness, not a kernel regression. The PR changes (WCN3988 baudrate vendor event handling) do not affect scan functionality.
4. Detail analysis attachment: failed_case_job269749_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize because the system is running under the Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode — kernel message "kvm [1]: HYP mode not available" confirms EL2 is already occupied by Gunyah, making /dev/kvm unavailable.
3. Possible fix: This is expected behavior on shikra-iqs-evk when booted with Gunyah hypervisor firmware; KVM and Gunyah are mutually exclusive (both require EL2). To enable KVM, boot without Gunyah hypervisor, or mark KVM tests as SKIP when Gunyah is detected. The PR (Bluetooth hci_qca patch) did not cause this failure.
4. Detail analysis attachment: failed_case_job269749_6_detailed.md

  Case 7: ** KVM_EL2_DTB (Test Environment Configuration Issue)

1. Failed case: ** KVM_EL2_DTB (Test Environment Configuration Issue)
2. Root cause: ** KVM cannot initialize because Gunyah hypervisor occupies EL2 on Shikra IQS EVK. Kernel correctly reports "HYP mode not available" at boot. This is a platform boot configuration issue, not a kernel bug.
3. Possible fix: Either (1) boot Shikra in native EL2 mode (without Gunyah) for KVM testing by selecting the appropriate EFI boot entry, or (2) exclude KVM tests from the Shikra test suite when Gunyah hypervisor is active, as KVM and Gunyah cannot coexist (both require exclusive EL2 access).
4. Detail analysis attachment: failed_case_job269749_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on shikra-iqs-evk because the Gunyah hypervisor (gunyah-mobile-98db777b6) is running at EL2, preventing KVM from accessing hypervisor mode. Kernel message: "kvm [1]: HYP mode not available".
3. Possible fix: This is not a kernel regression - it is expected platform behavior. The test should be skipped on platforms running Gunyah hypervisor. Update the LAVA test suite to detect Gunyah presence (check for "Hypervisor cold boot, version: gunyah" in boot log or /sys/hypervisor/type) and skip all KVM tests when Gunyah is active.
4. Detail analysis attachment: failed_case_job269749_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM is not available on the shikra-iqs-evk platform because the hardware does not support HYP (EL2 hypervisor) mode, as indicated by the kernel message "kvm [1]: HYP mode not available" during boot.
3. Possible fix: Exclude KVM test cases from the CI test suite for shikra-iqs-evk, or mark them as expected-skip for platforms without EL2 support; this is a platform hardware limitation, not a kernel bug.
4. Detail analysis attachment: failed_case_job269749_9_detailed.md

Job 269750 | SoC purwa-evk

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

Failed test cases in LAVA job 269750 (SoC: purwa-evk).

  Case 1: LAVA Infrastructure Failure — Invalid TESTCASE signal (LAVA signal protocol corruption)

1. Failed case: LAVA Infrastructure Failure — Invalid TESTCASE signal (LAVA signal protocol corruption)
2. Root cause: LAVA STARTRUN signal corrupted by kernel console output interleaving. DPU (Display Processing Unit) driver on purwa-evk (x1e80100) continuously prints error messages to console (frame done timeout, vblank timeout every ~70ms). When LAVA test framework emitted STARTRUN signal via echo, a DPU error message was printed simultaneously, splitting the signal string and corrupting the protocol. LAVA parser rejected the malformed signal, then rejected subsequent TESTCASE result signals as invalid due to missing test UUID context. This is NOT a kernel crash or functional failure — all tests (cdsp_remoteproc, adsp_remoteproc, CPUFreq) passed functionally.
3. Possible fix: Add loglevel=3 or quiet to kernel command line in LAVA job definition for purwa-evk to suppress KERN_ERR messages and prevent DPU error spam from corrupting LAVA signals. Alternative: apply drm.debug=0x00 or rate-limit DPU error messages in kernel driver code. Long-term: fix DPU timeout root cause (display panel configuration or disable display subsystem for headless CI). The PR (Bluetooth HCI QCA WCN3988 support) is NOT the cause — DPU errors are pre-existing on purwa-evk and unrelated to Bluetooth changes.
4. Detail analysis attachment: failed_case_job269750_1_detailed.md

  Case 2: lava-test-retry

1. Failed case: lava-test-retry
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Re-trigger the CI job. This is a transient LAVA infrastructure issue caused by timing-sensitive serial console output interleaving, not a kernel regression. If the issue recurs frequently on purwa-evk, consider: (1) suppressing DRM debug messages by setting drm.debug=0 in kernel cmdline, or (2) increasing LAVA signal retry logic, or (3) investigating and fixing the underlying DRM vblank timeout issue on x1e80100 display hardware (253 occurrences of DRM errors during this job).
4. Detail analysis attachment: failed_case_job269750_2_detailed.md

  Case 3: LAVA Test Infrastructure Failure — Signal Corruption

1. Failed case: LAVA Test Infrastructure Failure — Signal Corruption
2. Root cause: The LAVA_SIGNAL_STARTRUN message was corrupted by DPU error messages ([drm:dpu_encoder_frame_done_timeout:2732] [dpu error]enc40 frame done timeout) being interleaved into the serial console output at the exact moment the signal was transmitted, causing LAVA to receive a malformed signal <START[> 55.130015][ C2] [drm:dpu_encoder_frame_done_timeout:2732]... instead of the expected <LAVA_SIGNAL_STARTRUN 0_qcom-next-ci-premerge-tests 269750_1.1.3.1>. The actual test (cdsp_remoteproc) passed successfully.
3. Possible fix: This is a transient LAVA infrastructure issue caused by high-frequency DPU error messages flooding the console during test signal transmission. Re-trigger the CI job. If the issue persists, investigate the root cause of the DPU vblank timeout errors on purwa-evk (x1e80100 SoC) which are unrelated to the PR changes (Bluetooth hci_qca driver) but are causing console noise that corrupts LAVA signals.
4. Detail analysis attachment: failed_case_job269750_3_detailed.md

Job 269751 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Test Infrastructure False Positive

1. Failed case: Probe_Failure_Check — Test Infrastructure False Positive
2. Root cause: The Probe_Failure_Check test flags two benign early-boot firmware load failures (regulatory.db for cfg80211 and renesas_usb_fw.mem for xhci-pci-renesas) that do not indicate genuine kernel regressions. Both failures are error -2 (ENOENT, file not found) during initial probe, which is expected behavior when optional firmware files are not present in the rootfs. WiFi and Bluetooth functional tests (WiFi_OnOff, WiFi_Firmware_Driver, BT_ON_OFF, BT_FW_KMD_Service, BT_SCAN) all passed, confirming the wireless subsystem loaded firmware successfully at runtime. The xhci-pci-renesas failure is for an optional PCIe USB controller that is not critical for qcs6490-rb3gen2 platform functionality.
3. Possible fix: Suppress these two specific probe failures in the Probe_Failure_Check test logic by adding them to a known-benign list, or refine the test to only flag probe failures for devices that remain non-functional after boot completes. The PR (Bluetooth hci_qca WCN3988 baudrate fix) is unrelated to these failures and should not be blocked by this test result.
4. Detail analysis attachment: failed_case_job269751_1_detailed.md

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

1. Failed case: ** 0_qcom-next-ci-premerge-tests
2. Root cause: ** LAVA test suite marked as failed due to one pre-existing test failure (Probe_Failure_Check) that detected probe errors unrelated to the PR (missing regulatory.db firmware and Renesas xHCI firmware). The PR only modifies Bluetooth HCI QCA driver for WCN3988 baudrate handling, and all Bluetooth functional tests passed.
3. Possible fix: The PR is not the cause of this failure. The Probe_Failure_Check failure is a pre-existing infrastructure issue. To resolve: (1) Add missing regulatory.db firmware file to the rootfs image, and (2) investigate the Renesas xHCI PCIe controller firmware load failure (error -2 indicates file not found). The PR can be merged as Bluetooth functionality is verified working.
4. Detail analysis attachment: failed_case_job269751_2_detailed.md

Job 269752 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two pre-existing probe failures on qcs9100-ride platform: (1) regulatory.db firmware missing (-ENOENT) for cfg80211 wireless regulatory database, and (2) Aquantia AQR115C Ethernet PHY probe failure (-EINVAL) due to missing firmware-name DT property.
3. Possible fix: These are pre-existing platform configuration issues unrelated to PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (Bluetooth HCI QCA WCN3988 baudrate fix). Suppress these known qcs9100-ride platform issues in CI, or fix by: (1) adding regulatory.db firmware file to rootfs wireless-regdb package, and (2) adding firmware-name property to qcs9100-ride DT Aquantia PHY node if firmware is required for this PHY variant.
4. Detail analysis attachment: failed_case_job269752_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test expects the video codec device aa00000.video-codec to be attached to an IOMMU group on qcs9100-ride, but the device is either absent from the device tree, failed to probe, or lacks IOMMU configuration; this is a pre-existing platform configuration issue unrelated to the PR (which modifies only Bluetooth HCI driver code).
3. Possible fix: Update the qcs9100-ride device tree to either remove the video codec device from the SMMU test's critical master list (if the SoC does not have this video codec IP block), or add the missing video codec device tree node with proper IOMMU bindings if the hardware supports it.
4. Detail analysis attachment: failed_case_job269752_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Verify and correct the device tree for qcs9100-ride: ensure the ethernet@23040000 node has a valid phy-handle property pointing to a correctly defined PHY node under the MDIO bus, confirm phy-mode is set appropriately (e.g., rgmii-id), and check that the MDIO bus controller is enabled and the PHY address matches hardware. If the PHY is not being detected on the MDIO bus, add debug to confirm MDIO bus probe and PHY enumeration.
4. Detail analysis attachment: failed_case_job269752_3_detailed.md

  Case 4: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** The qcs9100-ride platform booted under the Gunyah hypervisor (as a guest VM), which owns EL2/HYP mode. KVM requires direct access to EL2 to function, but when the kernel runs as a guest, EL2 is unavailable. The kernel correctly detected this condition and reported "HYP mode not available" at boot, preventing /dev/kvm creation.
3. Possible fix: Configure the qcs9100-ride LAVA job to boot in native EL2 mode (without Gunyah hypervisor) for KVM test suites. Update the bootloader configuration to respect the el2kvm EFI variable and boot directly to EL2. As a short-term mitigation, modify the test suite to detect Gunyah boot and skip KVM tests with a clear message indicating they are not applicable in guest mode.
4. Detail analysis attachment: failed_case_job269752_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM Unavailable (Platform Limitation)

1. Failed case: KVM_EL2_DTB — KVM Unavailable (Platform Limitation)
2. Root cause: KVM driver initialization failed because the qcs9100-ride platform is not running in EL2 (hypervisor mode); kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU/firmware does not provide the required virtualization support for KVM to create /dev/kvm.
3. Possible fix: This is not a kernel regression introduced by PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (Bluetooth hci_qca patch). The qcs9100-ride platform does not support KVM/virtualization in its current firmware/boot configuration. To enable KVM: (1) verify the SoC supports virtualization extensions, (2) ensure the bootloader/firmware boots the kernel at EL2 instead of EL1, (3) if the platform fundamentally lacks EL2 support, exclude KVM tests from the qcs9100-ride CI test suite.
4. Detail analysis attachment: failed_case_job269752_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available on the qcs9100-ride platform; the kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or the hypervisor extension is disabled in firmware/bootloader configuration.
3. Possible fix: This is a pre-existing platform configuration issue, not a regression introduced by PR FROMLIST: Bluetooth: hci_qca: WCN3988: Drop baudrate change vendor event #1409 (which only modifies Bluetooth hci_qca driver). To enable KVM on qcs9100-ride: (1) verify the bootloader/firmware boots the kernel at EL2 with VHE (Virtualization Host Extensions) enabled, (2) check that the device tree does not disable the hypervisor node, (3) if the platform does not support EL2 in hardware or firmware policy, mark KVM tests as expected-to-skip for this SoC in the CI configuration.
4. Detail analysis attachment: failed_case_job269752_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because the qcs9100-ride platform does not support EL2 (Hypervisor) mode, as evidenced by the kernel message "kvm [1]: HYP mode not available" during boot. CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware does not provide the necessary virtualization extensions, preventing /dev/kvm device creation.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (the PR only modifies Bluetooth HCI QCA driver code). To resolve: (1) Skip KVM tests on qcs9100-ride in the LAVA job definition, or (2) Run KVM tests only on platforms with confirmed EL2 support (e.g., platforms with hypervisor firmware), or (3) If EL2 support is expected on this platform, investigate bootloader/firmware configuration to ensure virtualization extensions are enabled at boot time.
4. Detail analysis attachment: failed_case_job269752_7_detailed.md

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 6f1ee6c

• multimedia Job 269748 on hamoa-iot-evk
• multimedia Job 269746 on lemans-evk
• multimedia Job 269744 on monaco-evk
• multimedia Job 269775 on purwa-iot-evk
• multimedia Job 269745 on qcs615-ride
• multimedia Job 269751 on qcs6490-rb3gen2
• multimedia Job 269747 on qcs8300-ride
• multimedia Job 269752 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269749 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 6f1ee6c

• multimedia Job 269748 on hamoa-iot-evk
• multimedia Job 269746 on lemans-evk
• multimedia Job 269744 on monaco-evk
• multimedia Job 269786 on purwa-iot-evk
• multimedia Job 269745 on qcs615-ride
• multimedia Job 269751 on qcs6490-rb3gen2
• multimedia Job 269747 on qcs8300-ride
• multimedia Job 269752 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269749 on shikra-iqs-evk