FROMLIST: gpio: Add fwnode_gpiod_get() helper

[ziyuezhang-123]

Add fwnode_gpiod_get() as a convenience wrapper around
fwnode_gpiod_get_index() for the common case where only the
first GPIO is required.

This mirrors existing gpiod_get() and devm_gpiod_get() helpers
and avoids open-coding index 0 at call sites.

Suggested-by: Manivannan Sadhasivam mani@kernel.org
Acked-by: Manivannan Sadhasivam mani@kernel.org
Reviewed-by: Linus Walleij linusw@kernel.org
Acked-by: Bartosz Golaszewski bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Krishna Chaitanya Chundru krishna.chundru@oss.qualcomm.com
Signed-off-by: Ziyue Zhang ziyue.zhang@oss.qualcomm.com

Link: https://lore.kernel.org/all/20260511-wakeirq_support-v10-1-c10af9c9eb8c@oss.qualcomm.com/
CRs-Fixed: 4542930

[qcomlnxci]

Test jobs on a1c92a2

• multimedia Job 190182 on hamoa-iot-evk
• multimedia Job 190179 on lemans-evk
• multimedia Job 190185 on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job 190180 on qcs615-ride
• multimedia Job 190183 on qcs6490-rb3gen2
• multimedia Job 190181 on qcs8300-ride
• multimedia Job 190184 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on a1c92a2

• multimedia Job 190182 on hamoa-iot-evk
• multimedia Job 190179 on lemans-evk
• multimedia Job 190185 on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job on qcs615-ride
• multimedia Job 190183 on qcs6490-rb3gen2
• multimedia Job 190181 on qcs8300-ride
• multimedia Job 190184 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on a1c92a2

• multimedia Job 193982 on hamoa-iot-evk
• multimedia Job 193978 on lemans-evk
• multimedia Job 193977 on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job 193981 on qcs615-ride
• multimedia Job 193979 on qcs6490-rb3gen2
• multimedia Job 193980 on qcs8300-ride
• multimedia Job 193976 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 193975 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on a1c92a2

• multimedia Job 207581 on hamoa-iot-evk
• multimedia Job 207577 on lemans-evk
• multimedia Job 207578 on monaco-evk
• multimedia Job 207582 on purwa-iot-evk
• multimedia Job 207583 on qcs615-ride
• multimedia Job 207579 on qcs6490-rb3gen2
• multimedia Job 207575 on qcs8300-ride
• multimedia Job 207576 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 207580 on shikra-iqs-evk

[qswat-orbit-external]

Change task cannot be moved to Dev Complete

CR: 4542930
Change Task: kernel.qli.2.0
Error: GenAI Assisted field must be set before moving change tasks to Development Complete. Please provide GenAI information.

The change task for this CR cannot be automatically moved to Dev Complete due to the error above. Please resolve the issue mentioned in the error and manually change the change task status to Dev Complete in Orbit.

[qswat-orbit-external]

Change task cannot be moved to Dev Complete

CR: 4542930
Change Task: kernel.qli.2.0
Error: GenAI Assisted field must be set before moving change tasks to Development Complete. Please provide GenAI information.

The change task for this CR cannot be automatically moved to Dev Complete due to the error above. Please resolve the issue mentioned in the error and manually change the change task status to Dev Complete in Orbit.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #870

Job 207575 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two probe/firmware errors: (1) regulatory.db firmware load failure (ENOENT) — a known benign issue as wireless subsystem functions correctly; (2) Aquantia AQR115C Ethernet PHY probe failure (EINVAL) due to missing firmware-name DT property on qcs8300-ride platform — a pre-existing board configuration issue unrelated to the PR under test (GPIO helper addition).
3. Possible fix: Suppress the regulatory.db failure as known benign (wireless functional). For the Aquantia PHY: add the missing firmware-name property to the qcs8300-ride device tree ethernet PHY node (stmmac-0:08), or mark this test as expected-fail for qcs8300-ride until the platform DT is corrected. The PR itself (GPIO helper) is not the cause and should not be blocked by this pre-existing platform issue.
4. Detail analysis attachment: failed_case_job207575_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure failure — no external USB devices connected to the qcs8300-ride board during test execution. The USB host controller initialized successfully (xHCI driver loaded, root hub enumerated with 1 USB2 port), but only the root hub itself was detected (Bus 001 Device 001: Linux Foundation 2.0 root hub). The test expects at least one functional USB device beyond the hub to pass.
3. Possible fix: This is a test environment/infrastructure issue, not a kernel regression. The PR (adding fwnode_gpiod_get() helper to GPIO subsystem) does not touch USB code and cannot cause this failure. Recommended actions: (1) Verify USB device is physically connected to the qcs8300-ride board's USB port before running the test; (2) If this is a known lab configuration limitation for qcs8300-ride, mark USBHost as SKIP for this platform or update test expectations; (3) Re-run the test with a USB device (keyboard, mouse, or storage) connected to confirm USB host functionality.
4. Detail analysis attachment: failed_case_job207575_2_detailed.md

  Case 3: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** /dev/kvm device node not present because KVM cannot initialize when Linux runs as a guest under the Gunyah hypervisor on QCS8300 Ride. KVM requires EL2 (hypervisor mode) access, but Linux is running at EL1 (guest mode) under Gunyah. This is a platform architecture limitation, not a kernel bug.
