[WangaoW]

The driver currently has no way to configure firmware debug
logging at runtime. This makes firmware-side issues harder to
debug, because changing the firmware debug mask requires a
rebuild or reload.

The patch adds a debugfs fw_level file under the Iris debugfs
directory. The value is stored per Iris core and is normalized
on write, so userspace reads back the same mask that is
programmed to firmware.

The firmware debug configuration is sent during core
initialization and before opening a new session. This allows a
fw_level value written before a session starts to take effect for
that session.

HFI Gen1 and Gen2 paths are added for programming the debug
configuration and reading firmware debug messages from the debug
queue. Firmware error and fatal messages are printed with
dev_err_ratelimited(), while other firmware messages use
dev_dbg().

The default mask enables only firmware error and fatal messages
to avoid enabling verbose firmware logging by default.

Failure to configure firmware debug logging is treated as non-fatal
and does not block normal video operation.
CRs-fixed: 4657239

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 70b750d

• multimedia Job 269807 on hamoa-iot-evk
• multimedia Job 269814 on lemans-evk
• multimedia Job 269815 on monaco-evk
• multimedia Job 269809 on purwa-iot-evk
• multimedia Job 269813 on qcs615-ride
• multimedia Job 269810 on qcs6490-rb3gen2
• multimedia Job 269808 on qcs8300-ride
• multimedia Job 269811 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269812 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1416

Job 269807 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two benign probe/firmware errors during boot: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (error -16) — UEFI secure app service unavailable or already in use on hamoa-evk platform; (2) regulatory.db firmware load failed with -ENOENT (error -2) — wireless regulatory database file not present in rootfs. Both are pre-existing platform configuration issues unrelated to PR Add firmware debug logging support for the qcom Iris driver #1416 (iris video codec firmware debug logging).
3. Possible fix: Suppress these two known benign failures in the Probe_Failure_Check test for hamoa-evk platform, as they do not indicate kernel regressions and the affected subsystems (QSEECOM UEFI secure app, WiFi regulatory database) function correctly despite these messages (WiFi ON/OFF test passed, BT tests passed).
4. Detail analysis attachment: failed_case_job269807_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 hamoa-evk platform; the SMMU test validation script detected this missing attachment and failed the test, but SMMU hardware is functioning correctly with no kernel errors.
3. Possible fix: Add or correct the iommus property in the device tree node for aa00000.video-codec (likely in arch/arm64/boot/dts/qcom/hamoa-evk.dts or the SoC-level dtsi) to bind the video codec to an IOMMU group; this is a pre-existing platform configuration issue unrelated to the PR changes.
4. Detail analysis attachment: failed_case_job269807_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 bug—it is expected platform behavior. To enable KVM testing on hamoa-evk, either (1) boot without the Gunyah hypervisor (use a non-EL2 boot configuration), or (2) exclude KVM tests from the hamoa-evk test suite since this platform is configured for Gunyah virtualization, not KVM virtualization.
4. Detail analysis attachment: failed_case_job269807_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed because the kernel is running under Gunyah hypervisor (gunyah-mobile-1f99e07c2) which does not expose EL2/HYP mode to the guest OS, preventing KVM from creating /dev/kvm. The kernel log shows kvm [1]: HYP mode not available at boot, indicating KVM detected it cannot access the virtualization extensions required to operate.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by the PR (which only modifies Iris media driver). The hamoa-evk board is configured to run Linux as a guest under Gunyah hypervisor without nested virtualization support. To enable KVM tests: (1) reconfigure the board to boot Linux directly at EL2 without a hypervisor, or (2) upgrade Gunyah hypervisor firmware to support nested virtualization and expose virtual EL2 to the guest, or (3) exclude KVM tests from the hamoa-evk test suite since this platform does not support KVM in its current configuration.
4. Detail analysis attachment: failed_case_job269807_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on hamoa-evk because EL2 (Hypervisor) mode is not available on this platform hardware — kernel message at boot: "kvm [1]: HYP mode not available". This is a pre-existing platform limitation unrelated to the PR changes (Iris media driver firmware debug logging).
3. Possible fix: This is not a regression introduced by PR Add firmware debug logging support for the qcom Iris driver #1416. The hamoa-evk platform does not support virtualization/KVM because it lacks EL2 hypervisor mode. Either: (1) exclude KVM tests from the hamoa-evk CI test suite, or (2) if KVM support is expected on this SoC, verify the bootloader/firmware configuration enables EL2 and the kernel is booted at the correct exception level.
4. Detail analysis attachment: failed_case_job269807_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform limitation, NOT a PR-introduced regression. The PR only modifies the Iris video driver and does not touch KVM code. To resolve: (1) Skip KVM tests on hamoa-evk in CI configuration, as this platform does not support virtualization; or (2) If EL2 support is expected, verify firmware/bootloader configuration to ensure the kernel boots at EL2 and check SoC documentation to confirm EL2 is implemented in hardware.
4. Detail analysis attachment: failed_case_job269807_6_detailed.md

