Skip to content

FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 - #917

Merged
Salendarsingh Gaud (sgaud-quic) merged 1 commit into
qualcomm-linux:qcom-6.18.yfrom
QTI-Quill:talos-bt-issue
Sep 9, 2026
Merged

FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615#917
Salendarsingh Gaud (sgaud-quic) merged 1 commit into
qualcomm-linux:qcom-6.18.yfrom
QTI-Quill:talos-bt-issue

Conversation

@QTI-Quill

@QTI-Quill QTI-Quill commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown

Continuous high-amplitude noise could occur in the DA7213 microphone capture path after a Bluetooth out-of-range/reset event followed by reconnection. The noise was present in both the raw ALSA capture and PipeWire input, confirming that it originated before Bluetooth encoding.

The codec already obtains and enables MCLK through its DT clock and bias-level handling. However, the machine driver did not explicitly configure the codec sysclk during hw_params(). Enable codec_sysclk_set for QCS615 so that the DA7213 clock source and rate are configured before the codec power-up sequence.

Verified on QCS615 Talos with repeated Bluetooth disconnect and reconnect cycles. The noise was no longer reproducible.

Link: https://lore.kernel.org/all/20260807012450.1038180-1-le.qi@oss.qualcomm.com/

CRs-Fixed: 4612854

Le Qi
FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615
37789db 
Continuous high-amplitude noise could occur in the DA7213 microphone
capture path after a Bluetooth out-of-range/reset event followed by
reconnection. The noise was present in both the raw ALSA capture and
PipeWire input, confirming that it originated before Bluetooth
encoding.

The codec already obtains and enables MCLK through its DT clock and
bias-level handling. However, the machine driver did not explicitly
configure the codec sysclk during hw_params(). Enable
codec_sysclk_set for QCS615 so that the DA7213 clock source and rate
are configured before the codec power-up sequence.

Verified on QCS615 Talos with repeated Bluetooth disconnect and
reconnect cycles. The noise was no longer reproducible.

Link: https://lore.kernel.org/all/20260807012450.1038180-1-le.qi@oss.qualcomm.com/
Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
@qswat-orbit-external

qswat-orbit-external Bot commented Aug 7, 2026

Copy link
Copy Markdown

Merge Check Failed: No Change Task Found

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

Entities:

  • kernel.qli.2.0

CR: 4612854

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

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 7, 2026

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4612854 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4612854
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

2 similar comments
@qswat-orbit-external

qswat-orbit-external Bot commented Aug 7, 2026

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4612854 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4612854
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 7, 2026

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4612854 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4612854
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

@QTI-Quill

QTI-Quill commented Aug 7, 2026

Copy link
Copy Markdown
Author

qli-2.0 GA Critical Fix

@qcomlnxci

qcomlnxci commented Aug 11, 2026

Copy link
Copy Markdown

Test jobs on 37789db

@qcomlnxci

qcomlnxci commented Aug 11, 2026

Copy link
Copy Markdown

Test Matrix

Test Case *

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Build Status: ✅ BUILD SUCCEEDED

The kernel compilation completed successfully with no errors. The workflow failure was caused by LAVA test infrastructure issues, not by compilation problems.

Component Status Details
Kernel Build ✅ Pass Completed successfully at 2026-08-11T07:44:35Z
RT Build ✅ Pass Completed successfully
Modified File ✅ Pass sound/soc/qcom/sc8280xp.c compiled without errors
Test Submission ❌ Fail LAVA job submission failed (infrastructure issue)

Verdict

No compilation errors were introduced by this PR. The build succeeded completely. The workflow failure is due to test infrastructure (LAVA job submission) issues, which are unrelated to the code changes in this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Verdict

No compilation errors found. Both the default and RT kernel builds completed successfully. The workflow failure was caused by LAVA test infrastructure timeouts, not by any issues introduced in this PR.

Build Status:

  • ✅ Default kernel build: SUCCESS
  • ✅ RT kernel build: SUCCESS
  • ❌ LAVA test submission: FAILED (infrastructure timeout)

Root Cause: All test jobs failed to submit to the LAVA server due to connection timeouts (HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out). This is an infrastructure issue unrelated to the PR changes.

PR Changes: The PR adds a single line enabling codec_sysclk_set = true for QCS615 in sound/soc/qcom/sc8280xp.c. This change does not introduce any compilation errors.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Verdict

No compilation errors found. The workflow failed due to LAVA test infrastructure timeout, not build failures. Both kernel builds (regular and RT) completed successfully.

Root Cause: LAVA job submission timeout (HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out) — this is an infrastructure issue unrelated to the PR code changes.

Build Status:

  • ✅ Regular kernel build: SUCCESS
  • ✅ RT kernel build: SUCCESS
  • ✅ Modified file sound/soc/qcom/sc8280xp.c: Compiled successfully
  • ❌ Test submission: FAILED (infrastructure timeout)

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Build Status: ✅ SUCCESSFUL

The kernel build completed successfully. The workflow failure was caused by test infrastructure issues (LAVA job submission failures), not compilation errors.

Component Status Details
Kernel Build ✅ Pass All files compiled successfully
Modified File ✅ Pass sound/soc/qcom/sc8280xp.c compiled without errors
Test Submission ❌ Fail LAVA job submission failed (infrastructure issue)

Verdict

No compilation errors were introduced by this PR. The workflow failure is due to test infrastructure problems, not code issues. The PR changes are build-safe.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Build Status: ✅ SUCCESSFUL

Both the standard and RT kernel builds completed successfully with zero compilation errors.

Test Status: ❌ FAILED (Infrastructure Issue)

All 10 LAVA test jobs failed due to LAVA server connectivity issues, not code problems:

Platform Error
qcs615-ride HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
qcs6490-rb3gen2 HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
monaco-evk HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
purwa-iot-evk HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
lemans-evk HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
qcs8300-ride HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
hamoa-iot-evk HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
qrb2210-rb1 502 Server Error: Bad Gateway for url: lava-oss.qualcomm.com/RPC2
shikra-iqs-evk 504 Server Error: Gateway Time-out for url: lava-oss.qualcomm.com/RPC2
qcs9100-ride-r3 LAVA job submission failed

Verdict

This PR introduces ZERO compilation errors. The workflow failure is caused by LAVA infrastructure connectivity issues (timeouts and gateway errors), not by the code changes in this PR. The PR change (adding .codec_sysclk_set = true to qcs615_priv_data) is syntactically correct and compiled successfully.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Verdict

No compilation errors found. Both kernel builds (standard and RT) completed successfully. The workflow failure was caused by LAVA test infrastructure issues (connection timeouts to lava-oss.qualcomm.com), not by the PR changes.

Build Status:

  • ✅ Standard kernel build: SUCCESS
  • ✅ RT kernel build: SUCCESS
  • ❌ LAVA test submission: FAILED (infrastructure timeout)

Root Cause: The workflow marked as failed due to LAVA job submission timeouts when attempting to connect to lava-oss.qualcomm.com (HTTPSConnectionPool read timeout after 20 seconds). This is an infrastructure/network issue unrelated to the code changes in this PR.