3. Possible fix: Mark KVM tests as SKIP (not FAIL) for QCS8300 Ride platform in the LAVA test suite, or disable KVM tests entirely for Gunyah-based boot configurations. This is not a kernel issue and cannot be fixed in the kernel code.
4. Detail analysis attachment: failed_case_job207575_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM unavailable because system is running as a guest VM under Gunyah hypervisor. KVM requires EL2 (hypervisor privilege level) to function, but guest VMs run at EL1 and do not have access to EL2. This is expected behavior, not a failure.
3. Possible fix: This is not a bug - it is expected behavior. KVM cannot function in a guest VM without nested virtualization support. To run KVM tests, boot the kernel directly on bare metal (not under Gunyah hypervisor). If KVM functionality in a VM is required, nested virtualization support must be implemented in both Gunyah hypervisor and the KVM driver.
4. Detail analysis attachment: failed_case_job207575_4_detailed.md

  Case 5: KVM_Infra — /dev/kvm device node not available

1. Failed case: KVM_Infra — /dev/kvm device node not available
2. Root cause: KVM subsystem failed to initialize on qcs8300-ride (Monaco) platform despite CONFIG_KVM=y; /dev/kvm character device was never created, indicating KVM driver did not probe successfully or the platform does not support virtualization at EL2.
3. Possible fix: Verify that the qcs8300 (Monaco) SoC supports ARM virtualization extensions and that the bootloader/firmware boots the kernel at EL2 (not EL1); if the platform lacks VHE/nVHE support or boots at EL1, KVM cannot initialize and these tests should be skipped for this platform; if EL2 is available, check for missing device tree nodes or kernel boot messages indicating why KVM initialization was skipped.
4. Detail analysis attachment: failed_case_job207575_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM device node /dev/kvm not created despite CONFIG_KVM=y — KVM driver initialization failed silently or platform lacks EL2/VHE support required for KVM on QCS8300 (Monaco). This is a pre-existing platform/kernel configuration issue unrelated to the PR (which only adds a GPIO helper function).
3. Possible fix: Verify QCS8300 platform supports KVM/virtualization at EL2 by checking boot log for KVM initialization messages or errors. If KVM is unsupported on this SoC, exclude KVM tests from the CI test suite for qcs8300-ride. If KVM should be supported, investigate why the KVM ARM driver (arch/arm64/kvm/arm.c) failed to create /dev/kvm — check for missing hypervisor mode, VHE requirements, or silent initialization failures in dmesg.
4. Detail analysis attachment: failed_case_job207575_6_detailed.md

Job 207576 | SoC qcs9100-ride

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

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

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

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU S2CR Register Write
2. Root cause: The qcs9100-ride platform's SMMU hardware at 0x15000000 is not responding to MMIO writes during S2CR (Stream-to-Context Register) configuration. The crash occurs at qcom_smmu_write_s2cr+0x84 when the kernel attempts to write to SMMU register offset 0xc28 (S2CR for stream ID 8) while attaching remoteproc device 30000000.remoteproc to IOMMU group 15. The synchronous external abort (ESR 0x96000010) indicates the SMMU register aperture is either not powered, not clocked, or in a hardware fault state specific to this qcs9100-ride board revision.
3. Possible fix: This is a pre-existing platform/hardware issue NOT introduced by PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (which only adds a GPIO helper function). The SMMU probed successfully earlier but became inaccessible during device attachment. Recommended actions: (1) Verify SMMU power domain and clock configuration in qcs9100-ride device tree; (2) Check if SMMU requires additional power/clock resources for S2CR writes beyond probe-time requirements; (3) Add SMMU register access error handling in qcom_smmu_write_s2cr to prevent kernel panic; (4) Investigate qcs9100 (Lemans) platform-specific SMMU errata or hardware limitations; (5) Re-trigger the CI job to confirm if this is a transient hardware fault on the LAVA board.
4. Detail analysis attachment: failed_case_job207576_1_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in SMMU Initialization
2. Root cause: ** SMMU register write to S2CR (Stream-to-Context Register) at offset 0xc28 triggered a synchronous external abort during arm_smmu_device_probe, indicating the SMMU hardware register is either not accessible (power/clock issue), not implemented at the expected address (DT/platform mismatch), or the NoC path to the SMMU is broken on the qcs9100-ride board.
3. Possible fix: This is a board/platform-specific hardware configuration issue unrelated to the PR (which only adds a GPIO helper function). Re-run the test on a known-good qcs9100-ride board to confirm hardware health. If reproducible, verify: (1) SMMU power domain and clock configuration in device tree, (2) SMMU base address matches hardware spec (0x15000000), (3) NoC/interconnect path to SMMU is functional, (4) bootloader/firmware has correctly initialized the SMMU power island.
4. Detail analysis attachment: failed_case_job207576_2_detailed.md

  Case 3: Kernel Crash — Synchronous External Abort during SMMU initialization

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU initialization
2. Root cause: Hardware access fault (synchronous external abort 0x96000010) when writing to SMMU S2CR register at offset 0xc28 during qcom_smmu_write_s2cr() in SMMU driver probe. The SMMU hardware is either unpowered, unconfigured, or the register address is invalid for qcs9100-ride platform.
3. Possible fix: Verify SMMU power domain and clock configuration in qcs9100-ride device tree; ensure SMMU base address and register layout match hardware specification; check if SMMU requires firmware/TZ initialization before kernel access; add power-domain dependencies to SMMU DT node if missing.
4. Detail analysis attachment: failed_case_job207576_3_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in SMMU Initialization
2. Root cause: Synchronous external abort (0x96000010) during SMMU S2CR register write in qcom_smmu_write_s2cr at 4.358s into boot; hardware rejected register access, likely due to clock/power gating, missing hardware, or firmware protection on qcs9100-ride platform; PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (GPIO helper addition) is unrelated and did not cause this crash.
3. Possible fix: This is a pre-existing qcs9100-ride platform issue unrelated to PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870; verify SMMU clocks are enabled in device tree, check power domain dependencies, confirm firmware allows SMMU register access, and compare with working qcs9100 configurations; PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 can proceed as the crash is not a regression.
4. Detail analysis attachment: failed_case_job207576_4_detailed.md