Job 269808 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing platform issues unrelated to PR changes: (1) xhci-hcd USB host controller probe timeout (-110/ETIMEDOUT) on qcs8300-ride indicating USB PHY/clock/power sequencing issue or hardware unavailability; (2) missing regulatory.db firmware file (-2/ENOENT) for wireless regulatory domain enforcement, a known benign failure when the file is not packaged in the rootfs.
3. Possible fix: Both failures are pre-existing platform/infrastructure issues not introduced by this PR. The xhci-hcd timeout requires platform-specific investigation of USB subsystem power/clock dependencies on qcs8300-ride (check DT bindings, PHY initialization, and USB controller power sequencing). The regulatory.db failure is benign if wireless regulatory enforcement is not required; otherwise add linux-firmware package containing regulatory.db to the rootfs image.
4. Detail analysis attachment: failed_case_job269808_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Enable and configure the DWC3 USB controller driver and USB PHY drivers (qmp-combo-phy or qusb2-phy) for qcs8300 in the kernel configuration. Verify the device tree includes complete USB controller, PHY, and interconnect nodes with correct compatible strings, clocks, regulators, and resets. If USB host mode is intentionally unsupported on qcs8300-ride, disable the xHCI device tree node to prevent probe attempts.
4. Detail analysis attachment: failed_case_job269808_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm device node missing

1. Failed case: KVM_Driver — /dev/kvm device node missing
2. Root cause: KVM kernel module (kvm.ko) did not load or initialize during boot on qcs8300-ride platform, despite CONFIG_KVM=y in kernel config; no KVM initialization messages or errors appear in kernel log, and /dev/kvm character device was never created.
3. Possible fix: This is a pre-existing platform/kernel configuration issue unrelated to the PR (which modifies only drivers/media/platform/qcom/iris). Verify KVM ARM64 support is properly configured for qcs8300 SoC: check that CONFIG_KVM_ARM_HOST=y, CONFIG_HAVE_KVM=y, and that the platform's device tree and firmware support EL2/virtualization. If KVM is intentionally disabled on this platform, mark these KVM tests as expected-to-skip in the LAVA test suite for qcs8300-ride.
4. Detail analysis attachment: failed_case_job269808_3_detailed.md

  Case 4: KVM Device Node Missing — Driver Initialization Failure

1. Failed case: KVM Device Node Missing — Driver Initialization Failure
2. Root cause: KVM driver enabled in kernel config (CONFIG_KVM=y) but /dev/kvm device node not created; no KVM initialization messages in boot log indicate KVM failed to initialize silently, likely because QCS8300 (Monaco) platform does not support ARM virtualization extensions (EL2) or firmware/bootloader does not enable EL2 mode for Linux.
3. Possible fix: Verify QCS8300 hardware supports ARM virtualization extensions and EL2 is available; if not supported, disable KVM tests for this platform in CI; if supported, check bootloader/firmware configuration to ensure Linux boots at EL2 (VHE or nVHE mode) and KVM can initialize.
4. Detail analysis attachment: failed_case_job269808_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: This is a pre-existing platform limitation, not a bug. Either: (1) Skip KVM tests on qcs8300-ride (Monaco) platforms running Gunyah hypervisor, or (2) Use a different platform configuration without Gunyah if KVM functionality is required. The PR changes (Iris media driver firmware logging) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job269808_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: /dev/kvm device node is not present on qcs8300-ride platform despite CONFIG_KVM being enabled in kernel config — KVM driver failed to initialize or create the device node during boot, indicating either missing hardware virtualization support (EL2/VHE) on this SoC or a platform-specific KVM initialization failure unrelated to the PR changes (which only modify media/qcom/iris video codec driver).
3. Possible fix: This is a pre-existing platform issue not introduced by PR Add firmware debug logging support for the qcom Iris driver #1416 (which only touches drivers/media/platform/qcom/iris). Verify qcs8300-ride hardware supports ARM virtualization extensions (EL2/VHE) and check kernel boot log for KVM initialization errors. If the platform does not support KVM, exclude KVM tests from the qcs8300-ride CI test suite. If KVM should be supported, investigate why the KVM ARM driver is not creating /dev/kvm during initialization.
4. Detail analysis attachment: failed_case_job269808_6_detailed.md