PR Changes: The PR adds a single line (codec_sysclk_set = true) to sound/soc/qcom/sc8280xp.c for QCS615 audio configuration. This change compiled cleanly in both build variants.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded; workflow failed due to LAVA test infrastructure timeout

Verdict

The kernel build completed successfully. The workflow failure was caused by LAVA test job submission timeouts (infrastructure issue), not by compilation errors. The PR introduces no build-breaking changes.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Build Status: ✅ SUCCESS

Both kernel builds (standard and RT) completed successfully with no compilation errors.

Build Type Status Result
Standard build ✅ Pass Build completed successfully
RT build ✅ Pass Build completed successfully

Workflow Failure Cause

The workflow was marked as failed due to LAVA test job submission failures, not build failures. All test jobs failed to submit to the LAVA infrastructure:

  • qcs6490-rb3gen2: LAVA job submission failed
  • All other target platforms: LAVA job submission failed

Verdict

No compilation errors were introduced by this PR. The PR changes compile cleanly. The workflow failure is due to infrastructure issues with LAVA test job submission, which is unrelated to the code changes in this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

Build Status: ✅ SUCCESS

The kernel build completed successfully for both standard and RT configurations. The PR changes compiled without errors.

Build Type Status Details
Standard Build ✅ Pass sound/soc/qcom/sc8280xp.c compiled and linked successfully
RT Build ✅ Pass All modules built successfully

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test job submission timeouts, not compilation errors:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): 
Read timed out. (read timeout=20.0)

All 10 test jobs failed to submit due to LAVA server connectivity issues.

Verdict

No compilation errors found. The PR introduces no build failures. The workflow failure is due to infrastructure issues (LAVA server timeout), not code problems.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #917

PR: #917
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31466005090

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Workflow failed due to LAVA infrastructure timeout, not code issues

Verdict

No compilation errors found. The kernel built successfully for both standard and RT configurations. The workflow failure was caused by LAVA server connectivity timeouts during test job submission, which is an infrastructure issue unrelated to the PR code changes.

📎 Detailed analysis: Full report

@qcomlnxci

qcomlnxci commented Aug 14, 2026

Copy link
Copy Markdown

Test Matrix

Test Case monaco-evk-multimedia qcs615-ride-multimedia qcs9100-ride-r3-multimedia

@qcomlnxci

qcomlnxci commented Aug 14, 2026

Copy link
Copy Markdown

Test jobs on 37789db

@QTI-Quill

QTI-Quill commented Aug 14, 2026

Copy link
Copy Markdown
Author

Hi Komal Bajaj (@Komal-Bajaj)

Do you know what happened here for lava job fail? Seems http connection issue. Thanks

@qcomlnxci

qcomlnxci commented Aug 19, 2026

Copy link
Copy Markdown

Test jobs on 37789db

@qcomlnxci

qcomlnxci commented Aug 19, 2026

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip
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 ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ◻️ ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ 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 ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
OpenCV ✅ Pass ✅ 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 ⚠️ skip
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ❌ Fail ❌ Fail ❌ Fail ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
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 ◻️
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

qcomlnxci commented Aug 20, 2026

Copy link
Copy Markdown

Test jobs on 37789db

@qcomlnxci

qcomlnxci commented Aug 20, 2026

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip
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 ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ 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 ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ✅ Pass ❌ Fail
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
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 ❌ Fail ❌ Fail ❌ Fail ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
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 ◻️
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

@qlijarvis

qlijarvis commented Aug 22, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #917

Job 207916 | SoC lemans-evk

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

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

  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 flagged three categories of issues: (1) four PMIC temp-alarm devices in deferred probe state on lemans-evk, (2) Bluetooth firmware load failures (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv), and (3) regulatory.db firmware load failure. However, all are benign: BT_ON_OFF functional test passed (Rule 3 suppression applies), regulatory.db failure is from faux_driver test infrastructure, and temp-alarm deferred probes do not impact thermal subsystem functionality (Thermal Daemon Service started successfully). The PR modifies ASoC codec configuration for QCS615 and is completely unrelated to thermal, SPMI, or wireless subsystems on lemans-evk.
  3. Possible fix: Update the Probe_Failure_Check test script to apply suppression rules from lava-known-benign-failures.md: suppress Bluetooth firmware failures when BT_ON_OFF passes, exclude faux_driver regulatory.db failures, and filter deferred probes that don't cause functional failures (check if thermal daemon started and no thermal errors in dmesg). This is a test infrastructure improvement, not a kernel fix.
  4. Detail analysis attachment: failed_case_job207916_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, failing the SMMU test's critical master protection validation.
  3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies audio codec sysclk configuration for QCS615). The video codec device tree node likely lacks the required iommus property. Add the appropriate IOMMU phandle and stream ID to the video-codec DT node in arch/arm64/boot/dts/qcom/sa8775p.dtsi or the lemans-evk overlay.
  4. Detail analysis attachment: failed_case_job207916_2_detailed.md
  Case 3: 0_qcom-next-ci-premerge-tests (LAVA Framework Issue — Test Runner Completed But Marked Unfinished)
  1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Framework Issue — Test Runner Completed But Marked Unfinished)
  2. Root cause: LAVA dispatcher internal state machine error. The test runner successfully completed and sent <LAVA_TEST_RUNNER EXIT> signal at 18:28:06.834699, LAVA acknowledged completion with "ok: lava_test_shell seems to have completed" at 18:28:06.834857, but immediately marked the test run as "unfinished" at 18:28:06.835011 despite no timeout, crash, or incomplete test execution. This is a LAVA framework bug, not a kernel issue. The PR changes (audio codec sysclk configuration for QCS615) are unrelated to this failure.
  3. Possible fix: Re-trigger the LAVA job. This is a known LAVA dispatcher race condition where the internal completion state is not properly synchronized with the test runner exit signal. If the issue persists across multiple retries, file a bug report with the LAVA infrastructure team including job ID 207916 and the exact timestamp sequence showing the completion acknowledgment followed by the "unfinished" error.
  4. Detail analysis attachment: failed_case_job207916_3_detailed.md
