Video slice changes

[sachinku173]

Hi All,

Above series adds support for multi-slice encoding in the Qualcomm Iris
driver

Patch 1 is a prerequisite fix: iris_set_stage() computes a work_mode
but never caches it back into inst->fw_caps[STAGE].value, leaving
buffer-size and clock-frequency calculations based on a stale value.

Patch 2 is another prerequisite fix: iris_set_stage() currently always
selects STAGE_2 work mode for encoder sessions, but CBR rate control
requires STAGE_1. This is fixed by forcing STAGE_1 when BITRATE_MODE is
set to CBR.

Patch 3 adds the multi-slice support itself for Iris HFI Gen2 based
targets.

CRs-fixed: 4650099

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4650099 is not eligible for merge.

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

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

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

[qlijarvis]

PR #979 — validate-patch

PR: #979

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

1. Lore link present: Yes - all three commits have correct Link: tags pointing to v8 series on lore.kernel.org
2. Lore link matches PR commits: Yes - diff content is identical to lore v8 patches; commit messages faithfully preserve upstream rationale, Fixes tags, and review tags
3. Upstream patch status: ⏳ Decision Pending (superseded by v9) - v8 received Reviewed-by: tags from Vikash Garodia and Vishnu Reddy, but was superseded by v9 on August 1, 2026; no maintainer merge decision yet
4. PR present in qcom-next/topics: Yes - all 3 commit(s) are present in qcom-next or topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #979 - media: qcom: iris: add multi slice support (3 commits)
Upstream commits: v8 series on lore.kernel.org
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	✅	All three subjects match lore v8 (with FROMLIST: prefix added)
Body preserves rationale	✅	All commit bodies faithfully preserve upstream rationale
Fixes tag present/correct	✅	Commit 1/3 has correct Fixes tag matching upstream
Authorship preserved	✅	All commits preserve original author (Sachin Kumar Garg) - FROMLIST: allows submitter in From: field
Backport note (if applicable)	N/A	Not a backport - FROMLIST: prefix indicates pending upstream patch

Diff

File	Status	Notes
drivers/media/platform/qcom/iris/iris_ctrls.c (1/3)	✅	Identical to lore v8 patch 1 - adds cache update for work_mode
drivers/media/platform/qcom/iris/iris_ctrls.c (2/3)	✅	Identical to lore v8 patch 2 - forces STAGE_1 for CBR RC
drivers/media/platform/qcom/iris/iris_ctrls.c (3/3)	✅	Identical to lore v8 patch 3 - adds multi-slice support
drivers/media/platform/qcom/iris/iris_ctrls.h (3/3)	✅	Matches upstream
drivers/media/platform/qcom/iris/iris_hfi_gen2.c (3/3)	✅	Matches upstream
drivers/media/platform/qcom/iris/iris_hfi_gen2_defines.h (3/3)	✅	Matches upstream
drivers/media/platform/qcom/iris/iris_platform_common.h (3/3)	✅	Matches upstream
drivers/media/platform/qcom/iris/iris_platform_vpu2.c (3/3)	✅	Matches upstream

Issues

• Superseded revision: The PR links to v8 of the patch series (posted July 28, 2026), but a v9 revision was posted on August 1, 2026. The lore thread shows the series progressed from v7 → v8 → v9. While the v8 patches are technically correct, using a superseded revision may mean missing improvements or fixes from v9.

Verdict

The PR patches are faithful representations of the lore v8 series. All three commits match their upstream counterparts exactly in both commit message content and diff hunks. The FROMLIST: prefix is correctly applied, authorship is preserved, and the Link: tags point to the correct lore message-IDs.

However, the series was superseded by v9 three days after v8 was posted. Recommendation: Verify whether v9 contains material changes; if so, update the PR to track v9 instead of v8.

Final Summary

1. Lore link present: Yes - all three commits have correct Link: tags pointing to v8 series on lore.kernel.org
2. Lore link matches PR commits: Yes - diff content is identical to lore v8 patches; commit messages faithfully preserve upstream rationale, Fixes tags, and review tags
3. Upstream patch status: ⏳ Decision Pending (superseded by v9) - v8 received Reviewed-by: tags from Vikash Garodia and Vishnu Reddy, but was superseded by v9 on August 1, 2026; no maintainer merge decision yet
4. PR present in qcom-next/topics: Yes - all 3 commits are present in qcom-next (exact patch-id match for 1/3 and 2/3; content match for 3/3)

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: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/3	[PATCH 1/3] FROMLIST: media: iris: cache work mode after computing it	present - exact patch-id match at 3cf5e0e	skipped - not checked because qcom-next already contains the change	present
2/3	[PATCH 2/3] FROMLIST: media: iris: force stage 1 work mode for CBR RC	present - exact patch-id match at 5b81ed0	skipped - not checked because qcom-next already contains the change	present
3/3	[PATCH 3/3] FROMLIST: media: iris: add support for multi_slice in	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: 3/3
partial_commits: 0/3
missing_commits: 0/3
topics_checked_for_commits: 0/3
final_summary: PR present in qcom-next/topics: Yes - all 3 commit(s) are present in qcom-next or topics

[qlijarvis]

PR #979 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	All commits passed
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	Passed (pre-existing imagination driver errors unrelated to PR)
check-uapi-headers	✅	Passed
check-patch-compliance	❌	Content mismatch on commit 3/3
tag-check	✅	All commits have valid FROMLIST: prefix
qcom-next-check	⚠️	All commits are FROMLIST: — verify they exist in qcom-next

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #979 - media: iris: add support for multi_slice in iris encoder
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32238844253
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	All commits passed
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	Passed (pre-existing imagination driver errors unrelated to PR)
check-uapi-headers	✅	Passed
check-patch-compliance	❌	Content mismatch on commit 3/3
tag-check	✅	All commits have valid FROMLIST: prefix
qcom-next-check	⚠️	All commits are FROMLIST: — verify they exist in qcom-next

---

❌ check-patch-compliance

Root cause: The third commit's patch content differs from the upstream lore.kernel.org version.

Failure details:

Checking commit: FROMLIST: media: iris: add support for multi_slice in iris encoder
Change is different from the one mentioned in Link

Commit: 08d2f0885cc8a6e010129bec2022e5d15d42ac2f
Link: https://lore.kernel.org/all/20260728-iris_multi_slice-v8-3-eb18f96f0ed8@oss.qualcomm.com/

Analysis:

The checker detected that the patch content in the PR does not match the upstream patch at the provided lore link. This can happen for several reasons:

