Revert SCMI for qcom-6.18.y

[Salendarsingh Gaud (sgaud-quic)]

Out of tree module compilation is failing as this series moves the governor.h header.

INFO - | governor_gpubw_mon.c:14:10: fatal error: governor.h: No such file or directory
INFO - | 14 | #include "governor.h"

Reverting the series for now, and will be brought back with proper fix.

[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.

[qcomlnxci]

Test jobs on 0e6abfd

• multimedia Job 223464 on hamoa-iot-evk
• multimedia Job 223461 on lemans-evk
• multimedia Job 223465 on monaco-evk
• multimedia Job 223466 on purwa-iot-evk
• multimedia Job 223460 on qcs615-ride
• multimedia Job 223462 on qcs6490-rb3gen2
• multimedia Job 223468 on qcs8300-ride
• multimedia Job 223463 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223467 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	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
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	❌ Fail	❌ 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
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[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.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1081

Job 223460 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: No fix required. Apply suppression rule per lava-known-benign-failures.md Rule 2: "Suppress firmware load failure if WiFi ON/OFF functional test passes." The test framework should exclude this pattern from failure reporting when WiFi functional tests pass.
4. Detail analysis attachment: failed_case_job223460_1_detailed.md

  Case 2: smmu — Test Expectation Mismatch (Not a Kernel Issue)

1. Failed case: smmu — Test Expectation Mismatch (Not a Kernel Issue)
2. Root cause: The SMMU test expects video-decoder and video-encoder to be separate platform devices with individual IOMMU group attachments, but the qcom-venus driver on qcs615-ride uses "non-legacy binding" where video-decoder and video-encoder are V4L2 video devices (not platform devices) that inherit IOMMU protection from the parent aa00000.video-codec device (which is correctly attached to IOMMU group 7).
3. Possible fix: Update the SMMU test to recognize that for Venus video codec with non-legacy binding, only the parent video-codec device needs IOMMU group attachment; video-decoder and video-encoder are V4L2 devices that inherit protection from the parent and should not be checked as separate platform devices.
4. Detail analysis attachment: failed_case_job223460_2_detailed.md

  Case 3: KVM_Driver — KVM unavailable due to Gunyah hypervisor occupying EL2

1. Failed case: KVM_Driver — KVM unavailable due to Gunyah hypervisor occupying EL2
2. Root cause: KVM cannot initialize on QCS615-ride because the Gunyah hypervisor is already running at EL2 (Hypervisor mode). ARM64 architecture allows only one hypervisor to control EL2 at a time. KVM detected this condition and correctly reported "HYP mode not available", preventing /dev/kvm creation. This is an expected architectural limitation, not a kernel bug.
3. Possible fix: This is a test environment configuration issue, not a PR-introduced regression. The PR reverts SCMI memlat devfreq changes and does not modify KVM or virtualization code. To resolve: (1) Skip KVM tests on platforms configured with Gunyah hypervisor, OR (2) Boot the platform without Gunyah if KVM testing is required, OR (3) Mark KVM tests as "expected skip" on Gunyah-enabled platforms in the LAVA test definition.
4. Detail analysis attachment: failed_case_job223460_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Suppress KVM_EL2_DTB test on qcs615-ride (and all Gunyah-enabled platforms) in the LAVA test suite. Add platform detection logic to skip KVM tests when Gunyah hypervisor is detected. Alternatively, if KVM functionality is required on this platform, reconfigure the boot chain to load KVM instead of Gunyah (requires bootloader/firmware changes and is a platform-level decision, not a kernel fix).
4. Detail analysis attachment: failed_case_job223460_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — /dev/kvm not available

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm not available
2. Root cause: KVM initialization failed because EL2/HYP mode is occupied by the Gunyah hypervisor (gunyah-1cb9db980) running on QCS615. The kernel message "kvm [1]: HYP mode not available" indicates KVM detected EL2 is unavailable, preventing /dev/kvm device creation. This is expected behavior on Qualcomm platforms using Gunyah for virtualization; KVM and Gunyah cannot coexist as both require exclusive EL2 access.
3. Possible fix: Disable KVM tests for QCS615 platform in the LAVA test suite configuration, as this platform uses Gunyah hypervisor and does not support KVM. Alternatively, if KVM support is required, rebuild the firmware without Gunyah hypervisor (not recommended for production Qualcomm platforms). This is a platform limitation, not a kernel regression — the PR changes (SCMI/devfreq reverts) are unrelated to KVM functionality.
4. Detail analysis attachment: failed_case_job223460_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 platform hardware limitation, not a kernel regression. The KVM_Infra test should be excluded from the CI test suite for QCS615 targets, or the test should be updated to skip gracefully on platforms without EL2 support. The PR changes (reverting SCMI memlat/devfreq) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job223460_6_detailed.md

Job 223461 | SoC lemans-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Test infrastructure false positive. The test flagged three benign conditions as failures: (1) Bluetooth firmware fallback to alternate paths (functional — BT_ON_OFF passed with 100% success), (2) regulatory.db firmware fallback to built-in database (expected kernel behavior for embedded systems), and (3) temp-alarm deferred probe warnings (normal probe ordering mechanism on lemans-evk, not hard failures). No genuine kernel probe failure occurred; all functional tests passed.
3. Possible fix: Update the Probe_Failure_Check test script to suppress known benign firmware fallback patterns (regulatory.db error -2, Bluetooth firmware when BT_ON_OFF passes) and distinguish deferred probe warnings from hard probe failures. Add lemans-evk-specific suppression for the four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) if they are confirmed to remain deferred without functional impact on this platform.
4. Detail analysis attachment: failed_case_job223461_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec at address 0xaa00000 is not attached to any IOMMU group on lemans-evk, indicating missing or incomplete device tree IOMMU bindings for this critical master device.
3. Possible fix: Add the missing iommus property to the video-codec device tree node in the lemans-evk DTS file to bind it to the appropriate SMMU context bank, following the pattern used by other critical masters (GPU, USB, Display) that successfully attach to IOMMU groups.
4. Detail analysis attachment: failed_case_job223461_2_detailed.md

  Case 3: 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 not a genuine failure requiring a fix. The wrapper case failure is a LAVA orchestration artifact that reflects the sub-test failures. Investigate and fix the actual failed sub-tests: (1) Probe_Failure_Check (case ID 1, line 5230) and (2) smmu (case ID 2, line 5430). Once those are resolved, this wrapper case will automatically pass.
4. Detail analysis attachment: failed_case_job223461_3_detailed.md

Job 223462 | SoC qcs6490-rb3gen2

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

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

  Case 1: ** Probe_Failure_Check (Test Infrastructure False Positive)

1. Failed case: ** Probe_Failure_Check (Test Infrastructure False Positive)
2. Root cause: ** The Probe_Failure_Check test incorrectly flags expected platform behavior as failures: (1) audio device deferred probes are normal on qcs6490-rb3gen2 where audio card registration is not supported (Audio_Card_Registration: SKIP), and (2) regulatory.db firmware load failure is benign as WiFi operates correctly using built-in regulatory data (WiFi_Firmware_Driver: PASS, WiFi_OnOff: PASS).
3. Possible fix: Update the Probe_Failure_Check test to suppress known-benign patterns: (1) exclude deferred probe warnings for audio devices (soundwire, codec, pinctrl) on qcs6490-rb3gen2, and (2) exclude regulatory.db firmware load failures when WiFi functional tests pass. Alternatively, adjust the test to only flag hard probe failures (probe of .* failed with error -) rather than deferred probes and optional firmware warnings.
4. Detail analysis attachment: failed_case_job223462_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test environment issue — no USB device physically connected to the qcs6490-rb3gen2 board during test execution. The kernel USB subsystem initialized correctly (usbcore registered, USB HID driver loaded), but the USBHost test script found zero enumerated USB devices when querying the system, indicating no external USB device was plugged into the board's USB host port.
3. Possible fix: This is not a kernel regression. Verify the LAVA lab setup for qcs6490-rb3gen2 includes a USB device (e.g., USB flash drive, USB keyboard, or USB hub) connected to the board's USB host port before test execution. If the test is optional when no USB device is available, update the test script to report SKIP instead of FAIL when no devices are found.
4. Detail analysis attachment: failed_case_job223462_2_detailed.md

  Case 3: KVM Driver Initialization Failure — HYP mode unavailable

1. Failed case: KVM Driver Initialization Failure — HYP mode unavailable
2. Root cause: KVM driver probe failed at boot because EL2 (HYP mode) is already occupied by the Gunyah hypervisor running on qcs6490-rb3gen2. The kernel message kvm [1]: HYP mode not available at [3.389847] indicates KVM cannot initialize when another hypervisor controls EL2. This is a platform configuration constraint, not a kernel regression.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms. To enable KVM testing: (1) use a non-Gunyah firmware build that leaves EL2 available for Linux KVM, or (2) exclude KVM tests from the CI test suite for Gunyah-based platforms (rb3gen2 with Gunyah firmware), or (3) add a test skip condition that detects Gunyah presence (dmesg | grep -q "Gunyah based bootup") and skips KVM tests accordingly.
4. Detail analysis attachment: failed_case_job223462_3_detailed.md

  Case 4: KVM Driver Initialization Failure — /dev/kvm not available (HYP mode not available)

1. Failed case: KVM Driver Initialization Failure — /dev/kvm not available (HYP mode not available)
2. Root cause: The qcs6490-rb3gen2 platform's bootloader (ABL) boots Linux at EL1 without enabling EL2 (hypervisor mode) access. The KVM driver detected this condition during initialization (kvm [1]: HYP mode not available at boot time) and skipped device node creation, causing all KVM tests to fail at the availability gate.
3. Possible fix: Short-term: Exclude KVM tests from the qcs6490-rb3gen2 CI test suite by updating the LAVA job definition to skip Virtualization/KVM/* tests, as this platform does not currently support EL2. Long-term: Modify the ABL bootloader configuration to enable EL2 access for Linux (either boot at EL2 or enable HVC-based EL2 transitions from EL1), rebuild and flash the updated bootloader, then verify /dev/kvm is created and KVM tests pass.
4. Detail analysis attachment: failed_case_job223462_4_detailed.md

  Case 5: KVM_Infra — Platform Limitation (Gunyah Hypervisor Conflict)

1. Failed case: KVM_Infra — Platform Limitation (Gunyah Hypervisor Conflict)
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the Gunyah hypervisor is already running at EL2 (HYP mode), preventing KVM from accessing the required privilege level for virtualization.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms. To resolve: (1) disable the KVM_Infra test for qcs6490-rb3gen2 in the LAVA test suite, or (2) if KVM functionality is required, boot the platform without Gunyah hypervisor (requires bootloader/firmware configuration change to disable Gunyah and allow direct EL2 access).
4. Detail analysis attachment: failed_case_job223462_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: qcs6490-rb3gen2 platform does not support ARM virtualization extensions (EL2/HYP mode); kernel correctly reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm creation.
3. Possible fix: Exclude KVM tests from qcs6490-rb3gen2 CI runs, or mark them as expected-to-skip on platforms without virtualization support; this is not a kernel bug but a hardware limitation.
4. Detail analysis attachment: failed_case_job223462_6_detailed.md

Job 223463 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update qcs9100-ride device tree to add thermal zone bindings for all four PMIC temp-alarm nodes (resolve deferred probe), add the missing firmware-name property to the Aquantia PHY node or patch the driver to make it optional, and either add regulatory.db to rootfs or suppress this error in the Probe_Failure_Check test as a known benign failure. These are platform configuration gaps on qcs9100-ride, not regressions from PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat patches). PR Revert SCMI for qcom-6.18.y #1081 should proceed; these issues require separate platform enablement work.
4. Detail analysis attachment: failed_case_job223463_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec exists in device tree but is not attached to any IOMMU group, indicating either the video codec driver failed to probe or the device tree is missing the iommus property for this device on qcs9100-ride platform.
3. Possible fix: Verify video codec driver probe status in dmesg; if driver did not probe, investigate driver dependencies and firmware requirements; if driver probed but device is not in an IOMMU group, add the missing iommus property to the aa00000.video-codec device tree node referencing the appropriate SMMU instance.
4. Detail analysis attachment: failed_case_job223463_2_detailed.md

  Case 3: ** USBHost (Test Infrastructure / Hardware Dependency Failure)

1. Failed case: ** USBHost (Test Infrastructure / Hardware Dependency Failure)
2. Root cause: ** The USBHost test expects at least one functional USB device (keyboard, mouse, storage, etc.) to be physically connected to the qcs9100-ride board's USB ports to validate USB host functionality. Only USB root hubs (Bus 001, 002, 003 - Linux Foundation 2.0/3.0 root hubs) are enumerated, indicating no external USB devices are connected to the lab board. This is a test infrastructure/hardware setup issue, not a kernel regression. The USB host controllers initialized successfully (3 xHCI buses registered), drivers loaded correctly, and IOMMU protection is in place.
3. Possible fix: Connect a functional USB device (USB flash drive, keyboard, or mouse) to one of the USB ports on the qcs9100-ride lab board before running the USBHost test. If the lab setup intentionally has no USB devices, mark this test as SKIP or adjust the test expectation to validate only USB controller initialization rather than requiring enumerated devices.
4. Detail analysis attachment: failed_case_job223463_3_detailed.md

  Case 4: ** Ethernet_Basic_Validation — PHY Attachment Failure (Driver Probe Issue)

1. Failed case: ** Ethernet_Basic_Validation — PHY Attachment Failure (Driver Probe Issue)
2. Root cause: ** The qcom-ethqos driver for interface end0 (23040000.ethernet) on qcs9100-ride board cannot attach to its PHY during interface bring-up, failing with -EINVAL. This indicates an invalid or missing PHY configuration in the device tree (incorrect phy-handle phandle, missing PHY node, wrong PHY compatible string, or disabled PHY node), or the required PHY driver (likely qca808x) is not loaded. This is a pre-existing board/DT configuration issue specific to the qcs9100-ride LAVA target, not a regression introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat changes unrelated to Ethernet).
3. Possible fix: Verify and correct the device tree configuration for 23040000.ethernet on qcs9100-ride: (1) Confirm the phy-handle property points to a valid, enabled PHY node with correct compatible string and MDIO address. (2) Ensure the required PHY driver (CONFIG_QCA808X_PHY or equivalent) is built and loaded before interface bring-up. (3) Check MDIO bus enumeration logs to confirm the PHY is detected at the expected address. If the DT is correct, investigate whether the PHY hardware is present and functional on this specific board instance. This is a board-specific infrastructure issue that should be triaged separately from PR validation and should NOT block PR Revert SCMI for qcom-6.18.y #1081.
4. Detail analysis attachment: failed_case_job223463_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver cannot initialize because the qcs9100-ride (LeMans Ride Rev3) platform boots Linux at EL1 without EL2/HYP mode access. Kernel message kvm [1]: HYP mode not available at boot time [3.866636] indicates the CPU is not running in hypervisor mode, preventing /dev/kvm device creation. This is a platform firmware/bootloader configuration limitation, not a kernel regression.
3. Possible fix: This is not a PR-introduced regression (PR Revert SCMI for qcom-6.18.y #1081 contains only SCMI config reverts). To enable KVM on qcs9100-ride: (1) Configure the bootloader (ABL/UEFI) to boot Linux at EL2 instead of EL1, OR (2) Enable VHE (Virtualization Host Extensions) if supported by the SoC and ensure the bootloader enables it, OR (3) If EL2 is reserved for Gunyah hypervisor, this is a platform design choice and KVM cannot be used. For CI: suppress KVM tests on qcs9100-ride or mark as expected-fail until platform firmware is updated to support EL2 boot.
4. Detail analysis attachment: failed_case_job223463_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: Skip KVM tests on platforms with hypervisor enabled, or run KVM tests on a platform configuration without Gunyah hypervisor. Update the LAVA test job definition to check for hypervisor presence before running KVM tests, or add a test prerequisite that excludes hypervisor-enabled platforms from the KVM test suite.
4. Detail analysis attachment: failed_case_job223463_6_detailed.md

  Case 7: KVM_Infra — KVM/ARM Virtualization Not Available

1. Failed case: KVM_Infra — KVM/ARM Virtualization Not Available
2. Root cause: KVM ARM driver initialization failed during boot because HYP mode (EL2) is not available on the qcs9100-ride platform. The kernel log shows kvm [1]: HYP mode not available at boot time (line 3126), indicating the CPU is not running in or cannot access EL2 (hypervisor exception level). CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware does not provide the necessary virtualization support for KVM to initialize.
3. Possible fix: This is a platform limitation, not a PR-introduced regression. The qcs9100-ride (LeMans) platform either: (1) does not support EL2/virtualization in hardware, (2) has EL2 disabled in the bootloader/firmware configuration, or (3) is running under a hypervisor that has not delegated nested virtualization. To enable KVM on this platform: verify the SoC supports ARMv8 virtualization extensions, ensure the bootloader (ABL/XBL) boots the kernel at EL2 (not EL1), and if running under a hypervisor, enable nested virtualization support. If the platform fundamentally does not support EL2, mark KVM tests as "not applicable" for this SoC in the CI test matrix.
4. Detail analysis attachment: failed_case_job223463_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; kernel boot log shows kvm [1]: HYP mode not available at boot, indicating the qcs9100-ride platform either does not support ARM virtualization extensions (EL2/HYP mode) or EL2 is disabled in firmware/bootloader configuration.
3. Possible fix: This is a platform limitation, not a PR-introduced regression (the PR only reverts SCMI memlat devfreq changes unrelated to KVM). Mark KVM tests as "not applicable" for qcs9100-ride in the CI test plan, or enable EL2 in the platform firmware if the SoC supports virtualization extensions.
4. Detail analysis attachment: failed_case_job223463_8_detailed.md

Job 223464 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing probe failures unrelated to PR changes: (1) qcom_qseecom_uefisecapp probe fails with -EBUSY due to TrustZone resource conflict on hamoa-evk, (2) qcom-spmi-lpg probe fails with -EINVAL due to invalid multi-LED DT reg property, (3) regulatory.db firmware load fails with -ENOENT (benign, cfg80211 continues without it). None of these failures are introduced by the PR, which only reverts SCMI memlat devfreq changes that do not touch qseecom, spmi-lpg, or cfg80211 subsystems.
3. Possible fix: These are pre-existing platform issues, not PR regressions. To resolve: (1) For qseecom: investigate TrustZone firmware version and secure app availability on hamoa-evk; may require firmware update or DT node removal if UEFI secure app is not supported on this platform. (2) For spmi-lpg: fix the DT multi-LED reg property in hamoa PMIC node to match driver expectations. (3) For regulatory.db: install wireless-regdb package in rootfs or suppress this benign warning in the test filter. The PR can proceed as these failures exist independently of the reverted changes.
4. Detail analysis attachment: failed_case_job223464_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test script expects IOMMU group attachment for USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec), but these devices either do not require IOMMU protection (PHYs are not DMA masters) or have not probed successfully (video codec). The PR changes (SCMI memlat revert) do not affect IOMMU configuration; this is a pre-existing test expectation mismatch or missing DT iommus properties for the video codec on hamoa-evk.
3. Possible fix: Update the smmu test script to exclude USB PHY devices (addresses ending in f8800) from the critical master check, as PHYs are not DMA-capable. For the video codec (aa00000.video-codec), verify the device tree includes the iommus property and that the driver probes successfully; if the device is not functional on hamoa-evk, exclude it from the test or mark it as platform-specific expected failure.
4. Detail analysis attachment: failed_case_job223464_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: Exclude the KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests from the LAVA test suite for the Hamoa IoT EVK platform. Add a platform capability check to the test suite to skip KVM tests when EL2 is not available by checking for the kernel message HYP mode not available or the absence of /dev/kvm. Alternatively, if EL2 support is expected on this platform, investigate the bootloader/firmware configuration to ensure the kernel is booted with EL2 access enabled.
4. Detail analysis attachment: failed_case_job223464_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the kernel is running as a guest under the Gunyah hypervisor (nested virtualization), which does not expose EL2/HYP mode to the guest kernel. The message "kvm [1]: HYP mode not available" indicates KVM detected it cannot access hypervisor mode.
3. Possible fix: This is a test environment limitation, not a kernel bug. The KVM_EL2_DTB test (and all KVM tests) should be skipped on hamoa-evk when running under Gunyah hypervisor. Add a test precondition check for Gunyah presence (check for "Gunyah based bootup" in dmesg or /sys/firmware/devicetree/base/gunyah-hyp node) and skip KVM tests when detected.
4. Detail analysis attachment: failed_case_job223464_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on hamoa-evk because the platform runs under Gunyah hypervisor (Type-1 hypervisor) which already owns EL2 (HYP mode). The kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device creation. This is a pre-existing platform architectural limitation, not a regression introduced by PR Revert SCMI for qcom-6.18.y #1081 (which contains only SCMI memlat config reverts unrelated to KVM).
3. Possible fix: Mark KVM_Infra, KVM_Driver, and KVM_EL2_DTB tests as expected failures (XFAIL) or skip them entirely for hamoa-evk in the LAVA test definition, since nested virtualization (KVM under Gunyah) is not supported on this platform. Alternatively, run KVM tests only on platforms without a Type-1 hypervisor (e.g., bare-metal or platforms where Linux runs at EL2).
4. Detail analysis attachment: failed_case_job223464_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present. The kernel reports "kvm [1]: HYP mode not available" during boot, indicating the CPU is not running in EL2 (hypervisor exception level), which is a prerequisite for KVM functionality on ARM64. This is a platform/firmware configuration issue on hamoa-evk, not a kernel regression.
3. Possible fix: This is not a PR-introduced issue (the PR contains only devfreq/SCMI config reverts unrelated to KVM). The failure is due to the hamoa-evk platform not booting in EL2 mode. To enable KVM: (1) verify the bootloader (ABL/UEFI) is configured to boot the kernel in EL2 mode, (2) check if the platform firmware supports EL2/virtualization extensions, (3) if this is a known platform limitation, mark KVM tests as expected-fail for hamoa-evk in the LAVA job definition.
4. Detail analysis attachment: failed_case_job223464_6_detailed.md

Job 223465 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check — WiFi Driver Probe Failure (Firmware Missing)

1. Failed case: ** Probe_Failure_Check — WiFi Driver Probe Failure (Firmware Missing)
2. Root cause: ** ath11k_pci WiFi driver probe failed with -ETIMEDOUT because required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ directory. This is a pre-existing build configuration issue where WiFi firmware files are not packaged in the Yocto image for monaco-evk (iq-8275-evk board).
3. Possible fix: Add linux-firmware-ath11k package (or equivalent firmware files) to the Yocto image recipe for monaco-evk. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related WiFi firmware files are included in /lib/firmware/ in the rootfs. This is a build/integration fix, not a kernel code fix.
4. Detail analysis attachment: failed_case_job223465_1_detailed.md

  Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure with -ETIMEDOUT

1. Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure with -ETIMEDOUT
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk due to missing WiFi firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) combined with PCIe link instability (continuous AER correctable errors: RxErr, Timeout, Rollover, BadTLP, BadDLLP) indicating the WCN6855 WiFi module failed to initialize properly over PCIe during MHI power-on sequence.
3. Possible fix: Ensure the WiFi firmware package for WCN6855 hw2.1 (nfa765 variant) is installed in the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin. If firmware is present but probe still fails, investigate PCIe link training and signal integrity on monaco-evk hardware — the persistent AER correctable errors (RxErr/Timeout) suggest either a board-level PCIe signal integrity issue, incorrect PCIe reference clock configuration, or a power sequencing problem for the WCN6855 module on this specific monaco-evk board revision.
4. Detail analysis attachment: failed_case_job223465_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 Yocto/build recipe that packages WiFi firmware for monaco-evk. Verify the linux-firmware package or equivalent includes the WCN6855 hw2.1 nfa765 variant firmware. Re-trigger the CI job after the firmware is added to the build image.
4. Detail analysis attachment: failed_case_job223465_3_detailed.md

  Case 4: ** WiFi PCIe Driver Probe Failure (ath11k_pci)

1. Failed case: ** WiFi PCIe Driver Probe Failure (ath11k_pci)
2. Root cause: ** ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk WCN6855 WiFi hardware (PCIe device 0000:01:00.0). The probe timeout occurred during firmware loading phase, accompanied by continuous PCIe AER correctable errors (RxErr, Timeout, Rollover, BadTLP) indicating unstable PCIe link or device communication failure. Firmware files for WCN6855 hw2.1 nfa765 variant were not found (amss.bin returned -ENOENT), and the device failed to respond within the MHI (Modem Host Interface) timeout window.
3. Possible fix: This is a pre-existing hardware/firmware/infrastructure issue on the monaco-evk test board, not introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat config changes unrelated to WiFi/PCIe). Immediate action: verify WCN6855 firmware files are present in the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ and that the PCIe slot/card is properly seated. If firmware is missing, update the Yocto image recipe to include the correct ath11k firmware package. If PCIe link is unstable, check hardware connections and power supply to the WiFi module. Re-run the test after confirming firmware presence and hardware stability.
4. Detail analysis attachment: failed_case_job223465_4_detailed.md

Job 223466 | SoC purwa-evk

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

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

  Case 1: ** Driver Probe Failures — Platform-Specific Hardware Limitations

1. Failed case: ** Driver Probe Failures — Platform-Specific Hardware Limitations
2. Root cause: ** Five driver probe failures on purwa-evk (x5121) due to platform-specific hardware/firmware limitations: qcom_qseecom_uefisecapp (-EBUSY, secure world resource conflict), qcom-spmi-lpg (-EINVAL, invalid PWM channel configuration in DT), two qcom-pcie instances (-ENODATA, PCIe endpoints not populated on board), and regulatory.db firmware (-ENOENT, optional WiFi regulatory database not in rootfs). These are pre-existing platform characteristics not introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat config changes).
3. Possible fix: Suppress these five probe failures as known benign for purwa-evk in the Probe_Failure_Check test allowlist, as they represent expected hardware/firmware limitations on this platform and do not indicate kernel regressions. The PR changes (SCMI memlat reverts) do not touch any of the failing drivers (qseecom, spmi-lpg, pcie, cfg80211) and are unrelated to these probe failures.
4. Detail analysis attachment: failed_case_job223466_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Six USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec device (aa00000.video-codec) are missing IOMMU group attachments on purwa-evk, indicating incomplete device tree iommus property configuration for these platform devices.
3. Possible fix: Add missing iommus properties to the device tree nodes for the six USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) in arch/arm64/boot/dts/qcom/purwa*.dtsi, referencing the appropriate SMMU phandle and stream IDs, following the pattern used by the passing USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb).
4. Detail analysis attachment: failed_case_job223466_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize because the purwa-evk platform is running under the Gunyah hypervisor, which occupies EL2 (hypervisor mode). KVM requires exclusive access to EL2 and correctly detects this incompatibility, reporting "HYP mode not available" and refusing to create /dev/kvm.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The test failure is due to test environment misconfiguration. Fix: Either (1) disable KVM tests on platforms running under Gunyah hypervisor, or (2) configure the purwa-evk LAVA job to boot without the Gunyah hypervisor if KVM testing is required. The PR changes (reverting SCMI memlat devfreq patches) do not affect KVM functionality.
4. Detail analysis attachment: failed_case_job223466_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on purwa-evk because the Gunyah hypervisor is already running at EL2, preventing KVM from accessing HYP mode; kernel reports "kvm [1]: HYP mode not available" causing /dev/kvm device node creation to fail.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms. Either: (1) disable Gunyah hypervisor in the device tree and bootloader configuration if KVM testing is required, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms like purwa-evk, as KVM and Gunyah cannot coexist (both require exclusive EL2 access).
4. Detail analysis attachment: failed_case_job223466_4_detailed.md

  Case 5: KVM_Infra (also KVM_Driver and KVM_EL2_DTB - same root cause)

1. Failed case: KVM_Infra (also KVM_Driver and KVM_EL2_DTB - same root cause)
2. Root cause: KVM initialization failed because the kernel is running as a guest under the Gunyah hypervisor (not at EL2/HYP mode). The kernel message kvm [1]: HYP mode not available indicates the CPU is not in hypervisor exception level, which is required for KVM to function. On purwa-evk, the Gunyah hypervisor boots first and runs the Linux kernel as a guest VM at EL1, preventing KVM from accessing EL2 virtualization extensions.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat patches unrelated to virtualization). To enable KVM on purwa-evk: (1) configure the bootloader/firmware to boot Linux directly at EL2 without the Gunyah hypervisor, OR (2) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes), OR (3) mark KVM tests as expected-fail/skip for purwa-evk in the LAVA job definition since this platform is configured to run Linux as a guest under Gunyah.
4. Detail analysis attachment: failed_case_job223466_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on purwa-evk because the platform runs under the Gunyah hypervisor (gunyah-mobile-c487961e9), which occupies EL2 (hypervisor mode). KVM requires direct EL2 access to create virtual machines, but when a Type-1 hypervisor like Gunyah is present, EL2 is already claimed and nested virtualization is not supported on this platform.
3. Possible fix: This is not a bug — it is an expected platform limitation. The KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) should be skipped on platforms running under Gunyah or other Type-1 hypervisors. Update the LAVA test suite to detect hypervisor presence (check for "Hypervisor cold boot" in early boot logs or is_hyp_mode_available() in kernel) and skip KVM tests when a hypervisor is detected.
4. Detail analysis attachment: failed_case_job223466_6_detailed.md

Job 223467 | SoC shikra-iqs-evk

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

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

  Case 1: ** GIC (Test Script Bug — Not a Kernel Issue)

1. Failed case: ** GIC (Test Script Bug — Not a Kernel Issue)
2. Root cause: ** The GIC test script incorrectly parses /proc/interrupts by attempting to read beyond the actual CPU count columns (4 CPUs: 0-3 on shikra-iqs-evk). The script treats non-numeric fields ("GICv3", "19", "Level", "arch_timer") as if they were CPU interrupt counters for CPUs 4-7, causing bash integer comparison errors at line 75 of the test script.
3. Possible fix: Update the GIC test script (/lava-223467/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or parse only the numeric interrupt count columns from /proc/interrupts (columns 2 through N+1, where N is the CPU count), rather than blindly iterating through all whitespace-separated fields.
4. Detail analysis attachment: failed_case_job223467_1_detailed.md

  Case 2: Probe_Failure_Check — Pre-existing Platform Driver Probe Failures

1. Failed case: Probe_Failure_Check — Pre-existing Platform Driver Probe Failures
2. Root cause: The Probe_Failure_Check test detected seven pre-existing driver probe failures on shikra-iqs-evk that are unrelated to the PR changes (SCMI memlat revert series): coresight-etm4x ETM0-3 probe failures (-EINVAL), cpufreq-dt probe failure (-EEXIST indicating duplicate registration), lt9611c HDMI bridge probe failure (-EIO from I2C DMA transaction failure), regulatory.db firmware missing (-ENOENT), and three deferred probe warnings for audio subsystem (sound card CPU DAI name resolution, I2C device 3-0010, va_macro mclk clock dependency).
3. Possible fix: Mark this test failure as a known platform issue unrelated to PR Revert SCMI for qcom-6.18.y #1081. The PR only reverts SCMI memlat/devfreq changes and does not touch coresight, cpufreq, display bridge, wireless regulatory, or audio codec drivers. These probe failures existed before the PR and require separate investigation: (1) coresight-etm4x: investigate ETM device tree configuration or driver compatibility with shikra SoC; (2) cpufreq-dt: check for duplicate cpufreq policy registration in platform code; (3) lt9611c: debug I2C GPI DMA transaction failures on bus 4-0041; (4) regulatory.db: add firmware file to rootfs or mark as optional; (5) audio deferred probes: verify clock/codec dependencies in device tree. Approve PR Revert SCMI for qcom-6.18.y #1081 for merge as these failures are orthogonal to the changes.
4. Detail analysis attachment: failed_case_job223467_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 a known test infrastructure limitation, not a kernel bug. The test should either: (1) be marked as SKIP when no USB device is detected (similar to Ethernet_Basic_Validation which skips when no cable is connected), or (2) require a USB device to be physically connected to the board's USB host port before running the test suite. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job223467_3_detailed.md

  Case 4: BT_SCAN (suppressed - known benign failure)

1. Failed case: BT_SCAN (suppressed - known benign failure)
2. Root cause: Test infrastructure issue — BT_SCAN failed to discover nearby Bluetooth devices despite Bluetooth hardware and driver functioning correctly (BT_ON_OFF passed, confirming hci0 adapter is operational and can power on/off successfully). The scan test relies on external Bluetooth devices being present in the lab environment for discovery, which is an environmental dependency unrelated to kernel functionality.
3. Possible fix: This failure is suppressed per LAVA Known Benign Failure Suppression Rule 3: "BT firmware/scan failures are suppressed when BT_ON_OFF functional test passes." No kernel fix required — the Bluetooth stack is working correctly. If BT_SCAN validation is required, ensure a known Bluetooth beacon/device is powered on and within range of the test board in the LAVA lab environment.
4. Detail analysis attachment: failed_case_job223467_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a board-specific hardware/firmware configuration issue on Shikra IQS EVK. Immediate mitigation: disable the qcom_hwrng test on Shikra until the RNG hardware path is validated. Long-term fix: (1) Verify the RNG MMIO region (likely 0x793000 or similar per QCM2290 spec) is correctly mapped in the device tree with proper clocks/power-domains; (2) Confirm the RNG hardware block is powered and clocked during the test; (3) Check if firmware/TZ has disabled or restricted access to the RNG registers on this board variant. The KVM_Driver test failure (missing /dev/kvm) is a separate issue — likely CONFIG_KVM_ARM_MODE_PROTECTED or missing hypervisor support on this platform.
4. Detail analysis attachment: failed_case_job223467_5_detailed.md

  Case 6: Kernel Crash — Synchronous External Abort (secondary symptom: KVM_EL2_DTB test failure due to post-crash reboot)

1. Failed case: Kernel Crash — Synchronous External Abort (secondary symptom: KVM_EL2_DTB test failure due to post-crash reboot)
2. Root cause: System crashed during qcom_hwrng test execution when qcom_rng driver attempted MMIO read from RNG hardware registers, triggering synchronous external abort (ESR 0x96000010) at PC qcom_rng_read+0xc4. The crash caused kernel panic and system reboot. KVM_EL2_DTB test ran after reboot and failed because /dev/kvm device node was not present, indicating KVM driver did not initialize properly post-crash. This is a pre-existing hardware/driver issue on Shikra IQS EVK, not introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat devfreq patches unrelated to RNG or KVM).
3. Possible fix: Investigate qcom_rng driver hardware access at offset +0xc4 in qcom_rng_read() for Shikra platform. Check if RNG hardware block is properly powered/clocked and accessible via MMIO. Verify device tree RNG node register base address and size match hardware specification. Add error handling for hardware access faults. Consider disabling qcom_hwrng test on Shikra until root cause is resolved, as this is a known platform-specific hardware access issue unrelated to the PR changes.
4. Detail analysis attachment: failed_case_job223467_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: For the KVM_Infra test: Suppress this test on shikra-iqs-evk or update the test to handle platforms where KVM cannot initialize (e.g., check for EL2 availability before failing). For the qcom_hwrng crash: Investigate the shikra-iqs-evk device tree and platform configuration to ensure the RNG hardware block has correct clock/power domain/reset configuration. Add runtime PM calls or clock enablement in the qcom_rng driver's read path if missing, or disable the qcom_hwrng test on this platform until the hardware configuration is fixed.
4. Detail analysis attachment: failed_case_job223467_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 (qcom_rng) driver triggered a synchronous external abort at offset 0xc4 in qcom_rng_read() when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The abort indicates the hardware RNG block is either not powered, not clocked, or the MMIO address mapping is incorrect for the shikra-iqs-evk platform, causing a bus-level fault when the driver attempted to read hardware registers.
3. Possible fix: Verify the qcom_rng device tree node for shikra-iqs-evk has correct MMIO base address, clock references, and power domain assignments. Cross-check against hardware documentation for the Shikra SoC RNG block. If DT is correct, investigate whether the RNG hardware block requires additional platform-specific initialization (secure firmware configuration, reset sequencing, or interconnect path enablement) that is missing for this platform.
4. Detail analysis attachment: failed_case_job223467_8_detailed.md

  Case 9: Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: The qcom_rng driver triggered a synchronous external abort at PC qcom_rng_read+0xc4 when attempting to read from the hardware RNG device during the qcom_hwrng test execution. The fault indicates an invalid physical address access or a hardware/bus configuration issue preventing the CPU from accessing the RNG hardware registers. The board subsequently rebooted, causing the lava-test-shell to timeout after 2400 seconds when the test suite never completed.
3. Possible fix: This is a pre-existing hardware/platform issue unrelated to PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat config changes). Investigate the qcom_rng device tree configuration for shikra-iqs-evk: verify the RNG register base address and clocks/power-domains are correctly specified. Check if the RNG hardware block requires explicit power-on or clock enablement that is missing in the current DT. As a short-term mitigation, disable the qcom_hwrng test case for shikra-iqs-evk until the platform DT/firmware is corrected.
4. Detail analysis attachment: failed_case_job223467_9_detailed.md

  Case 10: ** Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: ** Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: ** The qcom_rng driver attempted to read from a memory-mapped hardware register (MMIO base 0xffff800082d05000) that is not responding on the bus, triggering a synchronous external abort and kernel panic. This indicates the hardware RNG block is not powered, clocked, or accessible when the driver attempts runtime operation. The crash is a pre-existing platform/driver issue on shikra-iqs-evk, not introduced by the PR (which reverts unrelated SCMI memlat devfreq patches for hamoa SoC).
3. Possible fix: Investigate and fix the qcom_rng driver's runtime power management for shikra platform. Immediate mitigation: disable the qcom_hwrng test on shikra-iqs-evk CI runs until the driver is fixed. Proper fix requires: (1) verify device tree configuration for RNG hardware block on shikra (clocks, power-domains, interconnects), (2) audit qcom_rng driver runtime PM implementation to ensure hardware is correctly powered/clocked before register access, (3) add runtime PM callbacks if missing, or fix existing callbacks to enable all required resources.
4. Detail analysis attachment: failed_case_job223467_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 register access fault in qcom_rng_read() at offset +0xc4 during qcom_hwrng test execution. The synchronous external abort (ESR 0x96000010) indicates an invalid physical address access or unpowered/unconfigured hardware block when the driver attempted to read from the RNG MMIO region. This is a hardware/firmware/device-tree configuration issue on the shikra-iqs-evk platform, not introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat config changes unrelated to RNG).
3. Possible fix: Verify the qcom_rng device tree node in arch/arm64/boot/dts/qcom/shikra*.dts* has correct reg property matching the SoC memory map, confirm the RNG hardware block is powered and clocked (check power-domains and clocks properties), and validate that the RNG MMIO region is accessible at the specified address. If the hardware is not present or not functional on shikra-iqs-evk, disable the qcom_rng node in the device tree with status = "disabled"; or skip the qcom_hwrng test for this platform.
4. Detail analysis attachment: failed_case_job223467_11_detailed.md

Job 223468 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Aquantia AQR115C Ethernet PHY driver probe failed with error -22 (-EINVAL) during boot at 12.153s due to missing or malformed firmware-name device tree property; the driver attempted to read the firmware-name property and received -EINVAL, causing probe to abort and leaving the eth0 interface non-functional on qcs8300-ride.
3. Possible fix: Add the missing firmware-name device tree property to the Aquantia AQR115C PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts (or the appropriate qcs8300 board DTS file). The property should specify the firmware file path expected by the Aquantia PHY driver, typically in the format firmware-name = "aquantia/AQR-G4_v5.4.C-AQR_CIG_WF-1.8.0.cld"; or similar, matching the firmware files available in the kernel firmware tree or linux-firmware repository. Verify the correct firmware filename by checking drivers/net/phy/aquantia/aquantia_firmware.c and the available firmware files.
4. Detail analysis attachment: failed_case_job223468_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB hub with downstream devices) to the qcs8300-ride board's USB host port before running the USBHost test. If the board is in a remote LAVA lab, coordinate with lab administrators to ensure USB test hardware is physically connected to the board. Alternatively, mark this test as "skip" or "expected fail" for boards without USB test peripherals attached.
4. Detail analysis attachment: failed_case_job223468_2_detailed.md

  Case 3: ** Ethernet Driver Initialization Failure — PHY Attachment Validation Error

1. Failed case: ** Ethernet Driver Initialization Failure — PHY Attachment Validation Error
2. Root cause: ** The qcom-ethqos Ethernet driver on qcs8300-ride fails to attach to the PHY during interface bring-up due to phylink validation rejecting the 2500base-x link mode configuration. The PHY advertised capabilities (0x000062c0) do not match the MAC supported capabilities (0x000062cc), causing phylink_validate() to return -EINVAL. This is a pre-existing device tree or PHY configuration issue on the qcs8300-ride platform, not introduced by PR Revert SCMI for qcom-6.18.y #1081 (which only reverts SCMI memlat devfreq changes).
3. Possible fix: This is a pre-existing qcs8300-ride platform/DT configuration issue. Recommended actions: (1) Verify the device tree phy-mode property for the Ethernet node at 23040000.ethernet matches the actual PHY hardware capabilities; (2) Check if the PHY node has correct compatible, max-speed, and link mode properties; (3) If using QCA808x PHY, ensure the PHY driver correctly advertises 2500base-x support; (4) Consider changing phy-mode to a mutually supported mode (e.g., sgmii, 1000base-x) if 2500base-x is not required. For PR Revert SCMI for qcom-6.18.y #1081 validation: Mark this failure as pre-existing infra issue and proceed with PR merge if no other genuine regressions are found.
4. Detail analysis attachment: failed_case_job223468_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver did not initialize on qcs8300-ride platform — CONFIG_KVM is enabled in kernel config but /dev/kvm device node was never created because the platform does not support ARM virtualization extensions (VHE/nVHE) or EL2 is not accessible to Linux (likely reserved by secure firmware/hypervisor).
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR touches only SCMI memlat config, not KVM). Mark KVM tests as expected-fail or skip for qcs8300-ride in the LAVA test suite, or investigate platform firmware/bootloader configuration to determine if EL2 can be made available to Linux.
4. Detail analysis attachment: failed_case_job223468_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM requires EL2 (hypervisor mode) privilege to initialize and create /dev/kvm. The qcs8300-ride target is running as a guest under the Gunyah hypervisor (boot log shows "Hypervisor cold boot, version: gunyah-cdfb73831"), which means the Linux kernel is running at EL1 without EL2 access. CONFIG_KVM is enabled in the kernel configuration, but the KVM driver cannot initialize because nested virtualization is not available or not enabled in this Gunyah hypervisor configuration.
3. Possible fix: This is not a PR-introduced regression—the PR contains only reverts of SCMI memlat devfreq patches and does not touch KVM, virtualization, or device tree configurations. The failure is a pre-existing platform/infrastructure limitation. To enable KVM on this platform: (1) verify Gunyah hypervisor supports nested virtualization for the guest VM, (2) if supported, enable nested virtualization in the Gunyah VM configuration, (3) if not supported, KVM tests should be skipped on qcs8300-ride when running under Gunyah, or (4) run KVM tests on bare-metal qcs8300-ride without Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job223468_5_detailed.md

  Case 6: KVM_Infra — Platform Configuration Limitation (Not PR-Introduced)

1. Failed case: KVM_Infra — Platform Configuration Limitation (Not PR-Introduced)
2. Root cause: QCS8300 Ride boots Linux under Gunyah hypervisor at EL1 (guest mode). KVM requires EL2 (hypervisor privilege level) to initialize. Since Gunyah controls EL2, Linux cannot access it, and KVM driver does not initialize. /dev/kvm is not created. This is expected behavior for this platform configuration.
3. Possible fix: This is not a bug to fix. If KVM functionality is required on QCS8300 Ride, the platform boot configuration must be changed to boot Linux directly on hardware (bare metal) instead of under Gunyah hypervisor. Alternatively, use nested virtualization if Gunyah supports it (requires Gunyah to expose EL2 features to guest). For CI purposes, exclude KVM tests from QCS8300 Ride test suite or mark them as expected-to-skip on hypervisor-based platforms.
4. Detail analysis attachment: failed_case_job223468_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM kernel module (kvm.ko) failed to load or create /dev/kvm device node despite CONFIG_KVM being enabled in kernel config; this is a pre-existing platform/infrastructure issue unrelated to the PR changes (PR only reverts SCMI memlat config changes).
3. Possible fix: Investigate KVM module loading on qcs8300-ride platform: check dmesg for KVM initialization errors, verify KVM ARM prerequisites (EL2 support, hypervisor mode), ensure kvm.ko and kvm-arm.ko modules are present in rootfs and loaded via modprobe, or add KVM module autoload configuration to the test image.
4. Detail analysis attachment: failed_case_job223468_7_detailed.md

[qlijarvis]

PR #1081 — validate-patch

PR: #1081

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: No — 12 out of 13 commits are missing required lore.kernel.org links (only the QCLINUX commit is exempt)

2. Lore link matches PR commits: N/A — cannot verify without lore links

3. Upstream patch status: N/A — cannot check without lore links

4. PR present in qcom-next/topics: Fail - 8/13 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation Report

PR: #1081 - Revert SCMI memlat series (13 commits)
Upstream commit: N/A (no lore.kernel.org links found)
Verdict: ❌ FAIL

---

Analysis Summary

This PR contains 13 revert commits that undo a previously merged SCMI memlat series. The reverts are necessary because the original series moved the governor.h header, breaking out-of-tree module compilation.

Commit breakdown:

• 1 × QCLINUX: revert (vendor-only)
• 3 × UPSTREAM: reverts
• 3 × FROMGIT: reverts
• 6 × FROMLIST: reverts

---

Commit Message Validation

Commit	Prefix	Lore Link Required?	Lore Link Present?	Status
01/13	Revert "QCLINUX:..."	❌ No	N/A	✅ PASS
02/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
03/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
04/13	Revert "FROMGIT:..."	✅ Yes	❌ No	❌ FAIL
05/13	Revert "UPSTREAM:..."	✅ Yes	❌ No	❌ FAIL
06/13	Revert "UPSTREAM:..."	✅ Yes	❌ No	❌ FAIL
07/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
08/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
09/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
10/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
11/13	Revert "FROMGIT:..."	✅ Yes	❌ No	❌ FAIL
12/13	Revert "FROMLIST:..."	✅ Yes	❌ No	❌ FAIL
13/13	Revert "FROMGIT:..."	✅ Yes	❌ No	❌ FAIL

Common issues across all non-QCLINUX commits:

• ❌ Missing Link: tag — No lore.kernel.org link to the original upstream patch being reverted
• ⚠️ Revert rationale present — All commits include clear justification (out-of-tree module build failure)
• ✅ Revert target documented — Each commit correctly identifies the SHA being reverted via This reverts commit <sha>
• ✅ Signed-off-by present — All commits properly signed by the author

---

Diff Comparison

Status: ⏭️ SKIPPED — Cannot compare diffs without lore source patches

Since no lore links are present, the skill cannot fetch upstream patches to verify that the revert diffs are faithful inversions of the original changes.

---

Upstream Patch Status

Status: ⏭️ SKIPPED — Cannot check upstream status without lore links

---

Integration Presence Check

According to integration_presence_report.md:

Commit	qcom-next	topics	Final Status
01/13	❌ missing	❌ missing	❌ missing
02/13	❌ missing	❌ missing	❌ missing
03/13	❌ missing	❌ missing	❌ missing
04/13	⚠️ partial	✅ present	✅ present
05/13	⚠️ partial	✅ present	✅ present
06/13	❌ missing	❌ missing	❌ missing
07/13	❌ missing	❌ missing	❌ missing
08/13	❌ missing	❌ missing	❌ missing
09/13	❌ missing	✅ present	✅ present
10/13	❌ missing	❌ missing	❌ missing
11/13	⚠️ partial	✅ present	✅ present
12/13	❌ missing	❌ missing	❌ missing
13/13	❌ missing	✅ present	✅ present

Summary: 5/13 commits present in topics, 8/13 missing from both qcom-next and topics.

---

Issues Found

1. Missing lore.kernel.org Links (12 commits)

Severity: ❌ CRITICAL

Commits 02/13 through 13/13 revert upstream-sourced patches (UPSTREAM:, FROMGIT:, FROMLIST:) but do not include Link: tags pointing to the original lore.kernel.org postings.

Impact:

• Cannot verify that the revert diffs correctly invert the original changes
• Reviewers cannot trace back to the original patch discussion
• Violates kernel commit message conventions for upstream-sourced changes

Example (commit 05/13):

Subject: [PATCH 05/13] Revert "UPSTREAM: of: Add of_machine_get_match() helper"

This reverts commit 863c23780bcf87124e8bc097ce5c4e2ced0429e0.

Expected:

Subject: [PATCH 05/13] Revert "UPSTREAM: of: Add of_machine_get_match() helper"

This reverts commit 863c23780bcf87124e8bc097ce5c4e2ced0429e0.

Link: https://lore.kernel.org/r/<message-id-of-original-patch>

Fix: Add Link: tags to all 12 commits by looking up the original commit SHAs in the git history and extracting their lore links.

---

2. Integration Presence Gaps (8 commits)

Severity: ⚠️ WARNING

8 out of 13 commits are missing from both qcom-next and the kernel-topics branches. This suggests:

• The reverts may be targeting commits that were never fully integrated, OR
• The reverts are being submitted before the original commits landed in the integration branches

Affected commits: 01/13, 02/13, 03/13, 06/13, 07/13, 08/13, 10/13, 12/13

Recommendation: Verify whether the original commits being reverted are actually present in the target branch before merging these reverts.

---

Recommendation

❌ DO NOT MERGE without addressing the missing lore links.

Required actions:

1. Add lore links to commits 02/13 through 13/13:

   • Look up each reverted commit SHA in git history
   • Extract the original Link: tag from the commit message
   • Add the link to the revert commit message

2. Verify revert targets exist in the target branch:

   • Confirm that all 13 commits being reverted are actually present in the branch where this PR will be merged
   • If any original commits are missing, remove the corresponding revert from this PR

3. Consider alternative approaches:

   • If the issue is limited to out-of-tree modules, consider a targeted fix instead of reverting the entire series
   • If the series must be reverted, document a plan to re-land it with the proper fix

---

Final Summary

1. Lore link present: No — 12 out of 13 commits are missing required lore.kernel.org links (only the QCLINUX commit is exempt)

2. Lore link matches PR commits: N/A — cannot verify without lore links

3. Upstream patch status: N/A — cannot check without lore links

4. PR present in qcom-next/topics: Fail — 8/13 commits are missing from both qcom-next and topics; 5/13 present in topics only

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

Commit	Subject	qcom-next	topics	Final
1/13	[PATCH 01/13] Revert "QCLINUX: qcom.config: Enable QCOM SCMI memlat	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
2/13	[PATCH 02/13] Revert "FROMLIST: arm64: dts: qcom: hamoa: Enable	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
3/13	[PATCH 03/13] Revert "FROMLIST: PM / devfreq: Introduce the QCOM SCMI	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
4/13	[PATCH 04/13] Revert "FROMGIT: of: Convert to of_machine_get_match()"	partial - subject or partial tree evidence found, but full change was not verified	present - all checked added lines are present	present
5/13	[PATCH 05/13] Revert "UPSTREAM: of: Add of_machine_get_match()	partial - subject or partial tree evidence found, but full change was not verified	present - all checked added lines are present	present
6/13	[PATCH 06/13] Revert "UPSTREAM: of: Add wrappers to match root node	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
7/13	[PATCH 07/13] Revert "FROMLIST: PM / devfreq: Add a governor for	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
8/13	[PATCH 08/13] Revert "FROMLIST: PM / devfreq: Add new track_remote	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
9/13	[PATCH 09/13] Revert "FROMLIST: PM / devfreq: Add new target_freq	missing - no subject, patch-id, or full tree-content match found	present - all checked added lines are present	present
10/13	[PATCH 10/13] Revert "FROMLIST: firmware: arm_scmi: vendors: Add QCOM	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
11/13	[PATCH 11/13] Revert "FROMGIT: firmware: arm_scmi: Rework protocol	partial - subject or partial tree evidence found, but full change was not verified	present - all checked added lines are present	present
12/13	[PATCH 12/13] Revert "FROMLIST: firmware: arm_scmi: Add QCOM Generic	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
13/13	[PATCH 13/13] Revert "FROMGIT: PM / devfreq: Move governor.h to a	missing - no subject, patch-id, or full tree-content match found	present - all checked added lines are present	present

Final Status

overall_status: FAIL
present_commits: 5/13
partial_commits: 0/13
missing_commits: 8/13
topics_checked_for_commits: 13/13
final_summary: PR present in qcom-next/topics: Fail - 8/13 commit(s) are missing from both qcom-next and topics

[qlijarvis]

PR #1081 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	13 commits with long commit description lines
dt-binding-check	⏭️	No binding changes
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	All 13 commits missing required prefix before Revert
tag-check	❌	All 13 commits missing required prefix before Revert

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1081 - Revert SCMI memlat devfreq patches
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34568377472
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	13 commits with long commit description lines
dt-binding-check	⏭️	No binding changes
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	All 13 commits missing required prefix before Revert
tag-check	❌	All 13 commits missing required prefix before Revert

---

❌ checkpatch — Long commit description lines

Root cause: All 13 revert commits have commit body lines exceeding 75 characters (the build error message line).

Failure details:

WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#9: 
INFO - | governor_gpubw_mon.c:14:10: fatal error: governor.h: No such file or directory

This warning appears in all 13 commits. The commit body contains a build error message that exceeds 75 characters.

Analysis: This is a cosmetic warning on revert commits. The long line is part of the revert justification (explaining why the revert is needed). While checkpatch flags it, this is acceptable for revert commits where the original subject line or error messages are quoted.

Fix (optional): Wrap the commit body line at 75 characters:

INFO - | governor_gpubw_mon.c:14:10: fatal error: governor.h: No such
       | file or directory

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git HEAD~13..HEAD

---

❌ check-patch-compliance — Missing prefix before Revert

Root cause: All 13 revert commits lack a required prefix tag before the word Revert.

Failure details:

Checking commit: Revert "QCLINUX: qcom.config: Enable QCOM SCMI memlat bus scaling"
Commit summary does not start with a required prefix

Checking commit: Revert "FROMLIST: arm64: dts: qcom: hamoa: Enable LLCC/DDR/DDR_QOS dvfs"
Commit summary does not start with a required prefix

[... repeated for all 13 commits ...]

Analysis: The check-patch-compliance checker requires revert commits to carry a prefix before the word Revert. Valid prefixes are: FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:.

Current format: Revert "FROMLIST: ..."
Required format: FROMLIST: Revert "FROMLIST: ..." or UPSTREAM: Revert "..."

Fix: Add a prefix before Revert in each commit subject:

Current subject	Corrected subject
Revert "QCLINUX: qcom.config: ..."	QCLINUX: Revert "QCLINUX: qcom.config: ..."
Revert "FROMLIST: arm64: dts: ..."	FROMLIST: Revert "FROMLIST: arm64: dts: ..."
Revert "FROMLIST: PM / devfreq: ..."	FROMLIST: Revert "FROMLIST: PM / devfreq: ..."
Revert "FROMGIT: of: Convert ..."	FROMGIT: Revert "FROMGIT: of: Convert ..."
Revert "UPSTREAM: of: Add ..."	UPSTREAM: Revert "UPSTREAM: of: Add ..."

Reproduce locally:

cd kernel-checkers
./check-patch-compliance.sh --kernel-src /path/to/kernel --base <base_sha> --head <head_sha>

Fix command:

git rebase -i HEAD~13
# For each commit, mark as 'reword' (r)
# Then update each subject line to add the prefix before "Revert"

---

❌ tag-check — Missing subject prefix (mandatory for qcom-6.18.y)

Root cause: The PR targets qcom-6.18.y, which is not qcom-next or qcom-next-staging. All commits must start with a valid prefix tag.

Failure details:

All 13 commits have subjects starting with Revert "..." without a leading prefix tag:

1. Revert "QCLINUX: qcom.config: Enable QCOM SCMI memlat bus scaling"
2. Revert "FROMLIST: arm64: dts: qcom: hamoa: Enable LLCC/DDR/DDR_QOS dvfs"
3. Revert "FROMLIST: PM / devfreq: Introduce the QCOM SCMI Memlat devfreq device"
4. Revert "FROMGIT: of: Convert to of_machine_get_match()"
5. Revert "UPSTREAM: of: Add of_machine_get_match() helper"
6. Revert "UPSTREAM: of: Add wrappers to match root node with OF device ID tables"
7. Revert "FROMLIST: PM / devfreq: Add a governor for tracking remote device frequencies"
8. Revert "FROMLIST: PM / devfreq: Add new track_remote flag for governors"
9. Revert "FROMLIST: PM / devfreq: Add new target_freq attribute flag for governors"
10. Revert "FROMLIST: firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions"
11. Revert "FROMGIT: firmware: arm_scmi: Rework protocol version negotiation logic"
12. Revert "FROMLIST: firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation"
13. Revert "FROMGIT: PM / devfreq: Move governor.h to a public header location"

Analysis: For branches other than qcom-next and qcom-next-staging, every commit must start with one of these prefixes:

• FROMLIST: — Posted to mailing list
• FROMGIT: — From a maintainer tree
• UPSTREAM: — Merged into mainline
• BACKPORT: — Backported with modifications
• QCLINUX: — Vendor-only change
• PENDING: — Work-in-progress
• WORKAROUND: — Temporary fix

Revert commits must carry a prefix before the word Revert.

Fix: Same as check-patch-compliance — add the appropriate prefix before Revert in each commit subject. Choose the prefix based on where the revert itself should be categorized:

• If the revert is vendor-specific → QCLINUX: Revert "..."
• If the revert matches an upstream revert → UPSTREAM: Revert "..."
• If the revert is being posted upstream → FROMLIST: Revert "..."
• If the revert is from a maintainer tree → FROMGIT: Revert "..."

Recommended approach: Since these are reverts of patches that were previously applied, and the reverts are vendor-specific (not posted upstream), use:

• QCLINUX: Revert "QCLINUX: ..." for commit Create qualcomm-linux-organization-repolinter.yml #1
• QCLINUX: Revert "FROMLIST: ..." for commits Adding Email Checker  #2, ci: Add email checker #3, Test PR for workflow testing #7, Test PR #8, ci: Fix: add bash shell to actions & use pull_request_target only for premerge #9, Test : Update README #10, Prepare qcom-next based on tag 'Linux 6.15-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #12
• QCLINUX: Revert "FROMGIT: ..." for commits ci: Add kernel checkers #4, ci : Dry run topic branch merge #11, ci: Fix: Fetch latest codebase before running checkers #13
• QCLINUX: Revert "UPSTREAM: ..." for commits ci: Add kernel checkers #5, ci: Add initial github actions for kernel CI pipeline #6

Fix command:

git rebase -i HEAD~13
# Mark each commit as 'reword' (r)
# Update each subject to add "QCLINUX: " before "Revert"

---

Verdict

13 blockers must be fixed before merge:

1. Critical: All 13 commits fail check-patch-compliance and tag-check due to missing prefix before Revert. This is a hard blocker — the CI will continue to fail until fixed.

2. Cosmetic: All 13 commits have checkpatch warnings for long commit body lines. This is acceptable for revert commits but can be fixed by wrapping the error message line.

Recommended action:

1. Rebase the PR and add QCLINUX: prefix before Revert in all 13 commit subjects
2. Optionally wrap the long commit body lines at 75 characters
3. Force-push the updated branch to re-trigger CI

Example fix for commit #1:

Before: Revert "QCLINUX: qcom.config: Enable QCOM SCMI memlat bus scaling"
After:  QCLINUX: Revert "QCLINUX: qcom.config: Enable QCOM SCMI memlat bus scaling"