Job 207917 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Driver Issues
  1. Failed case: Probe_Failure_Check — Pre-existing Platform Driver Issues
  2. Root cause: Three unrelated driver probe failures on hamoa-evk (x7181): (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone secure app unavailability, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-led 'reg' property in device tree, (3) regulatory.db firmware missing (benign - cfg80211 uses built-in certificates). None are related to the PR's ASoC codec sysclk change for QCS615.
  3. Possible fix: Mark this test as PASS with suppression — these are known pre-existing hamoa-evk platform issues unrelated to the PR under test. For proper fixes: (1) verify TZ firmware supports UEFI secure app on x7181, (2) correct the PMIC multi-led 'reg' property in hamoa DT, (3) optionally add regulatory.db to rootfs (non-critical).
  4. Detail analysis attachment: failed_case_job207917_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Six platform devices (five USB PHY devices and one video codec) on hamoa-evk lack IOMMU group attachments due to missing device tree iommus properties or incomplete driver IOMMU integration; this is a pre-existing platform configuration issue unrelated to the audio codec driver change in PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917.
  3. Possible fix: This failure is not caused by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (audio codec sysclk configuration). The PR should not be blocked by this pre-existing platform issue. To resolve the underlying issue, add iommus properties to the USB PHY (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) device tree nodes in the hamoa-evk DTS, or update the test to exclude these non-critical devices from mandatory IOMMU protection checks.
  4. Detail analysis attachment: failed_case_job207917_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel issue. To enable KVM on Hamoa IoT EVK, the firmware/bootloader must be updated to boot the kernel at EL2 or provide EL2 access via VHE (Virtualization Host Extensions). If EL2 is intentionally disabled for this platform, mark the KVM tests as "skip" or "not applicable" in the LAVA job definition for Hamoa targets by adding a platform-specific test filter. The PR (audio codec sysclk configuration) is unrelated and does not cause this failure.
  4. Detail analysis attachment: failed_case_job207917_3_detailed.md
  Case 4: ** KVM_EL2_DTB (Platform Limitation - HYP Mode Not Available)
  1. Failed case: ** KVM_EL2_DTB (Platform Limitation - HYP Mode Not Available)
  2. Root cause: ** The Hamoa IoT EVK platform does not provide EL2 (Hypervisor) mode support to the kernel. KVM initialization fails with "HYP mode not available" because the ARM SoC on this platform either lacks virtualization extensions or the firmware does not expose EL2 to the kernel. This is a platform architectural limitation, not a software bug.
  3. Possible fix: This is expected behavior for the Hamoa IoT EVK platform. To resolve: (1) Mark KVM tests as "skip" or "not applicable" for hamoa-evk in the LAVA test suite configuration, OR (2) If KVM support is required, verify with the hardware team whether the SoC supports virtualization extensions and whether the bootloader/firmware can be configured to expose EL2 to the kernel. If the SoC fundamentally lacks virtualization support, KVM cannot be enabled on this platform.
  4. Detail analysis attachment: failed_case_job207917_4_detailed.md
  Case 5: KVM_Infra — Test Infrastructure / Platform Capability Mismatch
  1. Failed case: KVM_Infra — Test Infrastructure / Platform Capability Mismatch
  2. Root cause: The hamoa-evk platform does not support EL2 (ARM hypervisor mode), which is required for KVM. The kernel correctly detects this at boot ("kvm [1]: HYP mode not available") and does not create /dev/kvm. The test expects KVM to be available but the platform firmware/bootloader does not enable EL2.
  3. Possible fix: Remove KVM tests from the hamoa-evk test suite, or configure the platform firmware/bootloader to boot with EL2 enabled if the hardware supports it. This is not a kernel issue and is unrelated to the PR (ASoC audio fix).
  4. Detail analysis attachment: failed_case_job207917_5_detailed.md
  Case 6: ** Watchdog Hard Lockup False Positive — qcom_hwrng test
  1. Failed case: ** Watchdog Hard Lockup False Positive — qcom_hwrng test
  2. Root cause: ** SBSA Generic Watchdog detected CPU7 idle for >10s during qcom_hwrng intensive entropy generation test, triggering false positive hard lockup detection. CPU7 was in legitimate idle state (cpuidle_enter_state), not stuck. Test completed successfully after watchdog event.
  3. Possible fix: Increase watchdog timeout from 10s to 30s for hamoa-evk in device tree or kernel config to accommodate intensive single-threaded workloads like qcom_hwrng. Alternatively, suppress watchdog hard lockup detection during known-intensive test phases, or tune qcom_hwrng test to periodically wake idle CPUs.
  4. Detail analysis attachment: failed_case_job207917_6_detailed.md
Job 207918 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Suppress this test failure for purwa-evk as these are known board-specific probe failures that do not impact system functionality (all critical subsystems operational: remoteproc, SMMU, USB, WiFi, BT, audio). If probe failures must be addressed: (1) qcom_qseecom: verify TZ firmware compatibility; (2) qcom-spmi-lpg: audit PWM DT node against hardware; (3) qcom-pcie: confirm PCIe slots unpopulated on this board variant; (4) regulatory.db: add to rootfs or suppress (WiFi functional without it).
  4. Detail analysis attachment: failed_case_job207918_1_detailed.md
  Case 2: ** smmu (test validation failure — not a kernel crash)
  1. Failed case: ** smmu (test validation failure — not a kernel crash)
  2. Root cause: ** Six platform devices on purwa-evk lack iommus properties in their device tree nodes: five USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec (aa00000.video-codec). The SMMU test script flags these as critical masters without IOMMU group attachment. SMMU hardware is functioning correctly (35 devices attached, no SMMU errors), but the test fails due to incomplete device tree IOMMU bindings for this platform.
  3. Possible fix: Add iommus properties to the six missing device tree nodes in arch/arm64/boot/dts/qcom/purwa.dtsi (or the appropriate purwa-evk device tree file), referencing the correct SMMU phandle and stream IDs. Example for USB PHY: iommus = <&apps_smmu 0xXXX 0x0>; where 0xXXX is the correct stream ID for each device. Verify stream ID assignments from hardware documentation or existing working platforms. After applying the fix, rebuild the DTB, reflash, and re-run the SMMU test to confirm all critical masters are now attached.
  4. Detail analysis attachment: failed_case_job207918_2_detailed.md
  Case 3: KVM_Driver (Test Environment Configuration Issue)
  1. Failed case: KVM_Driver (Test Environment Configuration Issue)
  2. Root cause: KVM cannot initialize on Purwa IoT EVK because the Gunyah hypervisor is already running at EL2 (log evidence: "kvm [1]: HYP mode not available" and "Hypervisor cold boot, version: gunyah-mobile-c487961e9"). KVM requires exclusive EL2 access, which is already claimed by Gunyah. This is a platform configuration issue, not a kernel regression.
  3. Possible fix: Exclude KVM tests from the Purwa IoT EVK test suite, as this platform is configured to run Gunyah hypervisor and cannot support KVM simultaneously. Alternatively, if KVM testing is required, configure the platform to boot without Gunyah hypervisor (requires bootloader/firmware changes).
  4. Detail analysis attachment: failed_case_job207918_3_detailed.md
  Case 4: KVM_EL2_DTB — KVM unavailable (platform limitation)
  1. Failed case: KVM_EL2_DTB — KVM unavailable (platform limitation)
  2. Root cause: The purwa-evk platform does not support ARM Virtualization Extensions (HYP/EL2 mode). The kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running at EL2 or the hypervisor is not enabled, preventing /dev/kvm creation. This is a pre-existing platform limitation, not introduced by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies ASoC codec configuration for QCS615).
  3. Possible fix: This is not a bug requiring a fix. The KVM tests should be skipped on platforms without virtualization support. Add platform capability detection to the LAVA test suite to skip KVM tests on purwa-evk and other non-virtualization-capable boards, or update the test job definition to exclude KVM tests for this SoC.
  4. Detail analysis attachment: failed_case_job207918_4_detailed.md
  Case 5: KVM Infrastructure Test Failure — Platform Limitation
  1. Failed case: KVM Infrastructure Test Failure — Platform Limitation
  2. Root cause: The purwa-evk platform runs under the Gunyah hypervisor (gunyah-mobile-c487961e9) which occupies EL2 (HYP mode). KVM requires exclusive access to EL2 to function, but this is architecturally impossible when a Type-1 hypervisor is already running at EL2. The kernel correctly reports "kvm [1]: HYP mode not available" and does not create /dev/kvm. This is expected behavior, not a regression.
  3. Possible fix: Exclude KVM tests from the purwa-evk test suite, as this platform architecture (Gunyah hypervisor at EL2) is fundamentally incompatible with KVM. Alternatively, add a pre-flight check to skip KVM tests when running under a hypervisor (detect via /sys/hypervisor or hypervisor-specific device tree nodes).
  4. Detail analysis attachment: failed_case_job207918_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Platform does not support EL2/HYP mode — kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
  3. Possible fix: This is a hardware/platform limitation of the purwa-evk board, not a kernel regression. The test should be skipped on platforms without virtualization extensions, or the test suite should check for HYP mode availability before running KVM tests. No kernel fix required — this is expected behavior on non-virtualization-capable hardware.
  4. Detail analysis attachment: failed_case_job207918_6_detailed.md