Job 207577 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected (1) four PMIC temp-alarm devices stuck in deferred probe state (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and (2) three firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv with error -2 ENOENT). However, the Bluetooth firmware failures are known benign per suppression Rule 3 — BT_ON_OFF functional test passed, confirming Bluetooth firmware loaded correctly at runtime. The deferred temp-alarm probes indicate a missing thermal zone dependency on lemans-evk platform.
3. Possible fix: The Bluetooth firmware failures are false positives and should be suppressed in the test harness (BT functional test passed). For the temp-alarm deferred probes: verify the lemans-evk device tree includes thermal zone definitions that reference these temp-alarm devices as thermal sensors. If missing, add thermal zone nodes with thermal-sensors = <&pmicX_temp_alarm> phandles. The PR (GPIO helper addition) is unrelated to these pre-existing platform issues.
4. Detail analysis attachment: failed_case_job207577_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on lemans-evk; the test expects this critical master to be IOMMU-protected but the device is either not present, did not probe, or lacks IOMMU configuration in the device tree for this SoC.
3. Possible fix: This is a pre-existing platform/test configuration issue unrelated to the PR (which only adds a GPIO helper function). Verify if lemans-evk hardware includes a video codec at this address; if yes, check device tree for missing iommus property or driver probe failures; if no, update the smmu test to skip video-codec validation on lemans-evk or mark it as optional.
4. Detail analysis attachment: failed_case_job207577_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 suite completed with two genuine test failures: (1) Probe_Failure_Check detected kernel probe/firmware errors in dmesg, and (2) smmu test detected Video codec device (aa00000.video-codec) missing IOMMU group attachment on lemans-evk platform.
3. Possible fix: Investigate the two root test failures: (1) Review probe_failures.log for the specific probe/firmware errors flagged by Probe_Failure_Check, and (2) Verify video codec IOMMU binding in the lemans device tree - the video-codec@aa00000 node may be missing the iommus property or the IOMMU domain allocation is failing at probe time.
4. Detail analysis attachment: failed_case_job207577_3_detailed.md

Job 207578 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Missing WiFi firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) caused ath11k_pci driver probe to fail with error -110 (ETIMEDOUT). Additional missing firmware files for Bluetooth (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) and regulatory database (regulatory.db) also triggered the test failure. These are pre-existing test infrastructure issues, not regressions introduced by the PR (which only adds a GPIO helper function).
3. Possible fix: Add the missing firmware files to the monaco-evk test image rootfs under /lib/firmware/. Specifically: (1) ath11k/WCN6855/hw2.1/nfa765/amss.bin and related ath11k firmware for WCN6855, (2) qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv for Bluetooth, (3) regulatory.db for wireless regulatory database. Alternatively, if these firmware files are intentionally excluded, update the Probe_Failure_Check test to suppress these known-missing firmware warnings for monaco-evk.
4. Detail analysis attachment: failed_case_job207578_1_detailed.md

  Case 2: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing WCN6855 nfa765 board variant firmware files to the linux-firmware-qcom or equivalent firmware package in the Yocto layer (meta-qcom). Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are included in the rootfs /lib/firmware/ directory for Monaco EVK builds.
4. Detail analysis attachment: failed_case_job207578_2_detailed.md

  Case 3: WiFi_OnOff — ath11k_pci driver probe failure

1. Failed case: WiFi_OnOff — ath11k_pci driver probe failure
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk due to missing WiFi firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) in the rootfs image, causing MHI power-up timeout during device initialization. This is a pre-existing infrastructure/image packaging issue, not introduced by the GPIO helper patch in PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image build recipe for monaco-evk. The firmware should be packaged in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ directory. Verify the linux-firmware package or equivalent firmware source includes this specific board variant (nfa765) firmware for WCN6855 hw2.1.
4. Detail analysis attachment: failed_case_job207578_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Pre-existing WiFi firmware file missing in test environment — ath11k driver probe failed with -110 (ETIMEDOUT) because firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin was not found (error -2, ENOENT) during MHI power-up, causing three test cases (Probe_Failure_Check, WiFi_Firmware_Driver, WiFi_OnOff) to fail. This is unrelated to the PR changes (GPIO consumer helper addition).
3. Possible fix: Install the missing WiFi firmware package linux-firmware-ath11k or equivalent containing ath11k/WCN6855/hw2.1/nfa765/amss.bin in the test rootfs, or update the firmware search path to include the correct location for monaco-evk WCN6855 hw2.1 nfa765 variant firmware.
4. Detail analysis attachment: failed_case_job207578_4_detailed.md

Job 207579 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — WiFi Regulatory Database Firmware Load (Known Benign)