Job 269809 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test infrastructure detected four pre-existing probe/firmware failures during boot that are unrelated to the PR changes: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY due to secure world resource unavailability on purwa-evk, (2-3) two qcom-pcie probe failures with -ENODATA due to missing PCIe PHY init sequences for this platform, and (4) regulatory.db firmware load failure with -ENOENT due to missing optional wireless regulatory database file in rootfs.
3. Possible fix: These are pre-existing platform-specific limitations on purwa-evk, not regressions introduced by the PR. The PR only modifies the Iris video codec driver (drivers/media/platform/qcom/iris/) and does not touch QSEECOM, PCIe, or wireless regulatory subsystems. To resolve the test failure: (1) update the Probe_Failure_Check test to exclude known benign failures for purwa-evk (QSEECOM -EBUSY, PCIe -ENODATA for unconfigured controllers, regulatory.db -ENOENT), or (2) fix the platform configuration by adding PCIe PHY init sequences to the device tree, ensuring QSEECOM dependencies are met, and including regulatory.db in the rootfs if wireless functionality is required.
4. Detail analysis attachment: failed_case_job269809_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is missing IOMMU group attachment, causing the SMMU validation test to fail because a critical master device is not protected by the IOMMU subsystem.
3. Possible fix: Add the missing iommus property to the video-codec device tree node at address aa00000 for the purwa-evk platform, or verify that the iris video driver changes in PR Add firmware debug logging support for the qcom Iris driver #1416 have not inadvertently broken the video codec's IOMMU attachment during device probe.
4. Detail analysis attachment: failed_case_job269809_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Test infrastructure misconfiguration - KVM tests are running on purwa-evk platform which boots under Gunyah hypervisor; KVM cannot initialize because EL2 (hypervisor mode) is already occupied by Gunyah, resulting in "HYP mode not available" and missing /dev/kvm device node.
3. Possible fix: Exclude KVM tests from the purwa-evk test suite in the LAVA job definition, as this platform architecture does not support nested virtualization or KVM when running under Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job269809_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM device node unavailable

1. Failed case: KVM_EL2_DTB — KVM device node unavailable
2. Root cause: KVM initialization failed because HYP/EL2 mode is not available on purwa-evk; the platform boots under Gunyah hypervisor which reserves EL2, preventing KVM from creating /dev/kvm. The kernel log shows "kvm [1]: HYP mode not available" at boot, confirming KVM cannot initialize in this virtualized environment.
3. Possible fix: This is a platform limitation, not a kernel bug. Disable KVM tests for purwa-evk in the LAVA test suite, or configure the platform to boot without the Gunyah hypervisor if KVM functionality is required. The PR changes (Iris media driver firmware logging) are unrelated to KVM and do not cause this failure.
4. Detail analysis attachment: failed_case_job269809_4_detailed.md

  Case 5: KVM_Infra (Platform Hardware Limitation)

1. Failed case: KVM_Infra (Platform Hardware Limitation)
2. Root cause: The Purwa IoT EVK SoC does not support ARM virtualization extensions (EL2/HYP mode). KVM driver initialization detected "HYP mode not available" at boot, preventing /dev/kvm device creation. This is a hardware platform limitation, not a kernel regression.
3. Possible fix: Mark KVM tests as "not applicable" for Purwa IoT EVK platform in the LAVA test suite configuration, or skip KVM tests on platforms without EL2 support. This is not a code fix — the platform hardware does not support virtualization.
4. Detail analysis attachment: failed_case_job269809_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support KVM virtualization — kernel reports "HYP mode not available" during boot, indicating the purwa-evk SoC/firmware does not provide EL2 hypervisor mode required for KVM operation.
3. Possible fix: Mark KVM tests as expected-fail or skip for purwa-evk platform in the LAVA job definition, as this is a hardware/firmware limitation not a kernel regression; alternatively, run KVM tests only on platforms with EL2 support (e.g., rb5, rb3gen2).
4. Detail analysis attachment: failed_case_job269809_6_detailed.md