Job 207919 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test infrastructure flagging pre-existing, non-critical probe issues as failures: (1) four PMIC temp-alarm devices in deferred probe state (normal kernel behavior when dependencies unavailable), (2) missing regulatory.db firmware file (known benign — wireless works with built-in rules), (3) Aquantia Ethernet PHY probe failure due to missing DT firmware-name property (pre-existing qcs9100-ride platform configuration issue). None are related to the PR's audio codec sysclk change for QCS615.
  3. Possible fix: Mark this test case as expected-fail or update the Probe_Failure_Check test to exclude known benign patterns: deferred probe for non-critical thermal devices, regulatory.db firmware absence (when cfg80211 continues), and pre-existing platform-specific PHY configuration issues. The PR itself requires no changes.
  4. Detail analysis attachment: failed_case_job207919_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Video codec device aa00000.video-codec at address 0xaa00000 is not attached to any IOMMU group on qcs9100-ride (SA8775P SoC), indicating missing or incorrect iommus property in the device tree node for this critical DMA master.
  3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/sa8775p.dtsi or the board-specific qcs9100-ride DTS file, referencing the appropriate APPS SMMU phandle and stream ID for the video codec hardware block.
  4. Detail analysis attachment: failed_case_job207919_2_detailed.md
  Case 3: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure issue — no physical USB device connected to the qcs9100-ride board; only USB root hubs (Bus 001, 002, 003) are enumerated, indicating USB host controllers are functional but no external USB devices are present in the test environment.
  3. Possible fix: This is not a kernel regression. The USBHost test requires a physical USB device (e.g., USB flash drive, keyboard, or mouse) to be connected to one of the board's USB ports. Either: (1) connect a USB device to the board before running the test, or (2) mark this test as "skip" for boards without USB peripherals in the LAVA lab, or (3) update the test to distinguish between "USB host controller not working" (genuine failure) vs "no USB device connected" (infrastructure/environment issue).
  4. Detail analysis attachment: failed_case_job207919_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test definition marked as failed due to 3 genuine sub-test failures (Probe_Failure_Check, smmu, USBHost) that are unrelated to the PR changes (audio codec configuration for QCS615 tested on qcs9100-ride platform).
  3. Possible fix: The test definition failure is expected behavior when sub-tests fail. The 3 sub-test failures appear to be pre-existing platform issues on qcs9100-ride: (1) Probe_Failure_Check detected regulatory.db firmware load failure and Aquantia AQR115C Ethernet PHY probe failure, (2) smmu test detected IOMMU-related log entries, (3) USBHost test failed because no functional USB devices were connected (only hubs detected). These failures are not introduced by the PR's audio codec changes for QCS615. Re-run the test on QCS615 hardware to validate the actual PR changes, or accept these qcs9100-ride platform-specific failures as pre-existing issues.
  4. Detail analysis attachment: failed_case_job207919_4_detailed.md
Job 207920 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Update the Probe_Failure_Check test to exclude known-benign firmware load failures where functional tests pass. Specifically, suppress regulatory.db load failures when WiFi_OnOff or WiFi_Firmware_Driver tests pass. Alternatively, add regulatory.db to the rootfs firmware directory to eliminate the message.
  4. Detail analysis attachment: failed_case_job207920_1_detailed.md
  Case 2: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** Test infrastructure issue — no physical USB device connected to qcs8300-ride board's USB host port during test execution. The USB host controller (xHCI) initialized correctly and enumerated the root hub (Bus 001 Device 001: ID 1d6b:0002), but the test requires a functional USB device (keyboard, mouse, storage, etc.) to be physically connected to validate USB host functionality.
  3. Possible fix: This is not a kernel regression. The PR changes ASoC codec configuration for QCS615 (sound/soc/qcom/sc8280xp.c) and is unrelated to USB. To resolve: (1) Verify a USB device is physically connected to the qcs8300-ride board's USB host port in the LAVA lab, (2) If the board has no USB device connected by design, mark this test as SKIP for qcs8300-ride or update the test to check for USB controller presence only (not require a connected device), (3) Re-run the test with a USB device connected.
  4. Detail analysis attachment: failed_case_job207920_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: qcs8300-ride runs under Gunyah hypervisor (EL2 already occupied); Linux guest at EL1 cannot initialize KVM, so /dev/kvm device node is never created despite CONFIG_KVM=y and CONFIG_VIRTUALIZATION=y being enabled.
  3. Possible fix: Skip KVM tests on qcs8300-ride in the LAVA job definition, or run these tests only on bare-metal (non-virtualized) targets where Linux has EL2 access. This is a platform limitation, not a kernel bug.
  4. Detail analysis attachment: failed_case_job207920_3_detailed.md
  Case 4: KVM_EL2_DTB — KVM device node unavailable (nested virtualization not supported)
  1. Failed case: KVM_EL2_DTB — KVM device node unavailable (nested virtualization not supported)
  2. Root cause: The qcs8300-ride target is running as a guest VM under the Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-1cb9db980" and "Gunyah based bootup" in boot log). KVM requires EL2 hypervisor privileges to initialize and create /dev/kvm, but when running as a guest VM the kernel executes at EL1 and cannot access EL2. Nested virtualization (KVM-inside-VM) is not supported on this Gunyah-based platform configuration.
  3. Possible fix: Skip KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on qcs8300-ride targets that boot under Gunyah hypervisor, or reconfigure the LAVA job to flash a bare-metal (non-VM) image where the kernel runs at EL2 and can initialize KVM. To identify Gunyah-based boots programmatically, check for "Gunyah based bootup" in early boot messages or the presence of the gunyah-md-region reserved memory node.
  4. Detail analysis attachment: failed_case_job207920_4_detailed.md
  Case 5: KVM_Infra — Pre-existing Platform Limitation (Not PR-Introduced)
  1. Failed case: KVM_Infra — Pre-existing Platform Limitation (Not PR-Introduced)
  2. Root cause: QCS8300 Ride platform runs Gunyah hypervisor at EL2, which prevents KVM from initializing. CONFIG_KVM is enabled but KVM cannot create /dev/kvm because Gunyah already occupies the EL2 exception level required for KVM operation. Boot log shows "Hypervisor cold boot, version: gunyah-1cb9db980" confirming Gunyah is active.
  3. Possible fix: This is not a regression introduced by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (ASoC audio codec change). The KVM tests should be excluded from the QCS8300 test suite, or the test framework should skip KVM tests when a non-KVM hypervisor is detected at boot. To enable KVM on this platform, the firmware/boot configuration would need to be changed to not load Gunyah, which is a platform-level decision outside the scope of kernel patches.
  4. Detail analysis attachment: failed_case_job207920_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: /dev/kvm device node not created during boot on QCS8300 Ride platform despite CONFIG_KVM=y; KVM driver did not initialize, indicating platform does not support virtualization or lacks required hardware/firmware support for KVM on this SoC.
  3. Possible fix: This is a pre-existing platform limitation unrelated to the PR (which only modifies audio codec driver). If KVM support is required on QCS8300, investigate: (1) whether the SoC supports EL2/hypervisor mode, (2) check for missing kernel configs (CONFIG_HAVE_KVM_IRQFD, CONFIG_KVM_ARM_PMU), (3) verify device tree includes required hypervisor nodes, (4) check if firmware/bootloader enables EL2. For PR validation purposes, suppress KVM tests on QCS8300 or mark as expected-fail for this platform.
  4. Detail analysis attachment: failed_case_job207920_6_detailed.md