1. Failed case: Probe_Failure_Check — WiFi Regulatory Database Firmware Load (Known Benign)
2. Root cause: The cfg80211 regulatory subsystem attempted to load regulatory.db firmware file during early boot (7.145s), which failed with -ENOENT (error -2, file not found). However, this is a known benign failure: WiFi functionality is fully operational as evidenced by WiFi_Firmware_Driver and WiFi_OnOff tests both passing. The regulatory database is not required for basic WiFi operation on qcs6490-rb3gen2, and the driver falls back to built-in regulatory rules.
3. Possible fix: No fix required. This is a known benign test failure that should be suppressed. The Probe_Failure_Check test should be updated to exclude regulatory.db firmware load failures when WiFi functional tests pass, following the same pattern as Rule 2 in lava-known-benign-failures.md. Alternatively, add regulatory.db to the rootfs firmware directory if strict compliance with the test is required, but this is not functionally necessary.
4. Detail analysis attachment: failed_case_job207579_1_detailed.md

  Case 2: USBHost — Test Environment Issue (No USB Device Connected)

1. Failed case: USBHost — Test Environment Issue (No USB Device Connected)
2. Root cause: The USBHost test failed because no USB devices were enumerated on the qcs6490-rb3gen2 board during test execution. The kernel USB subsystem initialized correctly (usbcore registered at boot time [3.149128]), USB controllers at addresses 0xa600000 and 0x8c00000 were added to IOMMU groups, and no USB driver probe failures or kernel errors were observed in the boot log. The test script reported "Enumerated USB devices..." followed immediately by "[FAIL] USBHost : Test Failed - No USB devices found." This indicates the test queried the USB bus (likely via lsusb or /sys/bus/usb/devices) but found no connected devices. The PR under test (PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870) adds only a static inline GPIO helper function (fwnode_gpiod_get) in include/linux/gpio/consumer.h and does not touch any USB-related code, making it impossible for this patch to cause USB enumeration failure.
3. Possible fix: This is a pre-existing test environment/lab infrastructure issue, not a kernel regression introduced by PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870. The failure is caused by the absence of a physical USB device connected to the board's USB host port during the LAVA test run. To resolve: (1) Verify the lab setup for qcs6490-rb3gen2 boards includes a USB device (e.g., USB flash drive, USB hub, or USB-to-serial adapter) connected to the USB host port before test execution. (2) If the board's USB host port hardware is known to be non-functional or not wired out on this specific board revision, mark the USBHost test as SKIP for qcs6490-rb3gen2 in the LAVA test definition. (3) Re-run the LAVA job after confirming USB device connectivity; if the issue persists with a device connected, investigate USB host controller driver probe status and device tree configuration for dr_mode settings.
4. Detail analysis attachment: failed_case_job207579_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because the qcs6490-rb3gen2 board firmware/bootloader does not enable EL2 (HYP mode) — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation. This is a platform/firmware limitation, not a kernel regression.
3. Possible fix: This is not a PR-introduced failure (PR only adds a GPIO helper function). The qcs6490-rb3gen2 platform requires bootloader/firmware configuration to enable EL2 virtualization support. Either: (1) update the board's bootloader/firmware to enable EL2, or (2) mark KVM tests as expected-fail for this platform in the CI job definition until firmware support is available.
4. Detail analysis attachment: failed_case_job207579_3_detailed.md

  Case 4: ** KVM_EL2_DTB — KVM Driver Initialization Failure

1. Failed case: ** KVM_EL2_DTB — KVM Driver Initialization Failure
2. Root cause: ** KVM driver initialization failed because HYP mode (ARM EL2) is not available on the qcs6490-rb3gen2 platform. The kernel detected at boot (line 2747: kvm [1]: HYP mode not available) that it does not have access to the virtualization extensions required for KVM operation, causing the driver to abort initialization and preventing creation of the /dev/kvm device node.
3. Possible fix: This is a pre-existing platform/firmware configuration issue unrelated to PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (which only adds a GPIO helper function). To enable KVM on qcs6490-rb3gen2: (1) verify the bootloader (ABL/XBL) is configured to boot Linux at EL2 or with VHE (Virtualization Host Extensions) enabled, (2) confirm the device tree includes the necessary PSCI and virtualization properties, (3) verify the hypervisor firmware (hypvm.mbn) configuration allows Linux to access EL2. This test should be marked as a known platform limitation or the CI job should skip KVM tests on platforms without EL2 support.
4. Detail analysis attachment: failed_case_job207579_4_detailed.md

  Case 5: KVM_Infra — KVM device node unavailable (pre-existing platform limitation)

1. Failed case: KVM_Infra — KVM device node unavailable (pre-existing platform limitation)
2. Root cause: KVM initialization failed during kernel boot with "kvm [1]: HYP mode not available" — the qcs6490-rb3gen2 platform does not support EL2 hypervisor mode, preventing /dev/kvm creation.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The GPIO patch in PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 does not affect KVM/virtualization. Mark KVM tests as expected-fail for qcs6490-rb3gen2, or skip KVM test suite on platforms without EL2 support.
4. Detail analysis attachment: failed_case_job207579_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM virtualization not supported on qcs6490-rb3gen2 — kernel reports "HYP mode not available" at boot, preventing /dev/kvm device creation and causing all KVM test cases to fail.
3. Possible fix: Mark KVM tests as expected-fail or skip them for qcs6490-rb3gen2 in the LAVA job definition, as this SoC does not support EL2 hypervisor mode required for KVM.
4. Detail analysis attachment: failed_case_job207579_6_detailed.md

Job 207580 | SoC shikra-iqs-evk

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

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

  Case 1: GIC Test Script Bug — False Failure on 4-CPU Platform