1. Context-only differences — line numbers shifted but actual changes are identical (false positive)
2. Legitimate adaptation — backport required modifications for the target kernel version
3. Missing hunks — some changes from upstream were omitted
4. Extra hunks — additional changes not present upstream

Fix:

1. Fetch the upstream patch and compare:

   b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260728-iris_multi_slice-v8-3-eb18f96f0ed8@oss.qualcomm.com/ -o /tmp/upstream
   git format-patch -1 08d2f0885cc8a6e010129bec2022e5d15d42ac2f --stdout > /tmp/pr-patch.patch
   
   # Compare the actual code changes (ignoring context line numbers)
   diff <(awk '/^diff/,/^--$/' /tmp/pr-patch.patch | grep -E '^[+-][^+-]') \
        <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')

2. If differences are real:

   • Context-only shift: No action needed — this is a checker limitation
   • Legitimate backport adaptation: Document the changes in the commit message with a note like:

     [ qcom-6.18.y: adapted for <reason>, changed <what> ]
     

   • Missing hunks: Cherry-pick the missing changes from upstream
   • Extra hunks: Remove them or attribute them to a separate commit

3. If the patch is identical: This may be a transient b4 fetch issue. Re-trigger CI.

Reproduce locally:

cd kernel
git checkout qcom-6.18.y
git fetch origin pull/979/head:pr-979
git checkout pr-979
../kernel-checkers/check-patch-compliance.sh qcom-6.18.y HEAD~2..HEAD

---

⚠️ qcom-next-check

Note: All three commits use the FROMLIST: prefix, indicating they are posted upstream but not yet merged into mainline.

Recommendation: Verify that these commits are already present in qcom-next before merging to qcom-6.18.y. The typical workflow is:

1. Patches land in qcom-next first
2. After validation, they are backported to stable branches like qcom-6.18.y

If these commits are not yet in qcom-next, consider:

• Merging them to qcom-next first, or
• Changing the prefix to BACKPORT: if they required modifications for qcom-6.18.y

---

Verdict

1 blocker to fix before merge:

The check-patch-compliance content mismatch on commit 3/3 must be investigated and resolved. The patch either needs to match the upstream version exactly, or the differences must be documented in the commit message if they are legitimate backport adaptations.

All other checkers passed successfully.

[qcomlnxci]

Test jobs on 08d2f08

• multimedia Job 212526 on hamoa-iot-evk
• multimedia Job 212523 on lemans-evk
• multimedia Job 212522 on monaco-evk
• multimedia Job 212521 on purwa-iot-evk
• multimedia Job 212519 on qcs615-ride
• multimedia Job 212520 on qcs6490-rb3gen2
• multimedia Job 212527 on qcs8300-ride
• multimedia Job 212524 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212525 on shikra-iqs-evk

[qcomlnxci]

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	◻️	◻️
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	◻️	◻️
CPU_affinity	✅ 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	❌ Fail	◻️	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
Interrupts	✅ 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	◻️	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	◻️
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	◻️	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	◻️	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #979

Job 212519 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — False Positive (Known Benign cfg80211 Regulatory Database Load Failure)

1. Failed case: Probe_Failure_Check — False Positive (Known Benign cfg80211 Regulatory Database Load Failure)
2. Root cause: The Probe_Failure_Check test flagged a cfg80211 regulatory.db firmware load failure (Direct firmware load for regulatory.db failed with error -2) as a probe failure. This is a known benign condition: cfg80211 attempts to load an optional regulatory database file, fails (file not present in rootfs), and falls back to compiled-in regulatory rules. WiFi functionality is unaffected — the wlp1s0 interface was created successfully and all WiFi tests passed. The failure is not related to the PR (which only modifies the iris video codec driver) and does not indicate a kernel regression.
3. Possible fix: Update the Probe_Failure_Check test script to suppress the regulatory: Direct firmware load for regulatory.db failed with error -2 pattern as a known benign failure. This error does not indicate a driver probe failure or functional regression. Alternatively, if strict firmware load checking is required, add the regulatory.db file to the test rootfs image to eliminate the warning.
4. Detail analysis attachment: failed_case_job212519_1_detailed.md

  Case 2: smmu (Test Validation Failure — Child Device IOMMU Attachment Check)

1. Failed case: smmu (Test Validation Failure — Child Device IOMMU Attachment Check)
2. Root cause: The LAVA smmu test expects video codec child devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to have separate IOMMU group attachments in sysfs, but these are logical V4L2 video devices created by the iris media driver, not independent platform devices with DMA capability requiring separate IOMMU bindings. The parent device aa00000.video-codec is correctly attached to IOMMU group 7, and the kernel SMMU subsystem is functioning correctly with no faults or errors.
3. Possible fix: Update the LAVA smmu test script to exclude logical child devices (identified by : in device name) from the critical master IOMMU attachment check, or explicitly whitelist video-decoder and video-encoder as expected non-DMA child devices that inherit IOMMU protection from their parent.
4. Detail analysis attachment: failed_case_job212519_2_detailed.md

  Case 3: KVM Driver Initialization Failure — Platform Hardware Limitation

1. Failed case: KVM Driver Initialization Failure — Platform Hardware Limitation
2. Root cause: The qcs615-ride platform does not support ARM Virtualization Extensions (EL2/HYP mode), which is a hardware prerequisite for KVM. The KVM driver correctly detected this limitation during boot and reported "kvm [1]: HYP mode not available", preventing /dev/kvm creation. This is expected behavior for this SoC.
3. Possible fix: Update the LAVA test job definition for qcs615-ride to exclude KVM tests, or add a runtime check in the test script to skip KVM tests when "HYP mode not available" is detected in dmesg. This is a test infrastructure issue, not a kernel bug. The PR (media/iris driver changes) does not introduce or affect this failure.
4. Detail analysis attachment: failed_case_job212519_3_detailed.md

  Case 4: ** KVM_EL2_DTB — KVM unavailable due to hypervisor mode conflict