Job 207921 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs /lib/firmware/ directory, or correct the board-specific firmware path in the device tree or driver board data to match the available firmware variant. Verify the WCN6855 board variant identifier (nfa765) is correct for Monaco EVK; if not, update the DT or driver to use the standard board file path. For Bluetooth and regulatory database, add the missing firmware files or verify fallback mechanisms are intentional.
  4. Detail analysis attachment: failed_case_job207921_1_detailed.md
  Case 2: WiFi_Firmware_Driver
  1. Failed case: WiFi_Firmware_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the missing WCN6855 WiFi firmware files to the Monaco EVK rootfs image under /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/. The firmware package should include at minimum amss.bin, m3.bin, and regdb.bin. Verify firmware is present before running WiFi tests, or mark WiFi tests as expected-fail for Monaco until firmware is provisioned.
  4. Detail analysis attachment: failed_case_job207921_2_detailed.md
  Case 3: WiFi_OnOff — ath11k_pci driver probe failure
  1. Failed case: WiFi_OnOff — ath11k_pci driver probe failure
  2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image, causing MHI (Modem Host Interface) initialization to fail during the power-up sequence on Monaco EVK.
  3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image build recipe (Yocto/meta-qcom layer) for Monaco EVK; this is a pre-existing infrastructure/image packaging issue unrelated to PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies audio codec configuration for QCS615).
  4. Detail analysis attachment: failed_case_job207921_3_detailed.md
  Case 4: ** 0_qcom-next-ci-premerge-tests
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) on monaco-evk due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin. This is a pre-existing infrastructure/firmware packaging issue, not a regression introduced by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies ASoC audio codec configuration for QCS615).
  3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image used for monaco-evk LAVA jobs. Verify the firmware path matches the driver's request. This is an infrastructure fix; the PR code change is unrelated and should not be blocked by this failure.
  4. Detail analysis attachment: failed_case_job207921_4_detailed.md
Job 207922 | SoC qcs615-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
  1. Failed case: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
  2. Root cause: Kernel panic triggered by synchronous external abort during SWIOTLB bounce buffer memory copy operation in USB device enumeration path. The crash occurred at __pi_memcpy_generic+0x2c while copying data from physical address 0xffff00008e379840 to SWIOTLB bounce buffer 0xffff00007febf000 during USB hub event processing (kworker/3:1, PID 92). The external abort indicates a bus-level fault accessing the source physical memory region, suggesting either invalid/unmapped physical address, IOMMU/SMMU misconfiguration for the USB controller DMA context, or hardware-level memory access violation on qcs615-ride platform.
  3. Possible fix: This is NOT a PR-introduced regression. The PR modifies only ASoC codec sysclk configuration (sound/soc/qcom/sc8280xp.c) and has no code path interaction with USB, DMA, SWIOTLB, or IOMMU subsystems. The crash is a pre-existing platform issue specific to qcs615-ride USB/DMA configuration. Recommended action: (1) Verify USB controller IOMMU domain configuration in qcs615-ride device tree — confirm iommus property and stream-id mappings are correct for the xHCI controller at 0xa800000. (2) Check SWIOTLB buffer allocation and physical address validity — enable swiotlb=force,verbose kernel command line and collect full boot log to trace SWIOTLB buffer setup. (3) Verify USB controller power/clock sequencing — the crash occurs during first USB device enumeration, suggesting potential race between controller initialization and DMA setup. (4) Re-run the LAVA job on a known-good baseline kernel (without this PR) to confirm the issue reproduces independently of the PR changes.
  4. Detail analysis attachment: failed_case_job207922_1_detailed.md
  Case 2: Kernel Crash — Synchronous External Abort during USB DMA
  1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA
  2. Root cause: Synchronous external abort at 8 seconds into boot during USB low-speed device enumeration. The crash occurred in __pi_memcpy_generic while copying data to a SWIOTLB bounce buffer (FAR=0xffff00007febf000) during usb_hcd_map_urb_for_dma. This indicates a hardware-level bus fault when the CPU attempted to access the bounce buffer physical address, suggesting either: (1) the SWIOTLB bounce buffer was allocated from an invalid/inaccessible physical memory region on qcs615-ride, (2) a platform-specific memory aperture or IOMMU configuration issue preventing access to the bounce buffer region, or (3) a hardware/firmware issue with the memory controller or interconnect on this specific board.
  3. Possible fix: This is a pre-existing platform/infra issue unrelated to PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies ASoC codec sysclk configuration). The crash is reproducible on qcs615-ride during USB device enumeration and indicates a board-level or kernel memory configuration problem. Recommended actions: (1) Check qcs615-ride DT memory reservations and SWIOTLB configuration — verify bounce buffer pool is allocated from accessible DRAM; (2) Compare with known-good qcs615-ride boot logs to confirm if USB enumeration previously worked; (3) Test with swiotlb=force or swiotlb=noforce kernel parameters to isolate SWIOTLB allocation; (4) If this is a new regression on qcs615-ride, bisect kernel changes affecting SWIOTLB, DMA, or qcs615 memory map; (5) Verify board firmware/bootloader version matches reference configuration.
  4. Detail analysis attachment: failed_case_job207922_2_detailed.md
  Case 3: Kernel Crash — Synchronous External Abort during USB DMA Mapping
  1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA Mapping
  2. Root cause: Synchronous external abort (bus error) during SWIOTLB bounce buffer copy from physical address 0x10e379840 (>4GB) during USB XHCI low-speed device enumeration. The USB controller attempted DMA to/from high memory requiring SWIOTLB bounce buffering, but the physical address access failed, indicating either invalid physical address, memory not mapped, or platform DMA addressing constraint violation on QCS615.
  3. Possible fix: This is a pre-existing kernel issue unrelated to the PR (audio codec configuration change). Recommended actions: (1) Verify USB XHCI DMA mask configuration for QCS615 in device tree and driver; (2) Check SWIOTLB size and allocation constraints; (3) Verify memory map and reserved regions for QCS615; (4) Test with swiotlb=force or increased SWIOTLB size; (5) Check if USB buffers should be allocated from DMA32 zone; (6) Bisect kernel versions to identify when this regression was introduced.
  4. Detail analysis attachment: failed_case_job207922_3_detailed.md
  Case 4: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
  1. Failed case: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
  2. Root cause: Hardware memory access fault during USB device enumeration when copying data to SWIOTLB bounce buffer at physical address 0x10e379840. The synchronous external abort (ESR 0x96000010) indicates the CPU attempted to access an invalid or unmapped physical address during DMA bounce buffer setup for a low-speed USB device (device number 2) on the xHCI controller.
  3. Possible fix: This is a pre-existing hardware/platform issue unrelated to PR917 (audio codec patch). Investigate: (1) IOMMU/SMMU configuration for the xHCI controller at 0xa800000 on qcs615-ride, (2) SWIOTLB buffer allocation and physical address validity, (3) USB controller DMA constraints and bounce buffer requirements. Short-term: re-trigger the CI job to confirm reproducibility; if intermittent, this may be a hardware/board-specific fault on the qcs615-ride test device.
  4. Detail analysis attachment: failed_case_job207922_4_detailed.md