1. Failed case: GIC Test Script Bug — False Failure on 4-CPU Platform
2. Root cause: The GIC test script assumes an 8-CPU system and attempts to validate timer interrupt counts for CPUs 4-7, which do not exist on the shikra-iqs-evk platform (4-CPU system: CPU 0-3). The script's bash integer comparison at line 75 fails when parsing /proc/interrupts for non-existent CPUs, encountering non-numeric tokens ("GICv3", "Level", "arch_timer") instead of interrupt counts, resulting in bash errors "[: GICv3: integer expected", "[: Level: integer expected", "[: arch_timer: integer expected" and false test failures for CPUs 4-7.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo before attempting to validate timer interrupt counts, rather than hardcoding an assumption of 8 CPUs. The script should only validate CPUs that are actually present on the target platform.
4. Detail analysis attachment: failed_case_job207580_1_detailed.md

  Case 2: Remoteproc Boot Failure — modem subsystem offline

1. Failed case: Remoteproc Boot Failure — modem subsystem offline
2. Root cause: remoteproc0 (modem subsystem) remained in 'offline' state and was never powered up during boot; no firmware load attempt was made for qcom/shikra/cqs/qdsp6sw.mbn, indicating the modem subsystem is not configured for auto-boot on the Shikra IQS EVK platform.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR only adds a GPIO helper function unrelated to remoteproc. The modem subsystem on Shikra IQS EVK requires manual start via echo start > /sys/class/remoteproc/remoteproc0/state or device tree configuration with qcom,auto-boot property. Update the test expectation to mark modem as optional/manual-start for this platform, or add device tree configuration to enable modem auto-boot if modem functionality is required.
4. Detail analysis attachment: failed_case_job207580_2_detailed.md

  Case 3: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the Probe_Failure_Check test to suppress known-benign probe failures: exclude cpufreq-dt EEXIST errors when cpufreq functional tests pass, and exclude regulatory.db ENOENT errors when WiFi tests are skipped. The PR (GPIO helper addition) is not related to these failures and should proceed.
4. Detail analysis attachment: failed_case_job207580_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a board/lab infrastructure configuration issue, not a kernel bug. The test should be marked as SKIP for shikra-iqs-evk until the board is reconfigured with a USB host port connection, or the test should be updated to detect USB gadget-only configurations and skip automatically. No kernel code change is required.
4. Detail analysis attachment: failed_case_job207580_4_detailed.md

  Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth scan test failed to discover any nearby Bluetooth devices after 3 scan attempts (15 seconds each) and an interactive fallback attempt, despite Bluetooth hardware being functional (hci0 powered, BT_ON_OFF test passed). This is a test environment issue — no scannable Bluetooth devices were present in the LAVA lab environment during test execution.
3. Possible fix: This is a pre-existing test infrastructure limitation, not a kernel regression introduced by PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (which only adds a GPIO helper function unrelated to Bluetooth). The fix is environmental: ensure at least one active, discoverable Bluetooth device is present in the LAVA lab test environment within radio range of the shikra-iqs-evk board. Alternatively, mark BT_SCAN as an optional test or configure it to skip when no target devices are available.
4. Detail analysis attachment: failed_case_job207580_5_detailed.md

  Case 6: 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 the CPU attempted to read from an unmapped, unpowered, or clock-gated MMIO address within the PRNG hardware block on shikra-iqs-evk.
3. Possible fix: Verify qcom_rng device tree node includes all required clocks, power domains, and interconnect paths for shikra (QCM6490). Check that runtime PM is correctly sequenced before hardware access. Add clock/power domain enablement validation in qcom_rng_read() before MMIO access, or ensure probe defers if dependencies are not ready.
4. Detail analysis attachment: failed_case_job207580_6_detailed.md

  Case 7: Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (bus fault) at PC qcom_rng_read+0xc4 when the dd process attempted to read from /dev/hwrng. The fault occurred during MMIO register access (b940035c = ldr w28, [x26]), indicating the qcom_rng hardware block was either not clocked/powered or the MMIO mapping was invalid. This is a pre-existing platform/firmware issue unrelated to PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (which only adds a GPIO helper function).
3. Possible fix: This is NOT a PR-introduced regression. The qcom_rng driver crash is a known shikra-iqs-evk platform issue where the RNG hardware block is not properly initialized by firmware or lacks required clock/power domain configuration in the device tree. Recommended action: (1) Skip the qcom_hwrng test on shikra-iqs-evk until the platform DT/firmware is fixed, or (2) investigate why the RNG MMIO region at the faulting address is not accessible (check clocks, power domains, and firmware initialization in the shikra DT).
4. Detail analysis attachment: failed_case_job207580_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 fault (synchronous external abort) in qcom_rng_read() at PC offset +0xc4 while reading from hardware RNG registers during qcom_hwrng test execution. The crash triggered a kernel panic, followed by board reset. After reboot, the system failed to return to the test shell prompt within the 40-minute LAVA timeout, causing lava-test-retry to fail.
3. Possible fix: This is a pre-existing hardware/driver issue unrelated to PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (GPIO helper addition). The qcom_rng driver is attempting to access unmapped or inaccessible hardware registers on shikra-iqs-evk. Recommended actions: (1) Verify qcom_rng device tree node and register mappings for shikra platform; (2) Check if qcom_rng hardware block is properly powered/clocked on this SoC; (3) Add error handling for external abort in qcom_rng_read(); (4) Consider blacklisting qcom_hwrng test on shikra-iqs-evk until hardware access is fixed.
4. Detail analysis attachment: failed_case_job207580_8_detailed.md

  Case 9: Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault (synchronous external abort) in qcom_rng_read() at offset +0xc4 when reading from the QCOM hardware RNG device during the qcom_hwrng test; the abort occurred while accessing MMIO register at instruction b940035c (ldr w28, [x26]), indicating the RNG hardware block was not accessible (likely not powered/clocked or in an incorrect state).