Job 269810 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check (Test Infrastructure False Positive)

1. Failed case: Probe_Failure_Check (Test Infrastructure False Positive)
2. Root cause: The test flagged two probe failures that are not genuine regressions: (1) regulatory.db firmware load failure is a known WiFi false positive—WiFi_OnOff functional test passed, confirming WiFi firmware loaded correctly at runtime; (2) xhci-pci-renesas probe failure is a pre-existing platform limitation on qcs6490-rb3gen2 where the Renesas USB controller firmware (renesas_usb_fw.mem) is not included in the rootfs—USBHost test was skipped (not failed), and this error has existed in prior builds.
3. Possible fix: Suppress both failures in the Probe_Failure_Check test logic: (1) Add suppression rule for "regulatory.db failed" when WiFi_OnOff passes (already covered by lava-known-benign-failures.md Rule 2); (2) Add platform-specific suppression for xhci-pci-renesas probe failures on rb3gen2 boards where USBHost is skipped. Alternatively, update the test to cross-reference functional test results before flagging probe failures as errors.
4. Detail analysis attachment: failed_case_job269810_1_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure marked the test definition as failed because the Probe_Failure_Check test case detected two pre-existing probe errors (regulatory.db firmware missing, xhci-pci-renesas firmware missing) that are unrelated to the PR changes (Iris media driver firmware debug logging).
3. Possible fix: The PR is not the cause of this failure. The Probe_Failure_Check test should be updated to suppress known benign firmware load failures (regulatory.db, xhci-pci-renesas) that do not impact platform functionality. Alternatively, add the missing firmware files to the rootfs image or disable the test case for platforms where these devices are not critical.
4. Detail analysis attachment: failed_case_job269810_2_detailed.md