Job 207923 | SoC shikra-iqs-evk

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

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

  Case 1: GIC
  1. Failed case: GIC
  2. Root cause: Test script bug — the GIC test script hardcodes an assumption of 8 CPUs (0-7) but shikra-iqs-evk has only 4 CPUs (0-3); when the script attempts to parse /proc/interrupts column 5 (CPU 4) at line 75, it encounters the string "GICv3" (interrupt controller name) instead of a numeric interrupt count, causing bash integer comparison to fail with "integer expected" error.
  3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online and only validate timer interrupt counts for CPUs that actually exist on the target platform; the script should parse /proc/interrupts by counting fields rather than assuming a fixed 8-CPU topology.
  4. Detail analysis attachment: failed_case_job207923_1_detailed.md
  Case 2: ** Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)
  1. Failed case: ** Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)
  2. Root cause: ** The Probe_Failure_Check test detected six probe/firmware failures on shikra-iqs-evk, all of which are pre-existing platform/infrastructure issues unrelated to the PR changes. The PR modifies only sound/soc/qcom/sc8280xp.c to enable codec_sysclk_set for QCS615, but the failures affect unrelated subsystems: coresight-etm4x (debug tracing, -EINVAL due to missing DT resources), cpufreq-dt (-EEXIST, already registered by qcom-cpufreq-hw), regulatory.db firmware (-ENOENT, missing file in rootfs), and deferred probe for sound/va_macro/ath10k_snoc (missing clock/regulator dependencies). None of these failures are caused by or related to the audio codec sysclk configuration change in the PR.
  3. Possible fix: Mark this test case as PASS (failures are pre-existing platform issues, not PR regressions). The coresight-etm4x failures require DT fixes for ETM device nodes on shikra; cpufreq-dt failure is benign (qcom-cpufreq-hw already provides cpufreq); regulatory.db should be added to rootfs or suppressed; deferred probe warnings are expected transient states that resolve later in boot. None require action on this PR.
  4. Detail analysis attachment: failed_case_job207923_2_detailed.md
  Case 3: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** The Shikra IQS EVK kernel build does not include the USB host controller driver (dwc3/xhci-hcd). USB core subsystem and USB PHY drivers are present and initialized successfully, but without the USB host controller driver, no USB devices can be enumerated. This is a kernel configuration issue specific to the Shikra IQS EVK build, not a code regression introduced by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which modifies only ASoC audio code for QCS615).
  3. Possible fix: Enable USB host controller drivers in the kernel configuration for Shikra IQS EVK: CONFIG_USB_DWC3=y, CONFIG_USB_DWC3_QCOM=y, CONFIG_USB_XHCI_HCD=y, CONFIG_USB_XHCI_PLATFORM=y. Rebuild the kernel and verify dwc3/xhci-hcd probe messages appear in dmesg. Until fixed, mark USBHost test as SKIP for this platform. Do NOT block PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 based on this failure.
  4. Detail analysis attachment: failed_case_job207923_3_detailed.md
  Case 4: BT_SCAN
  1. Failed case: BT_SCAN
  2. Root cause: Bluetooth scan test failed to discover any devices after 3 attempts (15s each) and interactive fallback, despite hci0 adapter being powered and functional (BT_ON_OFF passed), indicating no scannable Bluetooth devices were present in the LAVA lab environment during test execution on shikra-iqs-evk.
  3. Possible fix: This is an environmental/infrastructure issue, not a kernel regression. The PR changes (ASoC codec sysclk configuration for QCS615) do not affect Bluetooth functionality. Recommended actions: (1) Verify external Bluetooth beacon/device availability in the LAVA lab for shikra-iqs-evk; (2) Re-trigger the CI job when BT test infrastructure is available; (3) Consider marking BT_SCAN as non-blocking for PRs that don't touch Bluetooth subsystem code.
  4. Detail analysis attachment: failed_case_job207923_4_detailed.md
  Case 5: KVM_Driver — Platform Hardware Limitation (HYP Mode Unavailable)
  1. Failed case: KVM_Driver — Platform Hardware Limitation (HYP Mode Unavailable)
  2. Root cause: KVM driver initialization failed because the Shikra IQS EVK platform does not support ARM Hypervisor (HYP/EL2) mode, which is a mandatory hardware prerequisite for KVM virtualization. Boot log shows "kvm [1]: HYP mode not available" at [3.302617]. CONFIG_KVM is enabled in kernel config, but the hardware/firmware does not provide EL2 capability.
  3. Possible fix: This is not a kernel bug or PR-introduced regression. The test failure is expected on platforms without EL2 support. Recommended action: Update the LAVA test suite to skip KVM tests on platforms that do not advertise EL2 capability (check /sys/hypervisor/type or parse dmesg for "HYP mode not available" before running KVM tests), or exclude Shikra IQS EVK from the KVM test matrix if EL2 is not supported by its firmware/bootloader configuration.
  4. Detail analysis attachment: failed_case_job207923_5_detailed.md
  Case 6: KVM_EL2_DTB — /dev/kvm not available (consequence of prior kernel crash)
  1. Failed case: KVM_EL2_DTB — /dev/kvm not available (consequence of prior kernel crash)
  2. Root cause: System rebooted after a kernel crash (synchronous external abort in qcom_rng driver during qcom_hwrng test at ~770s uptime). The crash occurred when reading from /dev/hwrng, triggering a bus error in qcom_rng_read+0xc4. After reboot, KVM tests ran but failed because /dev/kvm was not present. The crash is unrelated to PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (audio codec change for QCS615).
  3. Possible fix: The KVM_EL2_DTB failure is a false positive caused by pre-existing qcom_rng driver instability on shikra-iqs-evk. The PR changes (sound/soc/qcom/sc8280xp.c) do not touch qcom_rng or KVM code. Recommended actions: (1) Re-run the CI job to verify if qcom_rng crash reproduces; (2) If crash persists, investigate qcom_rng hardware access issue on shikra-iqs-evk (possible clock/power/MMIO mapping problem); (3) Consider disabling qcom_hwrng test on shikra-iqs-evk until root cause is fixed, as it blocks downstream tests.
  4. Detail analysis attachment: failed_case_job207923_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: The KVM_Infra test failed because /dev/kvm device node is not present on the Shikra IQS EVK platform, indicating KVM is not functional despite CONFIG_KVM being enabled in the kernel configuration. This is a pre-existing platform limitation unrelated to the PR (which modifies only ASoC sound driver code for QCS615).
  3. Possible fix: This is not a PR-introduced regression. The KVM_Infra test failure is expected on Shikra IQS EVK as the platform does not support KVM virtualization (no /dev/kvm device created). The test should either be skipped for this platform or the platform's KVM support should be investigated separately. The subsequent kernel crash in qcom_hwrng is a separate, unrelated hardware issue (synchronous external abort during RNG hardware register access) that also predates this PR.
  4. Detail analysis attachment: failed_case_job207923_7_detailed.md
  Case 8: Kernel Crash — synchronous external abort in qcom_rng driver
  1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
  2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware fault) at qcom_rng_read+0xc4 when reading from the hardware RNG device. The crash occurred during a dd read from /dev/hwrng, indicating a hardware access fault (likely MMIO read from an unmapped/unpowered/clock-gated RNG peripheral). The system then panicked, and during panic handling, EFI pstore attempted to write crash logs but encountered repeated EFI runtime service paging faults, cascading into a fatal exception. This is a pre-existing platform/firmware issue on shikra-iqs-evk, not introduced by the PR (which only modifies ASoC codec configuration for QCS615).
  3. Possible fix: This is a known hardware/firmware issue on the shikra-iqs-evk platform. The qcom_rng driver is attempting to access RNG hardware that is either not properly initialized, not powered, or has incorrect MMIO mappings in the device tree for this SoC. Additionally, the EFI pstore backend is broken (firmware bug). Recommended actions: (1) Disable the qcom_hwrng test for shikra-iqs-evk until the platform firmware and device tree are fixed. (2) Add efi=noruntime to the kernel command line to prevent EFI runtime service crashes during panic. (3) Investigate why the RNG hardware is not accessible — check device tree MMIO ranges, power domains, and clock configuration for the RNG device on shikra (QCM2290 SoC).
  4. Detail analysis attachment: failed_case_job207923_8_detailed.md
  Case 9: ** Kernel Crash — Synchronous External Abort in qcom_rng Driver
  1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng Driver
  2. Root cause: ** The qcom_rng driver crashed with a synchronous external abort (hardware access fault) at offset +0xc4 in qcom_rng_read() while servicing a read from /dev/hwrng during the qcom_hwrng test. The fault indicates the driver attempted to access a hardware register that was either unpowered, unmapped, or not present on the shikra-iqs-evk platform. This is a pre-existing platform/driver issue unrelated to the PR's audio codec changes.
  3. Possible fix: Investigate the qcom_rng driver's hardware register access at the faulting offset (+0xc4 in qcom_rng_read). Verify that the RNG hardware block is correctly clocked, powered, and mapped in the shikra-iqs-evk device tree. If the hardware is not present or not functional on this platform, disable the qcom_hwrng test for shikra-iqs-evk or mark the driver as incompatible with this SoC variant. Additionally, configure ramdump collection (add reboot=panic_warm qcom_scm.download_mode=1 to kernel cmdline and ensure TCSR DT node is present) to capture full crash dumps for future debugging.
  4. Detail analysis attachment: failed_case_job207923_9_detailed.md
  Case 10: Kernel Crash — synchronous external abort in qcom_rng driver
  1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
  2. Root cause: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read+0xc4/0x228 during HWRNG test execution on shikra-iqs-evk. The qcom_rng driver attempted to read from an MMIO register that triggered a bus-level external abort, indicating the RNG hardware block is either not powered, not clocked, inaccessible due to security policy, or the register mapping is incorrect for this SoC variant.
  3. Possible fix: This is a pre-existing platform/firmware issue, not introduced by PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 (which only modifies audio codec configuration for QCS615). Immediate mitigation: Skip the qcom_hwrng test on shikra-iqs-evk until the RNG hardware access issue is resolved. Proper fix: Investigate shikra (QCS9100) device tree RNG node configuration, verify RNG clock/power domain dependencies are met, confirm firmware/TZ allows non-secure RNG access, and validate the MMIO register base address matches the SoC datasheet.
  4. Detail analysis attachment: failed_case_job207923_10_detailed.md
  Case 11: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read() at offset +0xc4 while reading from HWRNG device registers during qcom_hwrng test execution on shikra-iqs-evk; the abort indicates an invalid physical address access or bus error when the driver attempted to read RNG data registers.
  3. Possible fix: This is a pre-existing hardware/driver/firmware issue unrelated to the PR (which only modifies ASoC codec sysclk configuration for QCS615). The qcom_rng driver is attempting to access HWRNG registers that are either not mapped correctly in the device tree for shikra-iqs-evk, not powered/clocked, or the hardware block is not functional on this board revision. Immediate mitigation: disable the qcom_hwrng test for shikra-iqs-evk in the CI test suite. Proper fix: investigate shikra-iqs-evk device tree HWRNG node (reg property, clocks, power-domains) and verify hardware block availability; if the HWRNG block is not present or non-functional on this SoC/board variant, mark the driver as disabled in the device tree (status = "disabled").
  4. Detail analysis attachment: failed_case_job207923_11_detailed.md