3. Possible fix: Verify qcom_rng driver power/clock dependencies in the device tree for shikra-iqs-evk; ensure the RNG hardware block's power domain, clocks, and interconnect paths are correctly described and sequenced; add runtime PM support or explicit power-on sequence in qcom_rng probe if missing; if the hardware requires specific firmware or secure-world initialization, confirm that path is functional on this SoC.
4. Detail analysis attachment: failed_case_job207580_9_detailed.md

Job 207581 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)

1. Failed case: Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)
2. Root cause: Three probe failures detected in dmesg: (1) qcom_qseecom_uefisecapp failed with -EBUSY (secure world resource unavailable on this platform), (2) qcom-spmi-lpg failed with -EINVAL due to invalid device tree "reg" property for multi-led configuration, (3) regulatory.db firmware file missing from rootfs (-ENOENT). All three are pre-existing platform/configuration issues unrelated to the PR's GPIO helper function addition.
3. Possible fix: No action required for this PR — the GPIO helper function addition does not impact QSEE, SPMI/PMIC, or wireless regulatory subsystems. For platform quality: (1) add DT property to disable qcom_qseecom.uefisecapp.0 device node on platforms without UEFI secure app support, (2) correct the device tree "reg" property in c42d000.spmi:pmic@1:pwm multi-led child node to match qcom-spmi-lpg driver expectations, (3) add regulatory.db firmware file to rootfs or document as expected (cfg80211 uses built-in regulatory rules as fallback).
4. Detail analysis attachment: failed_case_job207581_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Six critical platform devices (five USB controllers at a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and video codec at aa00000) are missing IOMMU group attachments in the hamoa-evk device tree, causing the SMMU validation test to fail despite SMMU hardware and kernel driver functioning correctly.
3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video-codec aa00000.video-codec in arch/arm64/boot/dts/qcom/x7181-*.dtsi to attach them to appropriate IOMMU groups, following the pattern used by the working USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb).
4. Detail analysis attachment: failed_case_job207581_2_detailed.md

  Case 3: WiFi_Firmware_Driver — ath12k WiFi7 driver QMI DMA allocation failure

1. Failed case: WiFi_Firmware_Driver — ath12k WiFi7 driver QMI DMA allocation failure
2. Root cause: The ath12k_wifi7_pci driver failed to allocate a 7274496-byte (≈7MB) DMA buffer during QMI firmware initialization on the Hamoa EVK platform. The error message "qmi dma allocation failed (7274496 B type 1), will try later with small size" indicates the driver attempted a large contiguous DMA allocation that failed, likely due to memory fragmentation or insufficient CMA/DMA pool size for this SoC's WiFi7 hardware requirements. Despite the failure, the driver continued and successfully brought up the WiFi interface (wlP4p1s0), but the test harness flagged this probe-time error as a failure.
3. Possible fix: This is a non-fatal warning that does not prevent WiFi functionality — the driver implements a fallback mechanism ("will try later with small size") and successfully initialized. However, to eliminate the warning: (1) increase the CMA pool size in the device tree reserved-memory node for the Hamoa platform to accommodate the 7MB+ DMA requirement, or (2) tune the ath12k driver's QMI memory allocation strategy to request smaller initial buffers. The PR under test (gpio: Add fwnode_gpiod_get() helper) does not touch WiFi, DMA, or memory subsystems and is unrelated to this failure — this is a pre-existing platform/driver integration issue specific to Hamoa EVK's memory configuration.
4. Detail analysis attachment: failed_case_job207581_3_detailed.md

  Case 4: WiFi_OnOff — WiFi driver probe warning (non-fatal)

1. Failed case: WiFi_OnOff — WiFi driver probe warning (non-fatal)
2. Root cause: ath12k_wifi7_pci driver on hamoa-evk (wcn7850 hw2.0) logged a transient QMI DMA allocation failure during probe ("qmi dma allocation failed (7274496 B type 1), will try later with small size"), but the driver successfully recovered, loaded firmware, and created the WiFi interface (wlP4p1s0). The test harness incorrectly flagged this recoverable warning as a hard failure.
3. Possible fix: Update the WiFi_OnOff test harness probe-check logic to distinguish between fatal probe failures (driver never reaches operational state) and non-fatal transient warnings followed by successful recovery. The test should pass when the WiFi interface is created and operational, even if transient allocation warnings appear during probe. Alternatively, suppress this specific "will try later with small size" pattern as a known-benign recovery message in the test's probe-failure regex.
4. Detail analysis attachment: failed_case_job207581_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 platform hardware limitation, not a software bug. The test should be skipped on platforms without EL2 support. Add a platform capability check to the LAVA test definition to skip KVM tests on hamoa-evk and other platforms without virtualization extensions, or update the kernel config to disable CONFIG_KVM for hamoa-evk builds if virtualization is not a target feature for this SoC.
4. Detail analysis attachment: failed_case_job207581_5_detailed.md

  Case 6: KVM_EL2_DTB — /dev/kvm not available (HYP mode unavailable)