Job 269811 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing platform issues unrelated to PR changes: (1) cfg80211 regulatory database firmware file missing from rootfs (error -2 = -ENOENT), and (2) Aquantia AQR115C Ethernet PHY at MDIO address stmmac-0:08 probe failure due to missing or invalid firmware-name device tree property (error -22 = -EINVAL).
3. Possible fix: (1) Add regulatory.db firmware file to the rootfs image build recipe; (2) verify qcs9100-ride device tree includes correct firmware-name property for the Aquantia PHY node at MDIO address 0x08, or remove the property if firmware loading is not required for this PHY configuration.
4. Detail analysis attachment: failed_case_job269811_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test infrastructure false positive — the SMMU test script expects the parent video-codec device (aa00000.video-codec) to have a direct IOMMU group attachment, but the Iris video codec driver architecture correctly creates child platform devices (iris_non_pixel.0 and iris_pixel.0) that serve as the actual DMA masters and are properly attached to IOMMU groups 18 and 19 respectively.
3. Possible fix: Update the SMMU test script to recognize that video codec drivers using the Iris architecture attach child devices to IOMMU groups rather than the parent device. The test should check for iris_non_pixel.0 and iris_pixel.0 IOMMU group attachments instead of expecting aa00000.video-codec to have a direct attachment.
4. Detail analysis attachment: failed_case_job269811_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is NOT a PR-introduced regression (PR Add firmware debug logging support for the qcom Iris driver #1416 contains only Iris video codec changes). The failure is a known board/platform issue. Recommended action: Skip this test for qcs9100-ride until the device tree PHY configuration is corrected, or investigate the board's DT to add/fix the PHY phandle and phy-mode properties for the 23040000.ethernet node.
4. Detail analysis attachment: failed_case_job269811_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: qcs9100-ride platform does not support ARM Virtualization Extensions (EL2/HYP mode) — kernel reports "HYP mode not available" at boot, preventing KVM initialization and /dev/kvm device creation.
3. Possible fix: Remove KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests from the qcs9100-ride test suite, or configure the platform bootloader/firmware to enable EL2 mode if the SoC supports it (verify SoC datasheet first).
4. Detail analysis attachment: failed_case_job269811_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM Device Node Missing

1. Failed case: KVM_EL2_DTB — KVM Device Node Missing
2. Root cause: KVM initialization failed during kernel boot because the CPU is not running in EL2 (hypervisor) mode or ARM virtualization extensions are not available on the qcs9100-ride platform. The kernel message "kvm [1]: HYP mode not available" at boot time indicates KVM detected it cannot initialize, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression introduced by the PR (which only modifies media/iris driver). Verify the qcs9100-ride board firmware/bootloader is configured to boot the kernel in EL2 mode with virtualization extensions enabled. If the platform does not support EL2/KVM, mark KVM tests as "not applicable" for this SoC in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job269811_5_detailed.md

  Case 6: KVM_Infra — Platform EL2 Unavailable

1. Failed case: KVM_Infra — Platform EL2 Unavailable
2. Root cause: The qcs9100-ride platform boots in EL1 (kernel mode) instead of EL2 (hypervisor mode), preventing KVM initialization. The kernel message "kvm [1]: HYP mode not available" and bootloader message "Skipping overlay of hyp dt nodes for non-Gunyah hypervisor" confirm that the platform firmware does not configure the CPU to run in EL2, which is a prerequisite for KVM/ARM virtualization support.
3. Possible fix: This is a pre-existing platform/firmware limitation, not a kernel regression. The PR (media: qcom: iris firmware debug logging) does not touch KVM code. To enable KVM on qcs9100-ride: (1) configure the bootloader/firmware to boot the kernel in EL2 mode, or (2) enable a hypervisor (e.g., Gunyah) that provides EL2 virtualization support, or (3) mark KVM tests as expected-to-fail on platforms that do not support EL2 boot.
4. Detail analysis attachment: failed_case_job269811_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM is not available on qcs9100-ride (LeMans) platform because HYP mode is not supported - 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 known platform limitation, not a regression. The test should be skipped on qcs9100-ride, or the platform firmware/bootloader needs to be configured to boot the kernel in EL2 (HYP mode) to enable KVM support.
4. Detail analysis attachment: failed_case_job269811_7_detailed.md

Job 269812 | SoC shikra-iqs-evk

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

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

  Case 1: GIC Test Script Bug — Test Parsing Error

1. Failed case: GIC Test Script Bug — Test Parsing Error
2. Root cause: The GIC test script incorrectly parses /proc/interrupts when extracting per-CPU timer counts. The system has only 4 CPUs (0-3), but the script attempts to validate CPUs 4-7 by parsing non-numeric fields ("GICv3", "Level", "arch_timer") from the interrupt line as if they were CPU counter columns, causing bash integer comparison errors at line 75 and false "timer count has not incremented" failures.
3. Possible fix: Fix the GIC test script's /proc/interrupts parsing logic to correctly identify the number of online CPUs and extract only the numeric counter columns (columns 2 through N+1 where N is the number of online CPUs). The script should use nproc or /sys/devices/system/cpu/online to determine the CPU count before parsing interrupt counters.
4. Detail analysis attachment: failed_case_job269812_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing shikra-iqs-evk board configuration issues causing probe failures for non-critical peripherals: UCSI CCG USB Type-C controller missing firmware (ccg_secondary.cyacd2), regulatory database missing, TPM SPI device timeout (-110), and audio codec deferred probe due to missing clock/DAI configuration. These are board/firmware/DT configuration gaps unrelated to the PR changes (Iris video codec driver).
3. Possible fix: These probe failures are pre-existing board issues and not introduced by PR Add firmware debug logging support for the qcom Iris driver #1416 (which only modifies the Iris video codec driver). No action required for this PR. To resolve the underlying issues: (1) add ccg_secondary.cyacd2 firmware to rootfs /lib/firmware/, (2) add regulatory.db to rootfs, (3) verify TPM device tree SPI configuration and hardware connection, (4) fix audio codec device tree to provide correct mclk clock and CPU DAI references.
4. Detail analysis attachment: failed_case_job269812_2_detailed.md

  Case 3: ** PCIe — QPS615 Firmware Missing

1. Failed case: ** PCIe — QPS615 Firmware Missing
2. Root cause: ** Test environment configuration issue. The QPS615 PCIe-to-Ethernet switch validation failed because the required firmware file TC956X_Firmware_PCIeBridge.bin is not present in any standard firmware directory (/lib/firmware/, /lib/firmware/qca/, etc.) in the test rootfs. The kernel PCIe subsystem is functioning correctly (6 of 8 checks passed: enumeration, link training, MSI, runtime power management, and kernel health all passed). The failure is specific to the QPS615 switch firmware validation step, which is a test-level check, not a kernel functionality issue.
3. Possible fix: Provision the TC956X_Firmware_PCIeBridge.bin firmware file in the test rootfs at /lib/firmware/ or /lib/firmware/qca/. This firmware is required by the QPS615 (Toshiba TC956X) PCIe switch for the test validation step. The firmware should be added to the Yocto image recipe or copied into the rootfs during image build. This is a test infrastructure fix, not a kernel code change.
4. Detail analysis attachment: failed_case_job269812_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controllers on shikra-iqs-evk are configured in gadget/device mode rather than host mode; no USB root hubs are exposed because the hardware role is set to peripheral, preventing host controller (xHCI) initialization.
3. Possible fix: Update the shikra-iqs-evk device tree to set USB dr_mode to "host" or "otg" (with default role "host") for the USB ports under test, or update the LAVA job definition to skip the USBHost test on boards where USB is intentionally configured for gadget mode (serial console/ADB).
4. Detail analysis attachment: failed_case_job269812_4_detailed.md

  Case 5: ** KVM_Driver (test environment limitation — not a kernel issue)

1. Failed case: ** KVM_Driver (test environment limitation — not a kernel issue)
2. Root cause: ** The shikra-iqs-evk platform does not support ARM64 EL2 (Hypervisor mode), as evidenced by the kernel boot message kvm [1]: HYP mode not available. CONFIG_KVM is enabled in the kernel configuration, but the KVM driver cannot initialize because the hardware/firmware does not provide the required virtualization extensions. The /dev/kvm device node is never created because KVM initialization fails at probe time. This is a pre-existing platform limitation, not a regression introduced by PR Add firmware debug logging support for the qcom Iris driver #1416 (which only modifies the Iris video codec driver).
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for shikra-iqs-evk and other platforms that do not support EL2/virtualization. Add a platform capability check in the CI job definition to skip virtualization tests when HYP mode not available is detected in the kernel boot log, or maintain a platform whitelist for KVM tests that only includes boards with confirmed EL2 support.
4. Detail analysis attachment: failed_case_job269812_5_detailed.md

  Case 6: KVM_EL2_DTB — KVM/Virtualization Infrastructure Unavailable

1. Failed case: KVM_EL2_DTB — KVM/Virtualization Infrastructure Unavailable
2. Root cause: KVM failed to initialize because the platform is running under the Gunyah hypervisor in a configuration where EL2 (HYP mode) is not available to the Linux kernel. The kernel message "kvm [1]: HYP mode not available" indicates KVM detected it cannot access EL2, which is required for KVM to provide virtualization services. On shikra-iqs-evk, the Gunyah hypervisor owns EL2 and does not expose nested virtualization capabilities to the primary VM (PVM), preventing /dev/kvm creation.
3. Possible fix: This is a platform configuration limitation, not a kernel regression. The KVM_EL2_DTB test should be skipped on platforms running under Gunyah hypervisor without nested virtualization support. Update the LAVA test definition to add a pre-flight check: if "Gunyah" is detected in dmesg and "HYP mode not available" is present, mark KVM tests as SKIP rather than FAIL. Alternatively, if nested virtualization is required, update the Gunyah hypervisor configuration to expose EL2 capabilities to the PVM.
4. Detail analysis attachment: failed_case_job269812_6_detailed.md

  Case 7: KVM Infrastructure Test Failure — Platform Configuration Mismatch

1. Failed case: KVM Infrastructure Test Failure — Platform Configuration Mismatch
2. Root cause: KVM driver cannot initialize on Shikra IQS EVK because the platform is running Gunyah hypervisor at EL2, which prevents KVM from claiming HYP mode. The kernel message kvm [1]: HYP mode not available indicates this is expected behavior when another hypervisor is present.
3. Possible fix: Disable KVM tests for Shikra IQS EVK in the LAVA test suite, or reconfigure the platform to boot without Gunyah hypervisor if KVM testing is required. This is not a PR-introduced regression — PR Add firmware debug logging support for the qcom Iris driver #1416 only modifies media/iris driver code and does not affect virtualization subsystems.
4. Detail analysis attachment: failed_case_job269812_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present on the shikra-iqs-evk platform, despite CONFIG_KVM=y being enabled in the kernel configuration. This indicates the KVM kernel module either failed to probe, is not built into the kernel, or the platform does not support KVM virtualization at EL2.
3. Possible fix: Verify that the shikra-iqs-evk platform supports KVM/virtualization (check if CPU supports VHE/nVHE and if the hypervisor is configured correctly). If KVM is expected to work on this platform, check dmesg for KVM initialization errors during boot. If KVM is not supported on shikra-iqs-evk, mark this test as expected-fail or skip it in the LAVA test definition for this platform.
4. Detail analysis attachment: failed_case_job269812_8_detailed.md

Job 269813 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing rootfs configuration issue — wireless regulatory database firmware file (regulatory.db) is missing from /lib/firmware/, causing cfg80211 to log a firmware load failure (error -2, ENOENT) at boot time. The Probe_Failure_Check test detected this error message in dmesg and reported it as a test failure. This is NOT a PR-introduced regression; the PR modifies only the Iris video codec driver and does not touch wireless, cfg80211, or firmware loading infrastructure.
3. Possible fix: Add the regulatory.db firmware file to the rootfs image under /lib/firmware/. The file is provided by the wireless-regdb package. Alternatively, if the regulatory database is intentionally omitted, update the Probe_Failure_Check test to suppress known-benign firmware load failures for optional firmware files like regulatory.db.
4. Detail analysis attachment: failed_case_job269813_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test script incorrectly expects V4L2 video sub-devices (video-decoder, video-encoder) to have separate IOMMU group attachments, but these are virtual devices that inherit IOMMU protection from their parent platform device (aa00000.video-codec), which is correctly attached to IOMMU group 7.
3. Possible fix: Update the smmu test script to recognize that V4L2 video sub-devices do not require separate IOMMU group entries — verify only the parent video-codec platform device attachment, or skip the sub-device check for qcs615-ride which uses qcom-venus driver.
4. Detail analysis attachment: failed_case_job269813_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: QCS615 platform does not support or has disabled EL2 (hypervisor mode); KVM driver initialization fails with "HYP mode not available" preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. Either: (1) Skip KVM tests on QCS615 platform in CI configuration, or (2) Enable EL2 support in bootloader/firmware if the SoC supports it, or (3) Use a different platform that supports virtualization for KVM testing.
4. Detail analysis attachment: failed_case_job269813_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform Hardware Limitation (EL2 Not Supported)

1. Failed case: KVM_EL2_DTB — Platform Hardware Limitation (EL2 Not Supported)
2. Root cause: The qcs615-ride board does not support ARM EL2 (hypervisor mode), causing KVM initialization to fail with "HYP mode not available" and preventing /dev/kvm device node creation. CONFIG_KVM is enabled in the kernel but the hardware/firmware does not provide EL2 capability.
3. Possible fix: Mark KVM tests as expected-to-fail or skip them for qcs615-ride in the LAVA job definition, as this SoC does not support virtualization. Alternatively, run KVM tests only on platforms with EL2 support (e.g., sm8450, sm8550, sa8775p).
4. Detail analysis attachment: failed_case_job269813_4_detailed.md

  Case 5: KVM_Infra (Platform Limitation — KVM Not Available)

1. Failed case: KVM_Infra (Platform Limitation — KVM Not Available)
2. Root cause: KVM initialization fails because the qcs615-ride platform is running with Gunyah hypervisor already occupying EL2, preventing the Linux kernel from initializing KVM; kernel logs show "kvm [1]: HYP mode not available" at boot, causing /dev/kvm device node creation to fail.
3. Possible fix: This is not a kernel bug or PR-introduced regression — it is a platform configuration issue. To enable KVM on this board, either: (1) disable the Gunyah hypervisor in the boot configuration to free EL2 for Linux KVM, or (2) mark KVM tests as expected-to-fail on qcs615-ride when Gunyah is enabled, or (3) use a different test platform that boots Linux directly at EL2 without an external hypervisor.
4. Detail analysis attachment: failed_case_job269813_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because the QCS615-ride platform does not have HYP (Hypervisor) mode available — kernel reports "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 pre-existing platform limitation, not a PR-introduced regression. The PR modifies only the Iris media driver (firmware debug logging) and has no connection to KVM/virtualization. To resolve: either (1) skip KVM tests on QCS615-ride in the CI test matrix since this SoC does not support virtualization in the current boot configuration, or (2) if virtualization support is expected, investigate the bootloader/firmware configuration to enable EL2/HYP mode on this platform.
4. Detail analysis attachment: failed_case_job269813_6_detailed.md

Job 269814 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check (suppressed - known benign)

1. Failed case: Probe_Failure_Check (suppressed - known benign)
2. Root cause: Test detected Bluetooth firmware load errors (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) and a regulatory database load error (regulatory.db), but these are known benign false positives. The BT_ON_OFF functional test passed, confirming Bluetooth firmware loaded correctly at runtime. The test probes firmware state before driver initialization completes.
3. Possible fix: No fix required. Apply suppression Rule 3 from lava-known-benign-failures.md: mark as "suppressed (known benign: bt firmware false positive — BT ON/OFF passed)". The regulatory.db error is also benign (from faux_driver test infrastructure).
4. Detail analysis attachment: failed_case_job269814_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device aa00000.video-codec on lemans-evk (iq-9075-evk) is not attached to an IOMMU group, causing the SMMU test's critical master validation to fail. This is a pre-existing platform/device-tree configuration issue, NOT introduced by PR Add firmware debug logging support for the qcom Iris driver #1416 (which only modifies Iris driver firmware debug logging).
3. Possible fix: This is a known platform limitation on lemans-evk where the video codec device lacks IOMMU group attachment in the device tree. The test failure is a false positive for this PR — the PR changes are limited to Iris driver firmware logging and do not affect IOMMU/SMMU configuration. Suppress this test failure for lemans-evk or update the device tree to add IOMMU bindings for the video codec device at aa00000.video-codec.
4. Detail analysis attachment: failed_case_job269814_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test framework marked the test definition as "unfinished" because the test runner script sent <LAVA_SIGNAL_STARTRUN> but never sent the required <LAVA_SIGNAL_ENDRUN> signal, even though all 20 individual test cases passed successfully and the test runner printed <LAVA_TEST_RUNNER EXIT>.
3. Possible fix: Update the qcom-linux-testkit test runner script to emit <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests 269814_1.1.3.1> after all tests complete and before printing <LAVA_TEST_RUNNER EXIT>, or investigate why the existing ENDRUN signal emission is being skipped or suppressed in the lemans-evk test flow.
4. Detail analysis attachment: failed_case_job269814_3_detailed.md

Job 269815 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: ath11k_pci WiFi driver probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2: ENOENT), causing MHI power-up timeout (error -110: ETIMEDOUT) on monaco-evk platform with WCN6855 hw2.1 WiFi chip.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/), or if the file exists upstream, ensure the Yocto build includes the correct linux-firmware package version that contains this board-specific firmware variant for nfa765.
4. Detail analysis attachment: failed_case_job269815_1_detailed.md

  Case 2: WiFi Driver Probe Failure — Firmware Missing