Job 207924 | SoC qcs6490-rb3gen2

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Two pre-existing firmware load failures detected during boot: (1) cfg80211 regulatory database (regulatory.db) missing from firmware search path (error -ENOENT), and (2) Renesas xHCI USB controller firmware (renesas_usb_fw.mem) missing from firmware search path (error -ENOENT). Both failures are infrastructure/image configuration issues unrelated to the PR under test (PR FROMLIST: ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 #917 modifies only ASoC codec sysclk configuration for QCS615). The Probe_Failure_Check test flags any probe/firmware errors as failures, but these specific errors do not impact core system functionality on qcs6490-rb3gen2 — WiFi regulatory enforcement operates with built-in fallback rules, and the Renesas USB controller is an optional PCIe add-in card not required for board operation.
  3. Possible fix: Add the missing firmware files to the root filesystem image: (1) install wireless-regdb package or copy regulatory.db and regulatory.db.p7s to /lib/firmware/, and (2) install linux-firmware package or copy renesas_usb_fw.mem to /lib/firmware/. If these devices are not used on this platform, suppress the Probe_Failure_Check test's firmware-related error patterns for known-optional hardware (regulatory.db, renesas_usb_fw.mem) to reduce CI noise. The PR itself is not the cause and does not require changes.
  4. Detail analysis attachment: failed_case_job207924_1_detailed.md
  Case 2: ** Driver Probe Failure — USB Host Controller (Renesas xHCI)
  1. Failed case: ** Driver Probe Failure — USB Host Controller (Renesas xHCI)
  2. Root cause: ** The Renesas PCIe xHCI USB host controller (0001:04:00.0) failed to probe because the required firmware file renesas_usb_fw.mem is missing from the rootfs (-ENOENT, error -2). The qcs6490-rb3gen2 board relies on this PCIe-attached USB host controller for external USB device enumeration; the on-SoC USB controllers (8c00000.usb, a600000.usb) are configured for device/gadget mode, not host mode.
  3. Possible fix: Add the Renesas USB firmware package (linux-firmware-renesas or equivalent) to the Yocto image recipe for rb3gen2-core-kit. The firmware file renesas_usb_fw.mem must be installed to /lib/firmware/ in the rootfs. Rebuild the image and reflash to enable USB host functionality.
  4. Detail analysis attachment: failed_case_job207924_2_detailed.md
  Case 3: KVM_Driver — /dev/kvm device node not present
  1. Failed case: KVM_Driver — /dev/kvm device node not present
  2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the Gunyah hypervisor is already running in EL2 (HYP mode), preventing KVM from accessing the required privilege level. The kernel message "kvm [1]: HYP mode not available" at boot confirms that KVM detected the hypervisor and aborted initialization. This is a platform configuration issue, not a PR-introduced regression (the PR modifies only ASoC audio driver code).
  3. Possible fix: This is expected behavior on Gunyah-enabled platforms. The KVM_Driver test should be skipped on boards running Gunyah hypervisor. Add a test gate to check for Gunyah presence (e.g., grep "Gunyah based bootup" in dmesg) and skip KVM tests when detected, or exclude qcs6490-rb3gen2 from the KVM test matrix in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job207924_3_detailed.md
  Case 4: KVM_EL2_DTB — /dev/kvm not available (pre-existing platform limitation)
  1. Failed case: KVM_EL2_DTB — /dev/kvm not available (pre-existing platform limitation)
  2. Root cause: qcs6490-rb3gen2 (Kodiak) is running under Gunyah hypervisor in non-nested virtualization mode; kernel KVM driver detects "HYP mode not available" at boot and does not create /dev/kvm device node, causing all KVM-dependent tests to fail.
  3. Possible fix: This is not a PR-introduced regression. The PR modifies only audio codec configuration (sound/soc/qcom/sc8280xp.c) and has no impact on KVM/virtualization. The failure is a pre-existing platform configuration issue: qcs6490-rb3gen2 does not support nested virtualization under Gunyah. To resolve: (1) suppress KVM tests on this platform in CI job definitions, or (2) use a different test platform that supports nested virtualization, or (3) configure the hypervisor to expose EL2 to the guest kernel if hardware and firmware support it.
  4. Detail analysis attachment: failed_case_job207924_4_detailed.md
  Case 5: KVM Infrastructure Test — Platform Limitation (EL2 Not Available)
  1. Failed case: KVM Infrastructure Test — Platform Limitation (EL2 Not Available)
  2. Root cause: qcs6490-rb3gen2 platform does not support or enable EL2 (hypervisor mode). KVM driver initialization fails with "HYP mode not available" because the platform firmware/bootloader boots Linux directly at EL1 without hypervisor support. This is a platform configuration limitation, not a kernel regression.
  3. Possible fix: Mark KVM tests as "not applicable" or "skip" for qcs6490-rb3gen2 platform in the LAVA test suite configuration. Alternatively, if EL2 support is required, update platform firmware/bootloader to enable hypervisor mode and boot with a hypervisor layer (e.g., Gunyah/hypvm.mbn in EL2).
  4. Detail analysis attachment: failed_case_job207924_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not support ARM Virtualization Extensions (HYP/EL2 mode). The kernel correctly detected this at boot time with message kvm [1]: HYP mode not available, causing /dev/kvm device node creation to be skipped. The test expects KVM infrastructure to be available but the hardware does not support it.
  3. Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test plan, or mark them as expected-skip for platforms without virtualization support. Add a platform capability check to the test suite to skip KVM tests when CONFIG_KVM=y but HYP mode is unavailable.
  4. Detail analysis attachment: failed_case_job207924_6_detailed.md

sgaud-quic
Salendarsingh Gaud (sgaud-quic) requested changes Aug 30, 2026
View reviewed changes

@sgaud-quic Salendarsingh Gaud (sgaud-quic) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Mainline PR is not yet merged :
qualcomm-linux/kernel-topics#1657

@QTI-Quill

QTI-Quill commented Sep 2, 2026

Copy link
Copy Markdown
Author

Mainline PR is not yet merged : qualcomm-linux/kernel-topics#1657

Can we merge this first since it's QLI2.0 critical fix change? Also Can you please approve mainline PR and merge it also? Thanks

@sgaud-quic

Salendarsingh Gaud (sgaud-quic) commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Mainline PR is not yet merged : qualcomm-linux/kernel-topics#1657

Can we merge this first since it's QLI2.0 critical fix change? Also Can you please approve mainline PR and merge it also? Thanks

No, we have mainline first policy, first mainline PR needs to be merged.

@QTI-Quill QTI-Quill mentioned this pull request Sep 7, 2026
Open
@sgaud-quic
Salendarsingh Gaud (sgaud-quic) merged commit f1c641b into qualcomm-linux:qcom-6.18.y Sep 9, 2026
7 of 9 checks passed
mohsRafi pushed a commit to mohsRafi/kernel that referenced this pull request Sep 11, 2026
@sgaud-quic
ASoC: qcom: sc8280xp: configure codec sysclk for QCS615 (qualcomm-lin…
44a5e37 
…ux#917)

ASoC: qcom: sc8280xp: configure codec sysclk for QCS615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@quic-tingweiz Tingwei Zhang (quic-tingweiz) quic-tingweiz approved these changes
@sgaud-quic Salendarsingh Gaud (sgaud-quic) sgaud-quic approved these changes
@ndechesne Nicolas Dechesne (ndechesne) Awaiting requested review from ndechesne ndechesne was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@aiquny aiquny Awaiting requested review from aiquny aiquny was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@knaveen-qc knaveen-qc Awaiting requested review from knaveen-qc knaveen-qc was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@QTI-Quill @qcomlnxci @qlijarvis @sgaud-quic @quic-tingweiz