1. Failed case: KVM_EL2_DTB — /dev/kvm not available (HYP mode unavailable)
2. Root cause: KVM cannot initialize because EL2 (hypervisor mode) is already occupied by the Gunyah hypervisor running on the Hamoa IoT EVK platform; kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected EL2 is unavailable, preventing /dev/kvm device node creation.
3. Possible fix: This is not a kernel regression introduced by PR FROMLIST: gpio: Add fwnode_gpiod_get() helper #870 (GPIO helper addition). The failure is a platform configuration issue: Hamoa IoT EVK boots with Gunyah hypervisor at EL2, making KVM unavailable. To enable KVM testing on this platform, either: (1) boot without Gunyah hypervisor (requires firmware/bootloader reconfiguration to not load Gunyah), or (2) exclude KVM test cases from the Hamoa IoT EVK test suite, as KVM and Gunyah cannot coexist (both require exclusive EL2 access).
4. Detail analysis attachment: failed_case_job207581_6_detailed.md

  Case 7: KVM_Infra — Test Environment Limitation (Not a Kernel Bug)

1. Failed case: KVM_Infra — Test Environment Limitation (Not a Kernel Bug)
2. Root cause: The hamoa-evk board is running Linux as a guest under Gunyah hypervisor (line 2825: "Gunyah based bootup"). When Linux runs as a guest VM, it operates at EL1 and does not have access to EL2 (HYP mode). KVM requires EL2 access to provide nested virtualization. The kernel correctly detects this architectural limitation and reports "kvm [1]: HYP mode not available" (line 3698), causing /dev/kvm to not be created.
3. Possible fix: This is not a bug — it is expected behavior. KVM tests should be excluded from the test suite for boards running under Gunyah hypervisor, or the test should be marked as "skip" when HYP mode is unavailable. Update the LAVA job definition to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on hamoa-evk or any board configured to boot under Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job207581_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 message "kvm [1]: HYP mode not available" at boot indicates the Hamoa EVK platform does not support EL2 hypervisor mode required for KVM virtualization.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The Hamoa EVK does not have EL2/hypervisor support enabled in firmware/hardware configuration. Either: (1) skip KVM tests on Hamoa EVK in CI, or (2) enable EL2 support in the platform firmware if the SoC supports it, or (3) use a different board that supports virtualization for KVM testing.
4. Detail analysis attachment: failed_case_job207581_8_detailed.md

Job 207582 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark as known pre-existing issue for purwa-evk. The PR patch (GPIO helper addition) does not introduce or affect these failures. If purwa-evk board support is required, fix: (1) Add PCIe PHY init sequence data to DT or PHY driver for this SoC, (2) Correct the multi-LED "reg" property in SPMI LPG DT node, (3) Investigate QSEECOM resource conflict, (4) Add regulatory.db to rootfs firmware directory.
4. Detail analysis attachment: failed_case_job207582_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six critical DMA masters (five USB controllers: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb; and one video codec: aa00000.video-codec) are missing IOMMU group attachments on purwa-evk, indicating incomplete device tree iommus property configuration for these devices.
3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video codec aa00000.video-codec in arch/arm64/boot/dts/qcom/purwa.dtsi (or the appropriate SoC-level DTSI), referencing the correct SMMU phandle and stream IDs for purwa-evk platform.
4. Detail analysis attachment: failed_case_job207582_2_detailed.md

  Case 3: ** WiFi_Firmware_Driver (test harness false positive)

1. Failed case: ** WiFi_Firmware_Driver (test harness false positive)
2. Root cause: ** The ath12k WiFi driver on purwa-evk attempted a 7MB QMI DMA allocation during probe, which failed initially but succeeded on retry with a smaller size. The driver completed initialization successfully (firmware loaded, interface wlP4p1s0 created). The test harness flagged this as a failure because it pattern-matches "qmi dma allocation failed" in kernel logs without verifying the driver's final state. This is a test infrastructure issue, not a kernel regression. The PR (GPIO helper addition) is unrelated to this failure.
3. Possible fix: Update the WiFi_Firmware_Driver test script to check the driver's final probe status (interface creation, firmware load completion) rather than failing on transient retry messages. The pattern "qmi dma allocation failed.*will try later" should be treated as informational, not a hard failure, when followed by successful driver initialization.
4. Detail analysis attachment: failed_case_job207582_3_detailed.md

  Case 4: WiFi_OnOff — False Positive (Driver Probe Warning Misclassified as Failure)