1. Failed case: WiFi Driver Probe Failure — Firmware Missing
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (/lib/firmware/). The MHI firmware load failed with -2 (ENOENT), causing the WiFi chip initialization to time out. This is a board-specific firmware packaging issue for monaco-evk, not a kernel regression introduced by the PR (which only modifies video codec driver).
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/. The firmware should be sourced from the linux-firmware repository or Qualcomm's board support package for monaco-evk/nfa765. Update the Yocto recipe or rootfs build configuration to include the WCN6855 hw2.1 nfa765 firmware variant.
4. Detail analysis attachment: failed_case_job269815_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/), or if the firmware package is available, ensure the linux-firmware-ath11k or equivalent package for WCN6855/nfa765 variant is installed in the Yocto build configuration.
4. Detail analysis attachment: failed_case_job269815_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 runner completed and exited normally after running all available tests, but LAVA infrastructure marked the test definition as failed with "Marking unfinished test run as failed" because the test duration (465.29s) or test completion state did not match LAVA's expectations for a complete test run.
3. Possible fix: This is a LAVA test infrastructure configuration issue, not a kernel regression. The test runner executed successfully and all individual test cases that ran reported their results correctly. Re-trigger the LAVA job to verify if this is a transient infrastructure issue. If the issue persists, review the LAVA job definition's test timeout settings and the test runner's exit conditions to ensure they align with the expected test suite completion criteria.
4. Detail analysis attachment: failed_case_job269815_4_detailed.md

[Salendarsingh Gaud (sgaud-quic)]

Mainline PR is open : qualcomm-linux/kernel-topics#2057