1. Failed case: ** KVM_EL2_DTB — KVM unavailable due to hypervisor mode conflict
2. Root cause: ** The qcs615-ride platform boots under the Gunyah hypervisor (detected at boot: Hypervisor cold boot, version: gunyah-cdfb73831), which occupies EL2 (hypervisor mode). KVM requires direct EL2 access to create /dev/kvm and enable virtualization, but when Linux runs as a guest under Gunyah, EL2 is not available to the kernel, causing KVM initialization to fail with kvm [1]: HYP mode not available.
3. Possible fix: This is not a kernel bug or PR regression. The test expectation is incorrect for this platform configuration. Either: (1) Skip KVM tests on qcs615-ride when running under Gunyah hypervisor, or (2) Configure the platform to boot Linux directly (without Gunyah) if KVM functionality is required for testing. To implement option (1), add a test skip condition in the KVM test suite that checks for hypervisor presence via /sys/hypervisor/type or dmesg signature before attempting KVM tests.
4. Detail analysis attachment: failed_case_job212519_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM failed to initialize because HYP mode is not available on qcs615-ride — the Gunyah hypervisor is running in EL2, preventing KVM from taking control of the hypervisor exception level, resulting in "kvm [1]: HYP mode not available" during kernel boot.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The qcs615-ride board is configured to run the Gunyah hypervisor, which occupies EL2 and prevents KVM from initializing. To enable KVM testing on this platform, either: (1) disable the Gunyah hypervisor in the boot configuration to allow KVM to run natively in EL2, or (2) skip KVM tests on qcs615-ride in the CI job definition since this platform is configured for Gunyah virtualization, not KVM.
4. Detail analysis attachment: failed_case_job212519_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because the QCS615 platform does not support HYP (hypervisor) mode - the kernel message "kvm [1]: HYP mode not available" indicates the CPU/platform lacks EL2 virtualization extensions required for KVM operation.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The QCS615 SoC does not support ARM virtualization extensions (EL2/HYP mode). Mark KVM tests as "skip" or "not applicable" for qcs615-ride in the CI test matrix, or exclude this platform from KVM test runs.
4. Detail analysis attachment: failed_case_job212519_6_detailed.md

Job 212520 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC (Test Infrastructure Bug)