1. Failed case: WiFi_OnOff — False Positive (Driver Probe Warning Misclassified as Failure)
2. Root cause: The WiFi test script flags any kernel message containing "fail" or "error" during probe as a failure. The ath12k_wifi7 driver emitted a benign warning "qmi dma allocation failed (7274496 B type 1), will try later with small size" at line 13.580468s, but immediately recovered by using a smaller allocation size. The driver successfully completed probe: loaded firmware (fw_version 0x1103006c), identified chip (chip_id 0x2), and created a functional wlan0 interface (renamed to wlP4p1s0). The test script does not distinguish between fatal probe failures and recoverable warnings.
3. Possible fix: Update the WiFi_OnOff test script's probe failure detection logic to exclude messages that explicitly indicate recovery ("will try later", "retrying with"). Alternatively, verify driver probe success by checking for positive completion signals (interface creation, firmware load success) rather than only scanning for error keywords. For this specific case, the test should PASS because the WiFi driver is fully functional.
4. Detail analysis attachment: failed_case_job207582_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because HYP (EL2 hypervisor) mode is not available on the purwa-evk platform. The kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware does not support or enable EL2, which is required for KVM virtualization on ARM64.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression. The PR (adding fwnode_gpiod_get() helper) does not touch KVM or virtualization code. Fix: Either (1) enable EL2 support in the platform firmware/bootloader for purwa-evk, or (2) mark KVM tests as expected-fail/skip for platforms without EL2 support in the LAVA test definition.
4. Detail analysis attachment: failed_case_job207582_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a software bug. KVM tests should be excluded from the purwa-evk CI test suite, as this platform lacks the hardware prerequisite (EL2 support) for KVM. Add platform-specific test filtering to skip KVM tests on purwa-evk and other non-virtualization-capable SoCs.
4. Detail analysis attachment: failed_case_job207582_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform firmware configuration, not a kernel bug. To enable KVM on Purwa: (1) Update UEFI/XBL firmware to boot kernel at EL2 instead of EL1, OR (2) If the platform does not support EL2 due to TrustZone/secure firmware reserving it, mark KVM tests as "not applicable" for this board in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job207582_7_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) failed because the purwa-evk platform does not support HYP mode (EL2 virtualization). Kernel message at boot: kvm [1]: HYP mode not available. CONFIG_KVM is enabled in the kernel configuration, but the hardware does not provide the required ARM virtualization extensions.
3. Possible fix: Exclude KVM tests from the LAVA test suite for purwa-evk platform, or configure the CI to skip virtualization tests on platforms that do not support EL2. The PR patch (GPIO helper function addition) is unrelated to this failure - this is a pre-existing platform limitation, not a regression introduced by the PR.
4. Detail analysis attachment: failed_case_job207582_8_detailed.md

Job 207583 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — WiFi Firmware False Positive (Suppressed)

1. Failed case: Probe_Failure_Check — WiFi Firmware False Positive (Suppressed)
2. Root cause: The Probe_Failure_Check test detected a regulatory.db firmware load failure (error -2: ENOENT) during early boot when cfg80211 attempted to load the wireless regulatory database. However, this is a known false positive: the regulatory database is compiled into the kernel (X.509 certificates loaded successfully), and WiFi functionality is fully operational as evidenced by successful WiFi_OnOff and WiFi_Firmware_Driver tests, and the creation of functional interface wlp1s0 on qcs615-ride.
3. Possible fix: Suppress this failure per LAVA Known Benign Failure Suppression Rule 2. The test should be updated to exclude regulatory.db firmware load failures when WiFi functional tests pass, or the test pattern should be refined to distinguish between critical firmware failures and benign regulatory database fallback scenarios where compiled-in certificates are used.
4. Detail analysis attachment: failed_case_job207583_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — video-decoder and video-encoder child devices of the Venus video codec (aa00000.video-codec) are not showing IOMMU group attachments in sysfs, though the parent device is correctly attached to IOMMU group 7. This is a pre-existing platform/test issue on qcs615-ride, not introduced by the PR (which only adds a GPIO helper function).
3. Possible fix: This is not a PR-introduced regression. The test failure is pre-existing and unrelated to the GPIO helper patch. To resolve: (1) verify whether Venus child devices should have explicit iommus properties in qcs615.dtsi, or (2) update the test script to validate parent device IOMMU attachment for drivers that create child devices, rather than expecting each child to have a separate sysfs iommu_group link.
4. Detail analysis attachment: failed_case_job207583_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 or PR regression - it is expected behavior on platforms without virtualization support. To resolve: (1) Skip KVM tests on QCS615 platform in CI configuration, OR (2) Enable EL2/HYP mode in the bootloader/firmware if the hardware supports it, OR (3) Use a different platform with virtualization support for KVM testing.
4. Detail analysis attachment: failed_case_job207583_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on qcs615-ride because the system is running as a guest under Gunyah hypervisor (EL2 not available to guest OS). The kernel message kvm [1]: HYP mode not available at boot confirms KVM detected it cannot access EL2 hypervisor mode, which is required for KVM operation.
3. Possible fix: This is expected behavior, not a bug. The KVM_EL2_DTB test should be skipped on platforms running under a hypervisor (Gunyah). Add a test precondition check to skip KVM tests when /sys/hypervisor/type exists or when the kernel boot log contains "Hypervisor" initialization messages. Alternatively, if KVM support under Gunyah is desired, enable nested virtualization in the Gunyah hypervisor configuration.
4. Detail analysis attachment: failed_case_job207583_4_detailed.md

  Case 5: KVM_Infra (Platform Limitation - Not a Kernel Regression)

1. Failed case: KVM_Infra (Platform Limitation - Not a Kernel Regression)
2. Root cause: qcs615-ride platform does not support KVM virtualization because HYP (EL2) mode is unavailable - the board runs under Gunyah hypervisor which occupies EL2, preventing KVM from initializing and creating /dev/kvm (kernel log line 2692: "kvm [1]: HYP mode not available").
3. Possible fix: Update LAVA test definition to skip KVM tests on qcs615-ride (and other Gunyah-based platforms) by detecting "HYP mode not available" message and reporting SKIP instead of FAIL, as this is a known platform hardware/firmware limitation, not a kernel bug.
4. Detail analysis attachment: failed_case_job207583_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests (KVM_EL2_DTB and KVM_Infra subtests)

1. Failed case: 0_qcom-next-ci-premerge-tests (KVM_EL2_DTB and KVM_Infra subtests)
2. Root cause: QCS615 platform does not support KVM virtualization — kernel reports "HYP mode not available" during KVM initialization, preventing /dev/kvm device creation.
3. Possible fix: Mark KVM tests as "not applicable" or "skip" for QCS615 platform in the LAVA test definition; this is a known platform limitation, not a kernel regression.
4. Detail analysis attachment: failed_case_job207583_6_detailed.md