1. Failed case: GIC (Test Infrastructure Bug)
2. Root cause: The GIC test script (run.sh line 75) has a bash integer comparison bug when parsing /proc/interrupts for CPUs that are present but offline. The qcs6490-rb3gen2 board has 8 CPUs (0-7) present, but only 6 CPUs (0-5) are online at test time. The script attempts to parse timer interrupt counts for offline CPUs 6-7, which do not have columns in /proc/interrupts, causing bash to encounter "GICv3" (the interrupt controller name) instead of an integer, triggering the error: [: GICv3: integer expected.
3. Possible fix: Fix the GIC test script to skip offline CPUs or handle missing interrupt count columns gracefully. The script should check /sys/devices/system/cpu/cpu*/online before attempting to parse interrupt counts for each CPU, or use awk to safely extract only the numeric columns that exist for online CPUs.
4. Detail analysis attachment: failed_case_job212520_1_detailed.md

  Case 2: 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 linux-firmware-renesas package (or equivalent containing renesas_usb_fw.mem) to the rootfs build recipe for rb3gen2 test images. This is an optional PCIe USB controller and does not impact core system functionality, so the PR can proceed — this failure should be tracked separately as a test infrastructure improvement.
4. Detail analysis attachment: failed_case_job212520_2_detailed.md

  Case 3: ** Freq_Scaling (Test Logic Defect)

1. Failed case: ** Freq_Scaling (Test Logic Defect)
2. Root cause: ** The Freq_Scaling test checks for cpufreq interface presence on CPU7, but qcs6490-rb3gen2 has only 6 physical CPUs (CPU0-CPU5). The test hardcodes an 8-CPU iteration without querying actual CPU topology via /sys/devices/system/cpu/present, causing failure when CPU7 is not found.
3. Possible fix: Update the test script to query /sys/devices/system/cpu/present and iterate only through existing CPUs. Short-term: mark Freq_Scaling as expected failure or skip for qcs6490-rb3gen2 in the LAVA job definition.
4. Detail analysis attachment: failed_case_job212520_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing Renesas USB firmware file renesas_usb_fw.mem to the root filesystem image under /lib/firmware/. The firmware package is typically provided by linux-firmware or a vendor-specific firmware package. Rebuild the root filesystem with the firmware included, or install the firmware package at runtime before the test executes.
4. Detail analysis attachment: failed_case_job212520_4_detailed.md

  Case 5: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: **
3. Possible fix: Exclude KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests from the qcs6490-rb3gen2 test suite, as this platform configuration does not support nested virtualization. Alternatively, if KVM functionality is required, reconfigure the platform to boot without the Gunyah hypervisor (bare-metal mode), though this will disable Gunyah-dependent secure virtualization features.
4. Detail analysis attachment: failed_case_job212520_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Disable Gunyah hypervisor in the bootloader/firmware configuration for qcs6490-rb3gen2 if KVM testing is required, OR exclude KVM tests from the CI test suite for platforms running Gunyah. This is a platform-level decision, not a kernel code fix.
4. Detail analysis attachment: failed_case_job212520_6_detailed.md

  Case 7: ** KVM Infrastructure Test Failure — Platform Does Not Support Virtualization

1. Failed case: ** KVM Infrastructure Test Failure — Platform Does Not Support Virtualization
2. Root cause: ** The qcs6490-rb3gen2 (Kodiak) platform does not support ARM EL2/HYP mode (virtualization extensions). KVM driver initialization fails with "HYP mode not available" at boot, preventing /dev/kvm device node creation. CONFIG_KVM is enabled in kernel config but the hardware does not support the required CPU virtualization features.
3. Possible fix: This is a pre-existing platform limitation, not a regression. The KVM_Infra test should be excluded from the qcs6490-rb3gen2 test suite, or the test should be updated to skip gracefully when /dev/kvm is not present due to missing hardware support. No kernel code changes are required. The PR (media: iris driver changes) is unrelated and does not cause this failure.
4. Detail analysis attachment: failed_case_job212520_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support KVM virtualization — kernel reports "HYP mode not available" during boot, preventing /dev/kvm device creation. This is a hardware/firmware limitation of the qcs6490-rb3gen2 platform, not a kernel regression.
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the CI test suite for qcs6490-rb3gen2 and other platforms without HYP mode support, or mark them as expected failures for these platforms.
4. Detail analysis attachment: failed_case_job212520_8_detailed.md

Job 212521 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected 5 pre-existing platform probe failures at boot time (qcom_qseecom_uefisecapp -EBUSY, two qcom-pcie instances -ENODATA, qcom-spmi-lpg -EINVAL, regulatory.db firmware -ENOENT) that are unrelated to the PR changes (iris video codec driver). These failures existed before the test ran and are platform/board-specific hardware configuration issues on purwa-evk, not regressions introduced by PR Video slice changes #979.
3. Possible fix: Mark this test failure as a false positive for PR Video slice changes #979. The probe failures are pre-existing platform issues: (1) qcom_qseecom_uefisecapp -EBUSY (device busy) is a known TrustZone app initialization race on this platform; (2) PCIe probe failures -ENODATA indicate PHY power-on issues due to missing/unpopulated PCIe slots or DT configuration for purwa-evk; (3) qcom-spmi-lpg -EINVAL is a multi-LED DT binding issue; (4) regulatory.db firmware -ENOENT is expected when the file is not bundled in rootfs (cfg80211 falls back to compiled-in database). None of these are caused by iris video codec changes. Approve PR Video slice changes #979 for merge.
4. Detail analysis attachment: failed_case_job212521_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The smmu test detected that 6 critical DMA masters (5 USB DWC3 controllers at a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and the video codec at aa00000) are missing IOMMU group attachments on the purwa-evk platform, indicating incomplete device tree iommus property configuration for these devices.
3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video-codec aa00000.video-codec in the purwa-evk DTS, referencing the appropriate SMMU phandle and stream IDs to ensure these critical masters are protected by the IOMMU.
4. Detail analysis attachment: failed_case_job212521_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 a platform limitation, not a kernel bug. To enable KVM on purwa-evk: (1) verify the SoC supports virtualization extensions, (2) ensure the bootloader/firmware boots the kernel at EL2 (not EL1), (3) check if secure firmware (TrustZone) has disabled EL2 access and request a firmware update if needed. If purwa-evk does not support virtualization, exclude KVM tests from this platform's CI configuration.
4. Detail analysis attachment: failed_case_job212521_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM device node unavailable (platform configuration)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (platform configuration)
2. Root cause: Purwa-evk platform boots with Gunyah hypervisor running at EL2, placing Linux kernel at EL1 (guest mode). KVM requires EL2 (HYP mode) access to initialize and create /dev/kvm. The kernel correctly detects "HYP mode not available" and skips KVM initialization. This is expected behavior for this platform configuration, not a kernel defect.
3. Possible fix: This is not a bug requiring a fix. If KVM functionality is required on purwa-evk, the platform must be configured to boot Linux at EL2 (bare-metal mode) instead of under the Gunyah hypervisor. This requires bootloader/firmware changes to disable hypervisor boot, which is outside the scope of kernel changes. For CI purposes, either: (1) skip KVM tests on purwa-evk, or (2) use a different platform that boots Linux at EL2.
4. Detail analysis attachment: failed_case_job212521_4_detailed.md

  Case 5: ** KVM Infrastructure Failure — KVM driver initialization blocked by Gunyah hypervisor

1. Failed case: ** KVM Infrastructure Failure — KVM driver initialization blocked by Gunyah hypervisor
2. Root cause: ** KVM driver probe failed because EL2 (HYP mode) is already claimed by the Gunyah hypervisor (gunyah-mobile-c487961e9) running on the Purwa EVK platform. KVM requires exclusive EL2 access and cannot initialize when another hypervisor controls that exception level, resulting in "HYP mode not available" and no /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR regression - it is an expected platform configuration conflict. To enable KVM on Purwa EVK: (1) disable Gunyah hypervisor in the bootloader/firmware configuration, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use a different test platform without Gunyah for KVM validation. The PR changes (Iris video driver) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job212521_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP (EL2) mode is not available on the purwa-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware/firmware limitation, not a PR-introduced regression (PR modifies only media/iris driver). KVM requires EL2 hypervisor mode support which is not available on this SoC/board configuration. Either: (1) skip KVM tests on purwa-evk in CI job definition, or (2) verify if EL2 can be enabled via bootloader/firmware configuration for this platform.
4. Detail analysis attachment: failed_case_job212521_6_detailed.md

Job 212522 | SoC monaco-evk

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

Failed test cases in LAVA job 212522 (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 files to the rootfs image: copy ath11k/WCN6855/hw2.1/nfa765/amss.bin (and related .elf/.bin files) to /lib/firmware/ in the Yocto build recipe or rootfs overlay for monaco-evk target. Verify firmware presence with ls -la /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ on target before running WiFi tests.
4. Detail analysis attachment: failed_case_job212522_1_detailed.md

  Case 2: ** WiFi Driver Probe Failure — ath11k_pci probe timeout

1. Failed case: ** WiFi Driver Probe Failure — ath11k_pci probe timeout
2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT (error -110) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory, preventing MHI firmware download and device initialization.
3. Possible fix: Add the missing WCN6855 WiFi firmware files for the nfa765 variant to the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin, m3.bin, and regdb.bin — then rebuild the rootfs image and reflash the target.
4. Detail analysis attachment: failed_case_job212522_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci

1. Failed case: WiFi Driver Probe Failure — ath11k_pci
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory, causing MHI (Modem Host Interface) power-up to fail during driver initialization on monaco-evk.
3. Possible fix: Install the missing WCN6855 WiFi firmware files for the nfa765 board variant into the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin and associated board files — then rebuild the rootfs image and re-trigger the CI job.
4. Detail analysis attachment: failed_case_job212522_3_detailed.md

  Case 4: ** 0_qcom-next-ci-premerge-tests (Test Infrastructure Issue — Incomplete Result Cleanup)

1. Failed case: ** 0_qcom-next-ci-premerge-tests (Test Infrastructure Issue — Incomplete Result Cleanup)
2. Root cause: ** LAVA test runner completed all tests and reported results via LAVA_SIGNAL_TESTCASE, but the result_parse.sh cleanup script found two orphaned .res files (Ethernet_Basic_Validation.res and WiFi_OnOff.res) that were not removed after successful result reporting, triggering LAVA's "unfinished test run" detection and marking the test definition as failed despite all tests completing.
3. Possible fix: This is a pre-existing test infrastructure bug in the LAVA test runner cleanup logic, not a kernel regression introduced by PR Video slice changes #979 (which only modifies the Iris video codec driver). The test definition's result_parse.sh script should be updated to either: (1) skip .res files that have already been reported via LAVA_SIGNAL_TESTCASE, or (2) ensure send-to-lava.sh removes .res files after successful reporting. No kernel changes are required.
4. Detail analysis attachment: failed_case_job212522_4_detailed.md

Job 212523 | SoC lemans-evk

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

Failed test cases in LAVA job 212523 (SoC: lemans-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: This is a pre-existing platform configuration issue unrelated to the PR (which only touches iris video driver). The test should either: (1) exclude lemans-evk from strict Probe_Failure_Check enforcement until the platform's thermal monitoring stack is complete, or (2) add the missing qpnp-adc-tm5 driver and thermal zone DT nodes for lemans PMICs. The PR itself is not the cause and should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job212523_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on lemans-evk platform — the device tree for this SoC either lacks the video codec node at this address or the node is missing required iommus property bindings, preventing SMMU protection for this critical DMA master.
3. Possible fix: Add or fix the video codec device tree node for lemans-evk (sa8775p) at address 0xaa00000 with proper iommus property to bind it to an SMMU context bank; alternatively, if the hardware does not have a video codec at this address, update the smmu test's critical-device list to exclude aa00000.video-codec for lemans-evk platform.
4. Detail analysis attachment: failed_case_job212523_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the test definition as failed because two test cases within the suite failed (Probe_Failure_Check and smmu), even though the test runner completed normally and the kernel booted successfully. These failures are pre-existing infrastructure/platform issues unrelated to the PR changes (iris media driver multi-slice encoding support).
3. Possible fix: The test suite failure is not PR-introduced. The Probe_Failure_Check failure is due to deferred probe of temp-alarm devices and missing firmware files (regulatory.db, bluetooth firmware) — these are known benign issues on lemans-evk. The smmu failure is due to aa00000.video-codec missing IOMMU group attachment, which is a device tree configuration issue unrelated to the iris driver code changes in this PR. Re-run the CI job to confirm reproducibility; if persistent, update the test expectations to exclude these known platform-specific failures from blocking PR validation.
4. Detail analysis attachment: failed_case_job212523_3_detailed.md

Job 212524 | SoC qcs9100-ride

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

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

  Case 1: ** Kernel Crash — Synchronous External Abort during SMMU Register Write

1. Failed case: ** Kernel Crash — Synchronous External Abort during SMMU Register Write
2. Root cause: ** CPU write to SMMU S2CR register (stream-to-context mapping) at address 0x15000000 triggered synchronous external abort (ESR 0x96000010) during arm_smmu_device_probe. SMMU register reads succeeded (capability discovery completed), but first register write failed with hardware bus error. This indicates the SMMU register space is not writable, likely due to missing or incorrect clock/power-domain configuration in the qcs9100-ride device tree. The crash is platform-specific (qcs9100-ride) and unrelated to PR Video slice changes #979 (which only modifies iris video encoder driver).
3. Possible fix: Audit the qcs9100-ride device tree SMMU node (iommu@15000000) and verify all required properties are present and correct: clocks (cfg, ahb, axi), power-domains (SMMU_GDSC), and reg (0x15000000). Compare with reference qcs9100 DT or upstream bindings. Add missing clocks/power-domains, rebuild DTB, and retest. If DT is correct, enable SMMU debug logging (#define DEBUG in drivers/iommu/arm/arm-smmu/qcom_iommu.c) to trace clock/power-domain enable sequence and identify which resource is missing. Consult Qualcomm platform team for qcs9100-ride SMMU hardware requirements.
4. Detail analysis attachment: failed_case_job212524_1_detailed.md

  Case 2: Kernel Crash — Synchronous External Abort in SMMU Initialization

1. Failed case: Kernel Crash — Synchronous External Abort in SMMU Initialization
2. Root cause: Hardware bus error (synchronous external abort 0x96000010) when kernel attempted to write SMMU S2CR register at offset 0xc28 during arm-smmu driver probe for 15000000.iommu on qcs9100-ride. SMMU configuration registers were readable (probe succeeded, hardware config detected), but S2CR write access triggered external abort, indicating SMMU register write path is not accessible — likely due to missing clock/power domain enablement, secure firmware lockdown of S2CR registers, or platform-specific SMMU configuration issue preventing kernel write access to stream mapping registers.
3. Possible fix: This is a pre-existing qcs9100-ride platform/firmware issue, not introduced by PR Video slice changes #979 (which only modifies media/iris driver). Immediate mitigation: disable SMMU or use bypass mode in device tree for this platform until root cause is resolved. Proper fix requires platform team investigation: (1) verify SMMU clocks and power domains are fully enabled before driver probe, (2) check TrustZone/secure firmware configuration — S2CR registers may be locked for secure-only access, (3) review qcs9100 SMMU device tree bindings and compare with working platforms (e.g., sm8450/sm8550), (4) collect SMMU register dump via JTAG/SDI to confirm register accessibility and secure configuration state.
4. Detail analysis attachment: failed_case_job212524_2_detailed.md

  Case 3: ** Kernel Crash — Synchronous External Abort during SMMU Initialization

1. Failed case: ** Kernel Crash — Synchronous External Abort during SMMU Initialization
2. Root cause: ** Hardware bus fault (synchronous external abort, ESR 0x96000010) when the SMMU driver attempted to write to the S2CR register during qcom_smmu_write_s2cr+0x84/0x140 at boot time. The SMMU hardware block was not accessible, likely due to missing power domain enablement, clock gating, or incorrect platform initialization sequence on qcs9100-ride.
3. Possible fix: This is a pre-existing qcs9100-ride platform issue unrelated to PR Video slice changes #979 (which only modifies iris video encoder logic). Investigate qcs9100-ride device tree for missing SMMU power-domain or clock bindings. Verify bootloader/firmware leaves SMMU in accessible state. Compare with working qcs9100 configurations. If this is a known board issue, mark the test as expected-fail for qcs9100-ride until platform support is fixed. Re-trigger CI on a different SoC (e.g., sm8650, sa8775p) to validate the PR patches independently.
4. Detail analysis attachment: failed_case_job212524_3_detailed.md

  Case 4: Kernel Crash — Synchronous External Abort (SMMU Register Access)

1. Failed case: Kernel Crash — Synchronous External Abort (SMMU Register Access)
2. Root cause: Synchronous external abort (ESR 0x96000010) in qcom_smmu_write_s2cr+0x84/0x140 during ARM SMMU initialization at boot; the SMMU hardware register at address ffff800084000c28 (x0 + x1 offset) is not accessible, indicating the SMMU hardware block is either not powered, not clocked, or the register mapping in device tree does not match the actual hardware configuration on qcs9100-ride.
3. Possible fix: Verify qcs9100-ride device tree SMMU node register mappings match hardware documentation; confirm SMMU power domain and clock dependencies are correctly specified and enabled before SMMU probe; check if firmware (XBL/TZ/hypervisor) has correctly configured SMMU access permissions for the kernel; if issue persists on this specific board, capture hardware state via JTAG/SDI to confirm SMMU block power/clock status at crash time.
4. Detail analysis attachment: failed_case_job212524_4_detailed.md

Job 212525 | SoC shikra-iqs-evk

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

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

  Case 1: GIC (Test Infrastructure Bug)

1. Failed case: GIC (Test Infrastructure Bug)
2. Root cause: The GIC test script assumes 8 CPUs (0-7) but shikra-iqs-evk has only 4 CPUs (0-3); the script's bash integer comparison at line 75 fails when parsing /proc/interrupts for non-existent CPUs 4-7, producing "[: GICv3: integer expected" errors and incorrectly reporting timer count failures for CPUs that don't exist on this SoC.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online (which correctly reports "0-3" for shikra-iqs-evk) instead of hardcoding an 8-CPU assumption, and only test CPUs that actually exist on the target platform.
4. Detail analysis attachment: failed_case_job212525_1_detailed.md

  Case 2: Probe_Failure_Check (Driver Probe Failures — Pre-Existing Baseline)

1. Failed case: Probe_Failure_Check (Driver Probe Failures — Pre-Existing Baseline)
2. Root cause: Test case flags 6 pre-existing probe failures (coresight-etm4x -EINVAL, cpufreq-dt -EEXIST, regulatory.db -ENOENT, and 4 deferred probe entries) that are unrelated to the PR changes (iris media driver only) and do not affect system functionality (all critical tests passed: WiFi, BT, SMMU, RNG, watchdog, GPU).
3. Possible fix: Suppress these known baseline probe failures in the Probe_Failure_Check test for shikra-iqs-evk, or update the test to exclude non-critical probe failures that do not block functional tests. The PR is safe to merge; failures are platform-specific baseline issues, not regressions.
4. Detail analysis attachment: failed_case_job212525_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel issue requiring a code fix. To enable the USBHost test: (1) Verify the device tree dr_mode property for the USB controller at 4e00000.usb is set to "host" or "otg" (not "peripheral"), (2) Connect a physical USB device (e.g., USB flash drive) to the USB host port on the shikra-iqs-evk board, (3) If using OTG, ensure the OTG cable/adapter is properly connected to enable host mode. Alternatively, mark this test as SKIP for boards without USB host hardware connectivity in the LAVA lab.
4. Detail analysis attachment: failed_case_job212525_3_detailed.md

  Case 4: BT_SCAN — Bluetooth device discovery failure

1. Failed case: BT_SCAN — Bluetooth device discovery failure
2. Root cause: Bluetooth controller (hci0) successfully powered on and started discovery, but no nearby Bluetooth devices were detected after 3 scan attempts (15 seconds each) and an interactive fallback scan. This is an environmental/infrastructure issue: no scannable Bluetooth devices were present in the test lab environment during the test run, not a kernel driver or firmware failure. The PR changes (media/iris video encoder) are completely unrelated to Bluetooth subsystem.
3. Possible fix: This is not a kernel bug requiring a code fix. The test failure is due to missing Bluetooth test infrastructure (no beacon/advertising device in range). To resolve: (1) verify a Bluetooth beacon or advertising device is powered on and within range of the shikra-iqs-evk board in the LAVA lab, (2) re-run the test, or (3) if the lab environment cannot guarantee Bluetooth device presence, mark BT_SCAN as an optional/informational test rather than a hard failure gate for PR validation.
4. Detail analysis attachment: failed_case_job212525_4_detailed.md

  Case 5: 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 RNG access triggers synchronous external abort (bus error 0x96000010) at qcom_rng_read+0xc4 when test attempts to read from /dev/hwrng. The qcom_rng hardware is either not present, not powered/clocked, or not accessible on the Shikra IQS EVK platform, but the driver probe did not detect this condition.
3. Possible fix: This is a pre-existing platform issue unrelated to PR 979 (which only modifies iris media driver). Recommended actions: (1) Verify qcom_rng hardware presence and DT configuration for shikra-iqs-evk; (2) Add runtime hardware validation in qcom_rng probe to fail gracefully if hardware is inaccessible; (3) Disable qcom_hwrng test for shikra-iqs-evk until hardware support is confirmed; (4) Re-run PR 979 validation excluding the qcom_hwrng test.
4. Detail analysis attachment: failed_case_job212525_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR Video slice changes #979 (iris media driver changes). To enable KVM: (1) verify Shikra IQS EVK hardware supports virtualization extensions, (2) configure bootloader/firmware to boot Linux in EL2 or enable VHE (Virtualization Host Extensions), (3) if a secure hypervisor is present, configure it to allow Linux KVM access to EL2. If KVM is not supported on this platform, mark KVM tests as expected-fail for Shikra IQS EVK in the CI configuration.
4. Detail analysis attachment: failed_case_job212525_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The KVM tests should be skipped on platforms that do not support EL2. Add a platform capability check to the test suite to skip KVM tests when dmesg | grep "HYP mode not available" is present, or when /sys/hypervisor/type does not exist. Alternatively, if EL2 support is expected on this platform, verify the bootloader/firmware configuration enables virtualization extensions and boots the kernel at EL2.
4. Detail analysis attachment: failed_case_job212525_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: Hardware random number generator (PRNG) register access triggered a synchronous external abort (ESR 0x96000010) during qcom_hwrng test execution. The abort occurred in qcom_rng_read() at offset +0xc4 when attempting to read from PRNG MMIO registers, indicating the hardware block is either unpowered, unclocke d, or inaccessible on this shikra-iqs-evk platform.
3. Possible fix: This is a pre-existing platform/hardware issue unrelated to PR Video slice changes #979 (which only modifies iris media driver). Disable the qcom_hwrng test for shikra-iqs-evk in the CI test suite, or investigate whether PRNG hardware requires additional clock/power domain enablement in the shikra device tree that is currently missing.
4. Detail analysis attachment: failed_case_job212525_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: Hardware access fault in qcom_rng_read() at offset +0xc4 when reading from MMIO register (instruction b940035c = ldr w28, [x26, #0]). The driver attempted to read from physical address 0x000000bc27fd7e39 (stored in x0/x19), which triggered a synchronous external abort indicating the hardware register is not accessible—likely due to the RNG hardware block being unpowered, unclocked, or in an incorrect power/clock state on shikra-iqs-evk.
3. Possible fix: Verify qcom_rng DT node clock/power-domain/regulator dependencies for shikra (SM8750) in arch/arm64/boot/dts/qcom/sm8750.dtsi and shikra-iqs-evk.dts. Ensure the RNG hardware block's clocks are enabled and power domain is active before driver probe. Add runtime PM support to qcom_rng driver if missing, or gate the RNG device node with status = "disabled" in shikra-iqs-evk.dts until hardware dependencies are resolved.
4. Detail analysis attachment: failed_case_job212525_9_detailed.md

  Case 10: lava-test-retry

1. Failed case: lava-test-retry
2. Root cause: Kernel crash (synchronous external abort) in qcom_rng driver during hardware RNG read operation at ~808 seconds into test execution. The crash occurred in qcom_rng_read+0xc4/0x228 when the qcom_hwrng test attempted to read random data from /dev/hwrng. The synchronous external abort (ESR=0x96000010) indicates a hardware bus error when accessing the RNG hardware registers, causing immediate kernel panic and system reboot. After reboot, the LAVA test shell never resumed, leading to the 2400-second timeout and lava-test-retry failure.
3. Possible fix: This is a hardware access fault in the qcom_rng driver, not caused by the PR changes (which only modify iris media driver). The PR is unrelated to RNG functionality. Recommended action: Re-trigger the CI job to determine if this is a transient hardware issue on the shikra-iqs-evk board. If the failure reproduces consistently, investigate the qcom_rng driver's register access sequence and verify the RNG hardware block is properly clocked and powered on this platform. Check if recent changes to clock/power management or device tree for shikra affected RNG availability.
4. Detail analysis attachment: failed_case_job212525_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 synchronous external abort (ESR=0x96000010) in qcom_rng_read() at offset +0xc4 while reading from hardware RNG registers during qcom_hwrng test execution; the crash triggered an EFI runtime service paging fault cascade, causing system hang and subsequent LAVA test timeout after 2400 seconds.
3. Possible fix: This is a hardware access fault in the qcom_rng driver on shikra-iqs-evk. Verify that: (1) the PRNG hardware block is properly powered and clocked in the device tree for shikra, (2) the register base address mapping in qcom_rng DT node matches the SoC memory map, (3) firmware has initialized the PRNG block before kernel access. If the issue persists, add error handling in qcom_rng_read() to gracefully handle external aborts and prevent system-wide cascade failures. Re-run the qcom_hwrng test after verifying DT configuration.
4. Detail analysis attachment: failed_case_job212525_11_detailed.md

Job 212526 | SoC hamoa-evk

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

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

  Case 1: ** Probe_Failure_Check — Pre-existing Platform Probe Failures (Not PR-Introduced)

1. Failed case: ** Probe_Failure_Check — Pre-existing Platform Probe Failures (Not PR-Introduced)
2. Root cause: ** Two pre-existing platform-specific probe failures on hamoa-evk: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource unavailability or secure boot policy restriction; (2) qcom-spmi-lpg fails with -EINVAL due to DT configuration mismatch for PMIC@1 PWM controller. The regulatory.db firmware failure is a known benign false positive (WiFi functional tests passed). None of these failures are related to the PR changes, which only modify the iris video codec driver.
3. Possible fix: Mark Probe_Failure_Check as a false positive for this PR. The probe failures are pre-existing platform limitations on hamoa-evk and do not indicate a regression introduced by PR Video slice changes #979. To resolve the underlying issues: (1) For qcom_qseecom_uefisecapp: verify TrustZone firmware configuration and secure boot policy allow UEFI Secure App access, or disable the driver if not required on this platform; (2) For qcom-spmi-lpg: audit the DT node for PMIC@1 PWM controller and ensure qcom,num-channels and channel configurations match the hardware; (3) For regulatory.db: no action needed (WiFi functional).
4. Detail analysis attachment: failed_case_job212526_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six critical DMA masters (five USB PHY devices: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb; and one video codec device: aa00000.video-codec) are not attached to any IOMMU group on hamoa-evk, indicating missing or incomplete iommus DT properties for these devices.
3. Possible fix: Add iommus properties to the device tree nodes for the missing USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) in arch/arm64/boot/dts/qcom/x7181.dtsi or the hamoa-evk board DTS, referencing the appropriate SMMU phandle and stream IDs for each device.
4. Detail analysis attachment: failed_case_job212526_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Platform does not support EL2 (Hypervisor mode). The hamoa-evk (x1e80100 SoC) firmware/hardware does not provide EL2 access required for KVM operation. During kernel initialization, kvm_arch_init() detected HYP mode not available and returned -ENODEV, preventing /dev/kvm device node creation.
3. Possible fix: Skip KVM tests on hamoa-evk platform by adding platform-specific test exclusion in LAVA job definition. If KVM support is required, work with Qualcomm firmware team to enable EL2 in the boot chain (TZ/UEFI configuration) and verify x1e80100 silicon supports virtualization extensions.
4. Detail analysis attachment: failed_case_job212526_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed because Gunyah hypervisor owns EL2 on Hamoa IoT EVK, preventing Linux KVM from accessing hypervisor mode (log shows "kvm [1]: HYP mode not available" at boot).
3. Possible fix: This is a platform configuration issue, not a kernel regression. The Hamoa IoT EVK platform runs Gunyah hypervisor which owns EL2, making nested virtualization (Linux KVM) unavailable. Either: (1) disable KVM tests for Gunyah-enabled platforms in CI, or (2) configure Gunyah to support nested virtualization if the hardware/firmware supports it, or (3) use a different test platform without a pre-existing hypervisor for KVM validation.
4. Detail analysis attachment: failed_case_job212526_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Disable Gunyah hypervisor in the kernel config and device tree if bare-metal KVM is required, OR accept that KVM tests will fail on Gunyah-enabled builds and mark these tests as expected-fail for this platform configuration. To enable KVM: remove CONFIG_GUNYAH and related Gunyah DT nodes, rebuild, and reflash.
4. Detail analysis attachment: failed_case_job212526_5_detailed.md

  Case 6: KVM Infrastructure Failure — HYP mode not available

1. Failed case: KVM Infrastructure Failure — HYP mode not available
2. Root cause: KVM driver initialization failed on hamoa-evk because the platform does not have EL2 (Hypervisor) mode available. The kernel is configured with CONFIG_KVM=y but the hardware/firmware does not provide the required hypervisor privilege level, preventing KVM from creating the /dev/kvm device node. This is a platform limitation, not a kernel regression.
3. Possible fix: This is not a bug to fix — it is expected behavior on platforms without hypervisor support. The KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) should be skipped on hamoa-evk or any platform where EL2 is not available. Update the LAVA test suite to check for /dev/kvm existence before running KVM tests, or exclude hamoa-evk from KVM test runs in the CI configuration.
4. Detail analysis attachment: failed_case_job212526_6_detailed.md

Job 212527 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check — Driver Probe Failures (DT configuration + missing firmware)

1. Failed case: Probe_Failure_Check — Driver Probe Failures (DT configuration + missing firmware)
2. Root cause: Two pre-existing platform issues unrelated to PR979: (1) Aquantia AQR115C PHY driver probe fails with -EINVAL due to missing firmware-name DT property on qcs8300-ride, preventing Ethernet PHY attachment; (2) cfg80211 regulatory.db firmware file absent from rootfs (benign — WiFi functional tests pass).
3. Possible fix: For Aquantia PHY: Add firmware-name property to the Aquantia PHY device tree node in qcs8300-ride DTS, or remove the property requirement if firmware is not needed for this PHY variant. For regulatory.db: Install wireless-regdb package in rootfs or suppress this known-benign failure in Probe_Failure_Check test (WiFi is fully functional without it).
4. Detail analysis attachment: failed_case_job212527_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: No physical USB device connected to board during test execution
3. Possible fix: Connect a USB device (e.g., USB flash drive) to the qcs8300-ride board's USB host port before running the test. Alternatively, modify the USBHost test to SKIP (instead of FAIL) when no USB devices are present, or update the LAVA job definition to explicitly require USB device presence as a test prerequisite.
4. Detail analysis attachment: failed_case_job212527_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: PHY link mode validation failure during interface bring-up — phylink rejected 2500base-x mode with -EINVAL due to mismatch between PHY advertised modes (0x000062c0) and MAC supported modes (0x000062cc), preventing eth0 from attaching to PHY and coming up administratively.
3. Possible fix: Verify and correct the device tree ethernet node for qcs8300-ride: check phy-mode, max-speed, and phy-connection-type properties match the actual PHY hardware (likely needs phy-mode = "2500base-x" or max-speed = <2500> adjustment); if DT is correct, investigate whether the PHY driver (likely Marvell or Broadcom) requires a quirk or firmware for qcs8300 platform.
4. Detail analysis attachment: failed_case_job212527_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver configured (CONFIG_KVM=y) but never initialized on qcs8300-ride platform. No KVM initialization messages in kernel log indicate the driver silently failed to probe, most likely because the platform firmware does not enable EL2 (hypervisor mode) or the SoC does not support virtualization extensions required for KVM on ARM64.
3. Possible fix: Verify qcs8300 SoC and firmware support EL2/VHE. If supported, configure bootloader to enable EL2 access. If not supported, mark KVM tests as SKIP for this platform in the LAVA test definition, or disable CONFIG_KVM in the kernel config for qcs8300 builds.
4. Detail analysis attachment: failed_case_job212527_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on qcs8300-ride because the platform boots with Gunyah hypervisor active. Both KVM and Gunyah require exclusive control of EL2 (hypervisor mode); when Gunyah is initialized first by firmware ("Gunyah based bootup" at boot), KVM detects it cannot take control and silently fails to create /dev/kvm, causing CONFIG_KVM=y but no device node.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms, not a PR-introduced regression. The test should be skipped on qcs8300-ride or any Gunyah-based platform. Add platform detection to the test suite: check for "Gunyah" in /proc/device-tree/hypervisor/compatible or dmesg, and skip KVM tests when Gunyah is active. Alternatively, disable CONFIG_KVM in the kernel config for Gunyah-based builds to avoid confusion.
4. Detail analysis attachment: failed_case_job212527_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running as a guest under Gunyah hypervisor at EL1; KVM requires EL2 (hypervisor mode) to create /dev/kvm, which is unavailable when the kernel itself is virtualized.
3. Possible fix: Exclude KVM tests from the qcs8300-ride LAVA test suite, or run these tests only on bare-metal (non-virtualized) configurations where the kernel boots at EL2 and can initialize KVM.
4. Detail analysis attachment: failed_case_job212527_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: /dev/kvm device node is not present despite CONFIG_KVM being enabled in the kernel configuration — KVM driver failed to initialize or create the device node during boot on qcs8300-ride platform.
3. Possible fix: Verify KVM driver initialization in kernel boot log; check if KVM is built as a module (CONFIG_KVM=m) and needs explicit loading via modprobe kvm; if built-in (CONFIG_KVM=y), check for KVM initialization errors in dmesg indicating why /dev/kvm was not created (e.g., missing EL2/VHE support, hypervisor mode unavailable, or platform-specific KVM enablement requirements for qcs8300).
4. Detail analysis attachment: failed_case_job212527_7_detailed.md

[sachinku173]

https://github.com/qualcomm-linux/kernel/milestone/4

[Salendarsingh Gaud (sgaud-quic)]

sachinku173 please add mainline PR to CR.

[sachinku173]

sachinku173 please add mainline PR to CR.

Done

[qcomlnxci]

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	◻️	⚠️ skip	⚠️ skip	◻️
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	◻️
CPU_affinity	✅ 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	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
Interrupts	✅ 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	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	◻️
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	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	◻️	◻️	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	◻️	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️

[qcomlnxci]

Test jobs on 08d2f08

• multimedia Job 226875 on hamoa-iot-evk
• multimedia Job 226876 on lemans-evk
• multimedia Job 226877 on monaco-evk
• multimedia Job 226873 on purwa-iot-evk
• multimedia Job 226872 on qcs615-ride
• multimedia Job 226878 on qcs6490-rb3gen2
• multimedia Job 226879 on qcs8300-ride
• multimedia Job 226880 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 226874 on shikra-iqs-evk

[qcomlnxci]

Test jobs on 08d2f08

• multimedia Job 226875 on hamoa-iot-evk
• multimedia Job 226876 on lemans-evk
• multimedia Job 226877 on monaco-evk
• multimedia Job 226873 on purwa-iot-evk
• multimedia Job 226872 on qcs615-ride
• multimedia Job 227383 on qcs6490-rb3gen2
• multimedia Job 226879 on qcs8300-ride
• multimedia Job 226880 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227384 on shikra-iqs-evk

[qcomlnxci]

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	❌ Fail	✅ 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	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ 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	✅ 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	⚠️ 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