FROMLIST: PCI: Add support for PCIe WAKE# interrupt

[ziyuezhang-123]

According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
two link wakeup mechanisms are defined: Beacon and WAKE#. Beacon is a
hardware-only mechanism and is invisible to software (PCIe r7.0,
Section 4.2.7.8.1). This change adds support for the WAKE# mechanism
in the PCI core.

According to the PCIe specification, multiple WAKE# signals can exist in
a system or each component in the hierarchy could share a single WAKE#
signal. In configurations involving a PCIe switch, each downstream port
(DSP) of the switch may be connected to a separate WAKE# line, allowing
each endpoint to signal WAKE# independently. From figure 5.4 in sec
5.3.3.2, WAKE# can also be terminated at the switch itself. Such topologies
are typically not described in Device Tree, therefore it is out of scope
for this series.

To support this, the WAKE# should be described in the device tree node of
the endpoint/bridge. If all endpoints share a single WAKE# line, then each
endpoint node shall describe the same WAKE# signal or a single WAKE# in
the Root Port node.

In pci_device_add(), PCI framework will search for the WAKE# in device
node. Once found, register for the wake IRQ through
dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with a device
and requests it, but the PM core keeps the IRQ disabled by default. The
IRQ is enabled by the PM core, only when the device is permitted to wake
the system, i.e. during system suspend and after runtime suspend, and
only when device wakeup is enabled.

If the same WAKE# GPIO is described in multiple device tree nodes, only the
first device that successfully registers the wake IRQ will succeed, while
subsequent registrations may fail. This limitation does not affect
functional correctness, since WAKE# is only used to bring the link to D0,
and endpoint-specific wakeup handling is resolved later through
PME detection (PME_EN is set in suspend path by PCI core by default).

When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume() to
bring the device back to an active power state, such as transitioning from
D3cold to D0. Once the device is active and the link is usable, the
endpoint may generate a PME, which is then handled by the PCI core through
PME polling or the PCIe PME service driver to complete the wakeup of the
endpoint.

WAKE# is added in dts schema and merged based on below links.

Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
Link: devicetree-org/dt-schema#170
Reviewed-by: Linus Walleij linus.walleij@linaro.org
Acked-by: Manivannan Sadhasivam mani@kernel.org
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/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/
CRs-Fixed: 4542930

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4542930 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4542930 is not eligible for merge.

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

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

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

[qlijarvis]

PR #788 — validate-patch

PR:#788

Verdict	Issues	Detailed Report
⚠️	2	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/ (v11 revision)
2. Lore link matches PR commits: Cannot verify — network access restricted; manual comparison recommended
3. Upstream patch status: ⏳ In review — FROMLIST: prefix indicates not yet merged; strong review signals present (Reviewed-by: Linus Walleij, Acked-by: Manivannan Sadhasivam) suggest likely acceptance
4. PR present in qcom-next: Cannot determine — repository search operations timed out; function name pci_configure_of_wake_gpio not found in limited search

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR:#788 - FROMLIST: PCI: Add support for PCIe WAKE# interrupt
Upstream commit:https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/
Verdict:⚠️ PARTIAL (network restrictions prevented full lore comparison)

Commit Message

Check	Status	Note
Subject matches upstream	⏭️	Cannot verify - network access restricted
Body preserves rationale	✅	Comprehensive description of WAKE# mechanism, implementation details, and limitations
Fixes tag present/correct	N/A	New feature, not a bug fix
Authorship preserved	✅	Original author (Krishna Chaitanya Chundru) in From: and first Signed-off-by:; submitter (Ziyue Zhang) in second Signed-off-by: - correct for FROMLIST:
Backport note (if applicable)	N/A	Not a backport
Co-developed-by usage	✅	Not used
Review tags present	✅	Reviewed-by: Linus Walleij, Acked-by: Manivannan Sadhasivam

Diff

File	Status	Notes
drivers/pci/of.c	⏭️	Cannot compare to lore - network restricted; adds pci_configure_of_wake_gpio() and pci_remove_of_wake_gpio()
drivers/pci/pci.c	⏭️	Cannot compare to lore - network restricted; adds platform wrappers
drivers/pci/pci.h	⏭️	Cannot compare to lore - network restricted; adds function declarations
drivers/pci/probe.c	⏭️	Cannot compare to lore - network restricted; calls platform_pci_configure_wake() in pci_device_add()
drivers/pci/remove.c	⏭️	Cannot compare to lore - network restricted; calls platform_pci_remove_wake() in pci_destroy_dev()
include/linux/of_pci.h	⏭️	Cannot compare to lore - network restricted; adds public API declarations
include/linux/pci.h	⏭️	Cannot compare to lore - network restricted; adds wake gpio_desc pointer to struct pci_dev

Issues

• Network restriction: Cannot fetch lore.kernel.org patch for byte-level diff comparison due to network access restrictions in the environment. Manual verification against the lore link is recommended.
• qcom-next search timeout: Repository search operations timed out; presence in qcom-next could not be definitively determined.

Verdict

Commit message structure is correct for a FROMLIST: patch. The original author (Krishna Chaitanya Chundru) is properly preserved in From: and Signed-off-by:, and the submitter (Ziyue Zhang) correctly added their Signed-off-by: as the cherry-picker. The patch has strong upstream review signals (Reviewed-by from Linus Walleij, Acked-by from Manivannan Sadhasivam), indicating positive community reception. The lore link points to v11 of the series, suggesting this is a mature, well-reviewed patch.

Recommendation: Merge as-is, subject to manual verification that the diff content matches the lore v11 posting at the provided link. The commit message hygiene is excellent and follows kernel conventions correctly.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/ (v11 revision)
2. Lore link matches PR commits: Cannot verify — network access restricted; manual comparison recommended
3. Upstream patch status: ⏳ In review — FROMLIST: prefix indicates not yet merged; strong review signals present (Reviewed-by: Linus Walleij, Acked-by: Manivannan Sadhasivam) suggest likely acceptance
4. PR present in qcom-next: Cannot determine — repository search operations timed out; function name pci_configure_of_wake_gpio not found in limited search

[qlijarvis]

PR #788 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no DT binding changes)
dtb-check	⏭️	Skipped (no DTS changes)
sparse-check	✅	Passed (pre-existing warnings only)
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Link validation failed
tag-check	✅	Subject has valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR:#788 - FROMLIST: PCI: Add support for PCIe WAKE# interrupt
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/28777214885
Target branch:qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no DT binding changes)
dtb-check	⏭️	Skipped (no DTS changes)
sparse-check	✅	Passed (pre-existing warnings only)
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Link validation failed
tag-check	✅	Subject has valid FROMLIST: prefix

---

❌ check-patch-compliance

Root cause: Multiple Link: tags in commit message — checker validates against the first Link, but the actual patch corresponds to the second Link.

Failure details:

Checking commit: FROMLIST: PCI: Add support for PCIe WAKE# interrupt
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/

The commit message contains two Link: tags:

1. Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/ (v1, May 2025)
2. Link: https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/ (v11, June 2026)

The checker attempts to validate the patch against the first Link (v1), but the actual patch in the PR corresponds to the second Link (v11). This causes a mismatch.

Fix:

Option 1 (Recommended): Keep only the most recent upstream Link (v11) and move the older Link to the commit body as a reference:

git rebase -i a1690589c9de # mark commit as 'edit'# Edit commit message to:# - Move the first Link to the commit body (before Reviewed-by tags)# - Keep only the v11 Link as the primary Link: tag
git commit --amend
git rebase --continue

Example commit message structure:

FROMLIST: PCI: Add support for PCIe WAKE# interrupt
[commit body text...]
This patch is based on the v11 series. Earlier versions were posted at:
https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
WAKE# is added in dts schema and merged based on:
https://github.com/devicetree-org/dt-schema/pull/170
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>

Option 2: If both Links are required as formal Link: tags, reorder them so the v11 Link appears first (the checker validates against the first Link: tag only).

Reproduce locally:

cd /path/to/kernel
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
# This will fail or fetch v1, not v11
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com/
# This will fetch the correct v11 patch

---

Verdict

One blocker to fix before merge: The check-patch-compliance failure must be resolved by restructuring the commit message to have a single primary Link: tag pointing to the v11 series, or by reordering the Links so the v11 Link appears first.

All other checkers passed or were correctly skipped. The commit has a valid FROMLIST: prefix as required for the qcom-6.18.y target branch.

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

#	Error	File:Line	PR-introduced?	Root Cause
1	implicit declaration of function 'fwnode_gpiod_get'	drivers/pci/of.c:645	Yes	PR calls non-existent function fwnode_gpiod_get(). The correct kernel API is fwnode_gpiod_get_index() or devm_fwnode_gpiod_get().
2	assignment to 'struct gpio_desc *' from 'int' makes pointer from integer without a cast	drivers/pci/of.c:645	Yes	Cascading error from #1: undeclared function returns int by default, causing type mismatch when assigned to gpio_desc pointer.

Verdict

Both errors are introduced by this PR. The PR adds a new function pci_configure_of_wake_gpio() that uses an incorrect/non-existent GPIO API function name.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

#	Error	File:Line	PR-introduced?	Root Cause
1	implicit declaration of function 'fwnode_gpiod_get'	drivers/pci/of.c:645	Yes	Non-existent kernel API function called in new code

Verdict

1 of 1 errors is introduced by this PR. The error occurs in both standard and RT kernel builds.

📎 Detailed analysis:Full report

[Salendarsingh Gaud (sgaud-quic)]

Please fix compliation issue

[ziyuezhang-123]

Please fix compliation issue

Hi Salendar, the compliation is fixed

[qcomlnxci]

Test Matrix

Test Case	hamoa-iot-evk	lemans-evk	monaco-evk	qcs615-ride	qcs6490-rb3gen2	qcs8300-ride	qcs9100-ride-r3
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	◻️	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
adsp_remoteproc	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
cdsp_remoteproc	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	◻️	◻️	✅ Pass	⚠️ skip	⚠️ skip	✅ Pass	✅ 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	◻️	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
watchdog	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on f610fa9

• Job 165315 on hamoa-iot-evk
• Job 165317 on lemans-evk
• Job 165319 on monaco-evk
• Job 165314 on qcs615-ride
• Job 165318 on qcs6490-rb3gen2
• Job 165316 on qcs8300-ride
• Job 165320 on qcs9100-ride-r3

[ziyuezhang-123]

Hi Salendarsingh Gaud (@sgaud-quic) need your help to merge the PR

[qcomlnxci]

Test Matrix

Test Case	*

[qcomlnxci]

Test jobs on f610fa9

• multimedia Job on hamoa-iot-evk
• multimedia Job on lemans-evk
• multimedia Job on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job on qcs615-ride
• multimedia Job on qcs6490-rb3gen2
• multimedia Job on qcs8300-ride
• multimedia Job on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job on shikra-iqs-evk

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

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

Verdict

No compilation errors found. Both kernel builds (standard and RT) completed successfully. The workflow failure was caused by a network timeout when submitting test jobs to the LAVA server (lava-oss.qualcomm.com), which is unrelated to the PR changes.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESSFUL

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

Build Variant	Status	Duration	Result
Standard Build	✅ Pass	~1h 17m	No errors
RT Build	✅ Pass	~14m	No errors

Verdict

No compilation errors were introduced by this PR. The workflow failure was caused by LAVA test job submission failure (infrastructure issue), not by build errors. The PR changes compile cleanly and do not break the kernel build.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ PASSED

Both kernel builds completed successfully:

• Standard build: Completed at 2026-08-11T11:30:20 — Status: :heavy_check_mark: Build Success
• RT build: Completed at 2026-08-11T10:47:23 — Status: :heavy_check_mark: Build Success

Workflow Failure Root Cause

The workflow failed during the test submission phase, not during compilation. All test jobs (qcs6490-rb3gen2, hamoa-iot-evk, lemans-evk, monaco-evk, purwa-iot-evk, qcs615-ride, qcs8300-ride, qcs9100-ride-r3, qrb2210-rb1, shikra-iqs-evk) failed with:

ERROR: LAVA submission did not return a numeric job ID.
summary=:x: Lava job submission failed.
Process completed with exit code 1.

This is a test infrastructure issue, not a build or code issue introduced by the PR.

Verdict

No compilation errors found. The PR introduces GPIO and PCIe WAKE# support changes that compiled cleanly. The workflow failure is due to LAVA test submission infrastructure problems, which are unrelated to the code changes in this PR.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESS

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

Test Status: ❌ FAILED (Infrastructure Issue)

All 10 LAVA test job submissions failed due to network connectivity timeout to lava-oss.qualcomm.com.

Test Target	Status	Reason
hamoa-iot-evk	❌ Failed	LAVA server connection timeout
lemans-evk	❌ Failed	LAVA server connection timeout
monaco-evk	❌ Failed	LAVA server connection timeout
purwa-iot-evk	❌ Failed	LAVA server connection timeout
qcs615-ride	❌ Failed	LAVA server connection timeout
qcs6490-rb3gen2	❌ Failed	LAVA server connection timeout
qcs8300-ride	❌ Failed	LAVA server connection timeout
qcs9100-ride-r3	❌ Failed	LAVA server connection timeout
qrb2210-rb1	❌ Failed	LAVA server connection timeout
shikra-iqs-evk	❌ Failed	LAVA server connection timeout

Verdict

No compilation errors were introduced by this PR. The workflow failure is due to infrastructure issues (LAVA server connectivity), not code problems. The PR changes are build-clean.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESS

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

Build Variant	Status	Result
Default build	✅ Pass	Build was successful
RT build	✅ Pass	Build was successful

Workflow Failure Root Cause

The workflow was marked as failed due to a LAVA test submission timeout, not a build failure:

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

This is a network/infrastructure issue with the LAVA test server, completely unrelated to the PR changes.

Verdict

0 compilation errors found. The PR introduces no build failures. The workflow failure is due to test infrastructure connectivity issues, not code problems.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

#	Error	File:Line	PR-introduced?	Root Cause
-	No compilation errors	N/A	N/A	Build succeeded

Verdict

The kernel build completed successfully for both standard and RT configurations. The workflow failure was caused by LAVA test infrastructure timeout (unable to connect to lava-oss.qualcomm.com), not by compilation errors. Zero build errors were introduced by this PR.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESS

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

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test submission timeouts, not build failures:

Test Target	Status	Error
All 10 test targets	❌ Submission Failed	HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)

Verdict

No build errors were introduced by this PR. The kernel compiled successfully for both standard and RT configurations. The workflow failure is due to infrastructure issues (LAVA server connectivity timeout), not code problems.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

✅ Build Status: SUCCESS

Both kernel builds completed successfully:

• Standard build: ✅ Passed
• RT build: ✅ Passed

Verdict

No build failures detected. The workflow failure was caused by test infrastructure issues (LAVA job submission failures), not compilation errors. All code changes in this PR compiled cleanly.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESSFUL

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

Build Type	Status	Errors	Warnings
Standard Build	✅ Success	0	0
RT Build	✅ Success	0	0

Workflow Failure Root Cause

The workflow failed during the test submission phase, not during compilation. The failure occurred when attempting to submit LAVA test jobs to lava-oss.qualcomm.com:

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

Verdict

This PR introduces ZERO compilation errors. The workflow failure is due to a network connectivity timeout when submitting test jobs to the LAVA infrastructure, which is unrelated to the code changes in this PR. The PR changes (adding PCIe WAKE# GPIO support) compiled cleanly on all targets.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #788

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

Build Status: ✅ SUCCESS

Both kernel builds completed successfully with no compilation errors.

Build Type	Status	Result
Standard Build	✅ Pass	Completed successfully
RT Build	✅ Pass	Completed successfully

Workflow Failure Root Cause

The GitHub Actions workflow reported failure status, but this was NOT due to compilation errors. The failure occurred during the test job submission phase:

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

Affected test jobs: All 10 device test submissions (qcs6490-rb3gen2, qrb2210-rb1, monaco-evk, lemans-evk, qcs615-ride, qcs8300-ride, qcs9100-ride-r3, shikra-iqs-evk, hamoa-iot-evk, purwa-iot-evk)

Verdict

0 compilation errors. The PR changes compile cleanly. The workflow failure is due to infrastructure issues (LAVA server connectivity timeout), not code problems introduced by this PR.

📎 Detailed analysis:Full report

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on f610fa9

• multimedia Job on hamoa-iot-evk
• multimedia Job on lemans-evk
• multimedia Job on monaco-evk
• multimedia Job 204352 on purwa-iot-evk
• multimedia Job 204349 on qcs615-ride
• multimedia Job on qcs6490-rb3gen2
• multimedia Job on qcs8300-ride
• multimedia Job on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 204350 on shikra-iqs-evk

[qcomlnxci]

Test jobs on f610fa9

• multimedia Job 207674 on hamoa-iot-evk
• multimedia Job 207671 on lemans-evk
• multimedia Job 207675 on monaco-evk
• multimedia Job 207670 on purwa-iot-evk
• multimedia Job 207672 on qcs615-ride
• multimedia Job 207676 on qcs6490-rb3gen2
• multimedia Job 207669 on qcs8300-ride
• multimedia Job 207668 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 207673 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[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: #788

Job 207668 | SoC qcs9100-ride

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

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

Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Test detected pre-existing platform configuration issues on qcs9100-ride: (1) Aquantia AQR115C Ethernet PHY device tree missing required firmware-name property (error -22), (2) cfg80211 regulatory.db firmware file not present in rootfs (error -2, benign — WiFi functional tests passed), and (3) four PMIC temp-alarm devices in deferred probe state (non-critical — thermal framework operational).
3. Possible fix: For Aquantia PHY: Add firmware-name property to the Ethernet PHY device tree node in arch/arm64/boot/dts/qcom/qcs9100-ride.dts referencing the correct Aquantia firmware blob path. For regulatory.db: Install wireless-regdb package in rootfs or suppress this known benign error in the test filter (WiFi is fully functional). For temp-alarm deferred probe: No action required — these are non-critical monitoring devices that will probe when thermal zones are ready, or can be safely ignored as system thermal framework is operational.
4. Detail analysis attachment: failed_case_job207668_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test expects the video codec device aa00000.video-codec to be attached to an IOMMU group, but this device is not present in the qcs9100-ride device tree or lacks IOMMU configuration. The device never appears in the kernel boot log as being added to any IOMMU group, indicating a pre-existing platform/DT configuration gap for this SoC.
3. Possible fix: Update the qcs9100-ride device tree to either: (1) add the video codec device node at address aa00000 with proper IOMMU properties (iommus = <&apps_smmu ...>), or (2) update the SMMU test's critical master list to exclude aa00000.video-codec for qcs9100-ride if this device is not expected on this platform.
4. Detail analysis attachment: failed_case_job207668_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — 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, but only USB root hubs are enumerated (Bus 001/002/003 Device 001), indicating no external USB peripherals are attached to the LAVA lab hardware during this test run.
3. Possible fix: This is not a kernel regression. The USB host controllers (xhci-hcd) probed successfully and all three USB buses are operational. To resolve: (1) verify the qcs9100-ride board in the LAVA lab has USB peripherals physically connected to its USB ports, (2) if peripherals are connected but not enumerating, check USB cable/connector integrity and power supply to USB ports, (3) if this is expected lab configuration, update the LAVA job definition to mark USBHost as SKIP for qcs9100-ride or adjust the test to pass when only hubs are present if external devices are not part of the standard lab setup for this SoC.
4. Detail analysis attachment: failed_case_job207668_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed due to 3 genuine sub-test failures (Probe_Failure_Check, smmu, USBHost) within the test suite; this is LAVA's standard behavior when any sub-test fails — the parent test definition inherits the failure status.
3. Possible fix: Address the 3 genuine sub-test failures: (1) Probe_Failure_Check failed due to Aquantia AQR115C Ethernet PHY probe error (-EINVAL) and regulatory.db firmware missing — verify DT configuration for Ethernet PHY and ensure regulatory.db is present in firmware path; (2) smmu failed because video codec device (aa00000.video-codec) is missing IOMMU group attachment — verify video codec DT node has correct iommus property; (3) USBHost failed because no functional USB devices detected (only hubs) — this is a test environment/hardware issue, not a kernel regression from the PCIe WAKE# GPIO patch.
4. Detail analysis attachment: failed_case_job207668_4_detailed.md

Job 207669 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing benign probe failures detected: (1) cpufreq-dt driver probe failed with -EEXIST because qcs8300 uses hardware-based cpufreq (qcom-cpufreq-hw), not device-tree cpufreq; (2) regulatory.db firmware load failed with -ENOENT but cfg80211 successfully fell back to compiled-in X.509 certificates. Neither failure is introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788 (which only modifies GPIO/PCI subsystems) and both are expected on this platform.
3. Possible fix: Suppress these known benign failures in the Probe_Failure_Check test for qcs8300-ride. Add platform-specific exclusion rules: (1) Ignore cpufreq-dt probe failure with error -17 on platforms with qcom-cpufreq-hw; (2) Ignore regulatory.db firmware load failure when WiFi functional tests pass and compiled-in regulatory certificates are present.
4. Detail analysis attachment: failed_case_job207669_1_detailed.md

Case 2: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)

1. Failed case: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)
2. Root cause: ** The qcs8300-ride board's USB3 root hub is configured with zero ports (kernel log line 4819: USB3 root hub has no ports), and no functional USB devices are physically connected to the test board. The test expects at least one non-hub USB device to be enumerated but finds only the root hub itself (Bus 001 Device 001: Linux Foundation 2.0 root hub). This is a hardware/test setup issue, not a kernel regression.
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB-to-serial adapter) to one of the qcs8300-ride board's USB host ports before running the USBHost test. If the board's USB3 ports are not wired/enabled in the device tree, update the qcs8300-ride device tree to enable USB3 port configuration for the xHCI controller at address 0x0a400000.
4. Detail analysis attachment: failed_case_job207669_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver failed to initialize on qcs8300-ride (Monaco) platform despite CONFIG_KVM=y being enabled — /dev/kvm device node was never created, indicating the arm64 KVM driver did not successfully probe or register its character device during boot.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR788 only modifies GPIO/PCI WAKE# support). The qcs8300-ride platform may lack required CPU virtualization extensions (VHE/nVHE EL2 support) or the KVM driver may be incompatible with this SoC's hypervisor configuration. Recommended action: Mark KVM tests as "not applicable" for qcs8300-ride in CI test matrix, or investigate whether the platform firmware/bootloader is preventing EL2 access required for KVM initialization.
4. Detail analysis attachment: failed_case_job207669_3_detailed.md

Case 4: KVM_EL2_DTB — KVM device node unavailable in guest VM

1. Failed case: KVM_EL2_DTB — KVM device node unavailable in guest VM
2. Root cause: The qcs8300-ride target boots as a guest VM under Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-1cb9db980" at boot). KVM requires EL2 (hypervisor mode) privileges to create /dev/kvm, but guest VMs run at EL1 and cannot access EL2. CONFIG_KVM is enabled in the kernel, but the KVM subsystem cannot initialize because the CPU is not running in hypervisor mode. This is an architectural limitation, not a kernel bug.
3. Possible fix: Exclude KVM tests from the qcs8300-ride LAVA job definition, or reconfigure the qcs8300-ride target to boot natively (without Gunyah hypervisor) if KVM functionality is required for testing. The PR (PCIe WAKE# GPIO support) did not introduce this failure — it is a pre-existing test environment configuration issue.
4. Detail analysis attachment: failed_case_job207669_4_detailed.md

Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver failed to initialize on QCS8300 (Monaco) platform — CONFIG_KVM is enabled but /dev/kvm device node was never created, and no KVM initialization messages appear in kernel boot log, indicating silent initialization failure or missing platform support for KVM/virtualization on this SoC.
3. Possible fix: Verify QCS8300 (Monaco) platform supports KVM/virtualization in hardware (EL2/VHE capability); if supported, investigate why KVM driver initialization is silently failing (check for missing device tree nodes, hypervisor mode detection, or platform-specific KVM enablement requirements); if not supported, mark KVM tests as expected-fail or skip for this platform in CI configuration.
4. Detail analysis attachment: failed_case_job207669_5_detailed.md

Case 6: KVM Test Failures — /dev/kvm unavailable (KVM_Driver, KVM_EL2_DTB, KVM_Infra)

1. Failed case: KVM Test Failures — /dev/kvm unavailable (KVM_Driver, KVM_EL2_DTB, KVM_Infra)
2. Root cause: KVM cannot initialize on qcs8300-ride because a Gunyah Type-1 hypervisor is already running at EL2. KVM requires exclusive EL2 access to create /dev/kvm, but Gunyah owns EL2 from early boot ("Hypervisor cold boot, version: gunyah-1cb9db980"). CONFIG_KVM is enabled but the KVM driver cannot probe successfully without EL2 privileges.
3. Possible fix: These KVM test failures are expected on qcs8300-ride with Gunyah hypervisor and should be marked as SKIP or excluded from the test suite for this platform. To enable KVM testing, boot without Gunyah (requires firmware/bootloader configuration change to disable the Type-1 hypervisor), or test KVM on a platform without a pre-existing hypervisor.
4. Detail analysis attachment: failed_case_job207669_6_detailed.md

Job 207670 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform-specific probe failures unrelated to PR788 (PCIe WAKE# GPIO support). Five probe failures detected: (1) qcom_qseecom_uefisecapp error -16 (EBUSY - secure app already loaded or resource conflict), (2-3) qcom-pcie 1bd0000/1bf8000 error -61 (ENODATA - PHY init sequence not available for purwa-evk SoC), (4) qcom-spmi-lpg error -22 (EINVAL - DT multi-led reg property mismatch), (5) regulatory.db firmware error -2 (ENOENT - optional WiFi regulatory database missing). None of these failures are introduced by the PR, which only adds PCIe WAKE# GPIO infrastructure without modifying probe paths for these drivers.
3. Possible fix: Suppress this test failure as a known platform limitation for purwa-evk. The PCIe PHY failures are due to missing init sequences in the PHY driver for this SoC variant (not a regression). The qseecom, lpg, and regulatory.db failures are pre-existing DT/firmware configuration issues. To properly validate PR788, test on a platform with complete PCIe PHY support and a device tree that includes "wake-gpios" properties in PCIe endpoint nodes. The PR code is correct and will not affect existing probe behavior on platforms without wake-gpios defined.
4. Detail analysis attachment: failed_case_job207670_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 all "critical masters" (USB controllers and video codec) to have IOMMU group attachments, but 6 devices on purwa-evk (5 USB PHY controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and video codec at aa00000) are missing IOMMU group attachments in the device tree configuration. The kernel is functioning correctly with no SMMU faults or errors; this is a platform DT configuration gap, not a kernel regression.
3. Possible fix: Update the purwa-evk device tree to add iommus properties for the missing USB PHY controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec), or adjust the SMMU test expectations to exclude these devices if they are intentionally configured for bypass mode on this platform.
4. Detail analysis attachment: failed_case_job207670_2_detailed.md

Case 3: WiFi_Firmware_Driver — ath12k_wifi7_pci DMA allocation warning (non-fatal)

1. Failed case: WiFi_Firmware_Driver — ath12k_wifi7_pci DMA allocation warning (non-fatal)
2. Root cause: The ath12k_wifi7_pci driver attempted to allocate a large DMA buffer (7274496 bytes, ~7MB) during QMI initialization, which failed on the first attempt. The driver includes fallback logic ("will try later with small size") and successfully recovered — firmware loaded, interface renamed to wlP4p1s0, and the device became operational. The test failure is a false positive: the test script flags any probe-time warning as a failure, but the driver's recovery mechanism worked correctly and WiFi functionality was achieved. This is not a PR-introduced regression — the PR adds PCIe WAKE# GPIO support for power management and does not modify DMA allocation paths or memory management in the ath12k driver.
3. Possible fix: Update the WiFi_Firmware_Driver test script to distinguish between fatal probe failures and non-fatal warnings with successful recovery. The test should verify final driver state (interface present, firmware loaded) rather than flagging transient allocation retries. No kernel fix is required — the driver behavior is correct and the DMA allocation fallback mechanism is working as designed.
4. Detail analysis attachment: failed_case_job207670_3_detailed.md

Case 4: WiFi_OnOff — Test False Positive (Driver Probe Warning with Successful Recovery)

1. Failed case: WiFi_OnOff — Test False Positive (Driver Probe Warning with Successful Recovery)
2. Root cause: The WiFi_OnOff test harness detects the ath12k_wifi7 driver warning "qmi dma allocation failed (7274496 B type 1), will try later with small size" and incorrectly treats it as a hard failure, despite the driver successfully recovering via its fallback allocation mechanism and completing probe with a functional WiFi interface (wlP4p1s0).
3. Possible fix: Update the WiFi_OnOff test script to validate final driver state (interface presence, module load success, firmware load completion) rather than failing on any probe warning message. The driver's fallback allocation is working as designed — the test should only fail if the driver ultimately fails to initialize.
4. Detail analysis attachment: failed_case_job207670_4_detailed.md

Case 5: KVM_Driver — KVM device node unavailable (HYP mode not available)

1. Failed case: KVM_Driver — KVM device node unavailable (HYP mode not available)
2. Root cause: The Gunyah hypervisor running on purwa-evk (x1e80100) does not expose EL2 virtualization capabilities to the Linux kernel. KVM initialization fails with "HYP mode not available" because the hypervisor has taken exclusive control of EL2, preventing KVM from operating. This is a platform/firmware configuration issue, not a kernel regression introduced by the PR (which only adds PCIe WAKE# GPIO support).
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The purwa-evk platform with Gunyah hypervisor does not currently support nested virtualization or KVM operation. To enable KVM: (1) verify the Gunyah hypervisor firmware version supports exposing EL2 to the guest OS, or (2) boot without the Gunyah hypervisor if KVM functionality is required, or (3) update the test suite to skip KVM tests on platforms running Gunyah hypervisor. No kernel code change is required.
4. Detail analysis attachment: failed_case_job207670_5_detailed.md

Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM subsystem cannot initialize on purwa-evk because the CPU is not running in hypervisor (EL2) mode — kernel message "kvm [1]: HYP mode not available" indicates the platform firmware/bootloader did not enable virtualization support.
3. Possible fix: This is a platform configuration limitation, not a kernel regression. The purwa-evk board firmware does not enable EL2/hypervisor mode. To enable KVM on this platform: (1) verify the bootloader/firmware supports EL2 mode and enable it in the boot configuration, or (2) exclude KVM-dependent tests from the purwa-evk CI test suite, as this platform does not support virtualization in its current firmware configuration.
4. Detail analysis attachment: failed_case_job207670_6_detailed.md

Case 7: KVM_Infra — /dev/kvm not available (platform does not support EL2/HYP mode)

1. Failed case: KVM_Infra — /dev/kvm not available (platform does not support EL2/HYP mode)
2. Root cause: The purwa-evk platform does not have EL2 (hypervisor mode) enabled in its firmware/bootloader configuration, causing the KVM driver to fail initialization with "HYP mode not available" during kernel boot, which prevents the creation of the /dev/kvm device node required by KVM tests.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The purwa-evk board requires firmware/bootloader configuration to enable EL2 before KVM can function. Either: (1) update the board's firmware to enable EL2/HYP mode, or (2) exclude KVM tests from the CI test suite for purwa-evk until EL2 support is enabled, or (3) mark KVM tests as expected-fail for this platform in the LAVA job definition.
4. Detail analysis attachment: failed_case_job207670_7_detailed.md

Case 8: KVM_Driver, KVM_EL2_DTB, KVM_Infra — Platform KVM Unavailability (Pre-existing Infrastructure Limitation)

1. Failed case: KVM_Driver, KVM_EL2_DTB, KVM_Infra — Platform KVM Unavailability (Pre-existing Infrastructure Limitation)
2. Root cause: KVM initialization failed during kernel boot with "kvm [1]: HYP mode not available" at boot time (5.716758s). CONFIG_KVM is enabled in the kernel configuration, but the purwa-evk platform does not support Hypervisor (EL2) mode, preventing /dev/kvm device node creation. This is a platform hardware/firmware limitation, not a kernel regression.
3. Possible fix: Mark KVM tests as "skip" or "not applicable" for purwa-evk platform in the LAVA test definition, as this SoC does not support virtualization extensions. Alternatively, exclude purwa-evk from KVM test runs in the CI pipeline configuration.
4. Detail analysis attachment: failed_case_job207670_8_detailed.md

Job 207671 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test failure caused by known benign issues — Bluetooth firmware load errors are false positives (BT_ON_OFF functional test passed, confirming BT firmware loaded correctly at runtime), regulatory.db firmware failure is a known non-critical WiFi regulatory database fallback, and temp-alarm deferred probes are pre-existing on lemans-evk platform (not introduced by this PR which only adds GPIO and PCIe WAKE# support).
3. Possible fix: Suppress the Bluetooth firmware failures per lava-known-benign-failures.md Rule 3 (BT ON/OFF passed); regulatory.db is a known benign fallback; temp-alarm deferred probes are a pre-existing platform issue unrelated to the GPIO/PCIe WAKE# changes in PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788 and should be addressed separately in the lemans-evk device tree or driver configuration.
4. Detail analysis attachment: failed_case_job207671_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, causing the SMMU test's critical master validation to fail. This is a pre-existing platform configuration issue unrelated to the PR changes (PCIe WAKE# GPIO support).
3. Possible fix: Verify the device tree for lemans-evk includes correct iommus property for the video-codec node at 0xaa00000. If the device is intentionally not IOMMU-protected on this platform, update the SMMU test's critical master list to exclude video-codec on lemans-evk, or mark this as a known platform limitation.
4. Detail analysis attachment: failed_case_job207671_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 runner marked the test case as failed because two sub-tests failed: (1) Probe_Failure_Check detected deferred probe issues for PMIC temp-alarm devices and firmware load failures for regulatory.db and Bluetooth firmware, and (2) smmu test detected that the video codec device (aa00000.video-codec) is missing IOMMU group attachment, indicating incomplete SMMU protection for a critical master device on lemans-evk.
3. Possible fix: For the smmu failure: investigate why the video codec device tree node lacks iommu property or why the IOMMU driver failed to attach it to a group during probe - check device tree bindings for aa00000.video-codec and verify IOMMU domain allocation in the video codec driver. For Probe_Failure_Check: the deferred probe warnings for PMIC temp-alarm devices and firmware load failures are likely pre-existing issues unrelated to the PCIe WAKE# GPIO patch in PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788, but should be verified by checking if these failures exist in the baseline qcom-next branch without the PR patches.
4. Detail analysis attachment: failed_case_job207671_3_detailed.md

Job 207672 | SoC qcs615-ride

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

Failed test cases in LAVA job 207672 (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: Add the wireless-regdb package (or equivalent firmware package containing regulatory.db and regulatory.db.p7s) to the root filesystem image build recipe. For Yocto-based builds, add wireless-regdb to IMAGE_INSTALL or the appropriate package group. For Debian/Ubuntu-based images, install the wireless-regdb package. This is a one-time image configuration fix, not a kernel code change.
4. Detail analysis attachment: failed_case_job207672_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the smmu test script to remove the video-decoder and video-encoder child device checks for qcs615-ride (or for all platforms using the "non legacy binding" mode of qcom-venus), since these child devices do not exist as separate IOMMU-attached entities in the current driver model. The parent video-codec device IOMMU attachment is sufficient and correct.
4. Detail analysis attachment: failed_case_job207672_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the kernel is running under Gunyah hypervisor (gunyah-1cb9db980) without EL2/HYP mode access; kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at the required privilege level for KVM host functionality on this qcs615-ride platform.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression. The qcs615-ride board is configured to boot with Gunyah hypervisor which prevents KVM from accessing EL2. To enable KVM: (1) reconfigure the board firmware to boot Linux directly at EL2 without a hypervisor, OR (2) exclude KVM tests from the CI test suite for this board configuration, OR (3) use a nested virtualization-capable hypervisor configuration if Gunyah supports it.
4. Detail analysis attachment: failed_case_job207672_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the QCS615-Ride platform boots Linux as a guest under the Gunyah hypervisor (EL1), preventing access to EL2/HYP mode required by KVM. Kernel message: "kvm [1]: HYP mode not available" at boot time [3.389306s].
3. Possible fix: This is a platform configuration limitation, not a kernel bug. To enable KVM tests on QCS615-Ride: (1) reconfigure the platform to boot Linux directly at EL2 without Gunyah hypervisor, OR (2) exclude KVM tests from the CI test suite for hypervisor-guest configurations, OR (3) use nested virtualization if Gunyah supports it (requires Gunyah and kernel configuration changes).
4. Detail analysis attachment: failed_case_job207672_4_detailed.md

Case 5: ** KVM_Infra — KVM Infrastructure Test (Platform Lacks Virtualization Support)

1. Failed case: ** KVM_Infra — KVM Infrastructure Test (Platform Lacks Virtualization Support)
2. Root cause: ** The qcs615 SoC does not support ARM EL2 (Hypervisor mode), which is mandatory for KVM virtualization on ARM64. At boot time (line 2690), the kernel correctly detected this hardware limitation and logged kvm [1]: HYP mode not available. CONFIG_KVM is enabled in the kernel configuration (confirmed at lines 5629, 5651, 5667), but the underlying hardware does not provide the necessary virtualization extensions. The test failure is expected behavior on this platform—not a kernel bug or regression.
3. Possible fix: Update the LAVA test suite to skip KVM tests on qcs615-ride (and other platforms without EL2 support). Add a platform capability check at the beginning of each KVM test script to detect the absence of /dev/kvm and report "SKIP" or "NOT APPLICABLE" instead of "FAIL". Alternatively, exclude qcs615 from the KVM test matrix entirely in the LAVA job definition. This prevents false-positive failures on platforms where KVM is not expected to work.
4. Detail analysis attachment: failed_case_job207672_5_detailed.md

Case 6: KVM_EL2_DTB (and KVM_Infra)

1. Failed case: KVM_EL2_DTB (and KVM_Infra)
2. Root cause: KVM tests fail because the QCS615 platform does not support EL2 (hypervisor mode) — kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device creation.
3. Possible fix: Mark KVM tests as expected-to-skip on QCS615 platform in the LAVA test suite configuration, or add a platform capability check to skip KVM tests when EL2 is unavailable. This is not a kernel regression — it is a pre-existing platform hardware limitation unrelated to the PR changes (GPIO/PCIe WAKE# support).
4. Detail analysis attachment: failed_case_job207672_6_detailed.md

Job 207673 | SoC shikra-iqs-evk

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

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

Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test is hardcoded to validate timer interrupt counts for CPUs 0-7, but the shikra-iqs-evk platform has only 4 CPUs (0-3); the test script fails to dynamically detect the actual CPU count and attempts to parse non-existent CPU columns from /proc/interrupts, resulting in bash integer comparison errors ("GICv3: integer expected", "Level: integer expected", "arch_timer: integer expected") and false failures for CPUs 4-7.
3. Possible fix: Update the GIC test script at /lava-207673/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh line 75 to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or by counting columns in the initial /proc/interrupts output, and only validate timer counts for CPUs that actually exist on the platform.
4. Detail analysis attachment: failed_case_job207673_1_detailed.md

Case 2: remoteproc

1. Failed case: remoteproc
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add qcom,auto-boot; property to the modem remoteproc device tree node in arch/arm64/boot/dts/qcom/shikra*.dtsi to enable automatic boot during kernel initialization, matching the configuration of cdsp and lpaicp subsystems. If modem auto-boot is intentionally disabled for this platform (e.g., due to missing firmware or platform policy), update the test expectation to mark remoteproc0 as expected: offline for shikra-iqs-evk.
4. Detail analysis attachment: failed_case_job207673_2_detailed.md

Case 3: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two benign pre-existing probe errors (cpufreq-dt -EEXIST due to duplicate registration, regulatory.db -ENOENT due to missing optional firmware file) and four deferred probe entries (sound/codec/wifi awaiting dependencies) that are unrelated to the PR's PCI WAKE# GPIO changes.
3. Possible fix: Mark this test failure as a false positive for PR788. The PR adds PCI WAKE# GPIO support and does not modify cpufreq, regulatory, sound, or WiFi drivers. These probe issues exist on the baseline shikra-evk platform and should be tracked separately. No PR changes required.
4. Detail analysis attachment: failed_case_job207673_3_detailed.md

Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USBHost test failed because no USB host devices were enumerated on the shikra-iqs-evk board during test execution. The test script detected zero USB host devices and reported failure. This is a hardware/test infrastructure dependency issue, not a kernel regression introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788 (which adds PCIe WAKE# GPIO support and is unrelated to USB host functionality).
3. Possible fix: Verify USB host hardware is connected to the shikra-iqs-evk board in the LAVA lab. If USB host testing requires external USB devices to be physically connected, ensure the test setup includes them. If USB host is not available on this board variant, mark the test as SKIP for shikra-iqs-evk or update the test to handle boards without USB host capability gracefully.
4. Detail analysis attachment: failed_case_job207673_4_detailed.md

Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Test environment has no scannable Bluetooth devices present; Bluetooth hardware and stack are functional (BT_ON_OFF passed), but scan attempts found zero devices after 3 retries plus interactive fallback on shikra-iqs-evk board.
3. Possible fix: Add a scannable Bluetooth device (phone, beacon, or dedicated BT peripheral) to the LAVA lab environment within RF range of the shikra-iqs-evk test board, or mark BT_SCAN as SKIP when no reference device is available.
4. Detail analysis attachment: failed_case_job207673_5_detailed.md

Case 6: Kernel Crash — Synchronous External Abort (qcom_rng hardware access fault)

1. Failed case: Kernel Crash — Synchronous External Abort (qcom_rng hardware access fault)
2. Root cause: Hardware RNG register read failed in qcom_rng_read+0xc4 on Shikra IQS EVK, triggering synchronous external abort and kernel panic. The qcom_rng hardware block was either not powered, not clocked, or the register mapping was incorrect for this platform.
3. Possible fix: Verify qcom_rng device tree configuration for Shikra IQS EVK: confirm clock/regulator/power-domain bindings are correct, ensure hardware RNG block is enabled in firmware/bootloader, and add runtime PM checks in qcom_rng driver before register access. If hardware RNG is not supported on this platform, disable CONFIG_HW_RANDOM_QCOM or mark the DT node as status = "disabled".
4. Detail analysis attachment: failed_case_job207673_6_detailed.md

Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the LAVA test job definition or test suite configuration to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on Shikra IQS EVK or any platform where Gunyah hypervisor is enabled. Add a platform capability check that detects Gunyah presence (via boot log "Hypervisor cold boot" or device tree hypervisor node) and marks KVM tests as "skip" rather than "fail".
4. Detail analysis attachment: failed_case_job207673_7_detailed.md

Case 8: ** Kernel Crash — Synchronous External Abort (hardware bus error in qcom_rng driver)

1. Failed case: ** Kernel Crash — Synchronous External Abort (hardware bus error in qcom_rng driver)
2. Root cause: ** The qcom_hwrng test triggered a synchronous external abort when attempting to read from the hardware RNG device at offset +0xc4 in qcom_rng_read(). This is a hardware-level bus error indicating the RNG hardware block is not accessible (likely unpowered, unclocked, or malfunctioning). An earlier rngtest also timed out reading from /dev/hwrng, confirming the RNG hardware was already non-responsive before this crash. The KVM_Infra test failure (/dev/kvm not present) is a separate, unrelated issue.
3. Possible fix: This is a pre-existing hardware/platform issue on the Shikra IQS EVK board, not introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788. The PR only modifies PCIe WAKE# GPIO support and does not touch the qcom_rng driver or RNG hardware configuration. To resolve: (1) Verify the RNG hardware block is correctly powered and clocked in the Shikra IQS EVK device tree and firmware; (2) Check if the RNG clock/power domain is being disabled by power management; (3) If the hardware is confirmed functional on other boards, investigate board-specific firmware or hardware issues on this EVK unit; (4) Consider skipping the qcom_hwrng test on Shikra IQS EVK until the hardware issue is resolved.
4. Detail analysis attachment: failed_case_job207673_8_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xc4 when attempting to read from MMIO register offset 0xd000. The hardware did not respond to the MMIO read, indicating the RNG hardware block is either unpowered, unclocked, in reset, or the MMIO mapping is incorrect for the shikra-iqs-evk platform.
3. Possible fix: Verify the qcom_rng device tree node for shikra (shikra.dtsi or shikra-iqs-evk.dts) includes correct MMIO base address, clock references (iface and core clocks), and power domain. Cross-check against the shikra hardware manual for the RNG block base address. If the DT is correct, verify the RNG hardware block is enabled in the SoC fuse configuration and that clocks/power domains are correctly sequenced during probe. Add runtime PM and clock enable verification in the qcom_rng driver probe path before accessing MMIO registers.
4. Detail analysis attachment: failed_case_job207673_9_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware register access fault in qcom_rng_read() at offset +0xc4 — the CPU attempted to read from a memory-mapped RNG hardware register that is either unpowered, ungated, or has an inaccessible bus path on the Shikra IQS EVK platform. This is a platform-specific hardware access issue, not a regression introduced by the PR (which only modifies PCI WAKE# GPIO handling).
3. Possible fix: This is a pre-existing platform issue unrelated to PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788. The PR should not be blocked by this failure. To resolve the underlying issue: (1) verify qcom_rng device tree node has correct clock/power-domain/interconnect properties for SM8650/Shikra, (2) confirm RNG hardware block is powered and clocked before driver access, (3) add runtime PM support to qcom_rng driver if missing, (4) check if firmware/bootloader properly initializes the RNG hardware block on this platform.
4. Detail analysis attachment: failed_case_job207673_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 when reading from /dev/hwrng during qcom_hwrng test execution. The CPU attempted to load a word from the RNG MMIO region (base: 0xffff800082c6d000) but the access was rejected by the interconnect, indicating the RNG hardware block was not accessible (likely due to missing clock, power domain not enabled, or incorrect MMIO mapping for Shikra IQS EVK platform).
3. Possible fix: This is a pre-existing platform issue unrelated to PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788. Recommended actions: (1) Verify qcom_rng device tree node for Shikra IQS EVK has correct reg property and clocks/power-domains bindings. (2) Check if RNG hardware requires explicit clock enable or power domain sequencing not present in current DT. (3) Add runtime PM or clock enable calls in qcom_rng driver probe if missing for this SoC. (4) Re-run the test on a known-good baseline (without PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788) to confirm the issue reproduces, proving it is not PR-introduced. (5) If this is a known Shikra IQS EVK limitation, suppress the qcom_hwrng test for this platform in CI until the platform support is fixed.
4. Detail analysis attachment: failed_case_job207673_11_detailed.md

Case 12: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver crashed with a synchronous external abort (hardware access fault) at PC offset 0xc4 in qcom_rng_read() when attempting to read from PRNG hardware register at address 0xffff800082c6d004 during the qcom_hwrng test. The fault indicates the PRNG hardware block is either not powered/clocked, not properly mapped, or in a bad state on the shikra-iqs-evk board. This is NOT caused by the PR under test (PCIe WAKE# support), which does not touch qcom_rng or PRNG subsystems.
3. Possible fix: This is a pre-existing kernel or board infrastructure issue, not a PR regression. Recommended actions: (1) Verify PRNG power/clock domain configuration in the shikra device tree; (2) Check if PRNG hardware is functional on this board revision; (3) Add error handling in qcom_rng driver to gracefully handle hardware access failures; (4) Re-run the test on a known-good shikra board to confirm hardware vs software issue. The PR can proceed to merge as it does not introduce this failure.
4. Detail analysis attachment: failed_case_job207673_12_detailed.md

Job 207674 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing probe failures unrelated to PR788: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource conflict, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED DT configuration, (3) regulatory.db firmware missing from rootfs (-ENOENT).
3. Possible fix: These are pre-existing platform issues not introduced by PR788 (which only adds PCIe WAKE# GPIO support). Mark test as false positive for this PR. To fix the underlying issues: (1) investigate qseecom TZ resource allocation, (2) correct the multi-LED "reg" property in hamoa-evk device tree, (3) add regulatory.db firmware to rootfs image.
4. Detail analysis attachment: failed_case_job207674_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Six critical hardware masters (five USB controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800, and one video codec at aa00000) are missing IOMMU group attachments on the hamoa-evk platform, indicating incomplete device tree IOMMU bindings for these components.
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/hamoa*.dtsi to bind them to the appropriate SMMU context banks.
4. Detail analysis attachment: failed_case_job207674_2_detailed.md

Case 3: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath12k WiFi7 PCI driver QMI DMA allocation failure (7274496 bytes, type 1) during device probe on hamoa-evk; the PR introduces PCI WAKE# IRQ registration in pci_device_add() which may interfere with early DMA setup or resource allocation timing for the WiFi PCIe endpoint.
3. Possible fix: Revert the PCI WAKE# changes from this PR and retest; if the issue persists, investigate whether the ath12k driver's QMI DMA allocation size (7MB) exceeds platform DMA constraints or whether the PCI core changes affect DMA mask setup or IOMMU domain attachment timing for PCIe devices on hamoa.
4. Detail analysis attachment: failed_case_job207674_3_detailed.md

Case 4: WiFi_OnOff — Test Framework False Positive (DMA allocation warning misinterpreted as failure)

1. Failed case: WiFi_OnOff — Test Framework False Positive (DMA allocation warning misinterpreted as failure)
2. Root cause: The ath12k_wifi7 WiFi driver encountered a transient DMA allocation failure (7274496 bytes) during QMI initialization at boot, logged the warning "qmi dma allocation failed (7274496 B type 1), will try later with small size", then successfully recovered by retrying with a smaller allocation. The driver completed probe successfully (chip_id 0x2, fw_version 0x1103006c detected, wlP4p1s0 interface created). The WiFi_OnOff test framework uses a simplistic grep pattern to detect "probe/runtime failures" in the kernel log and incorrectly flagged this recoverable warning as a test failure without verifying the driver's final operational state.
3. Possible fix: This is a test framework false positive, not a kernel regression. The WiFi driver is functioning correctly. The test should be updated to check the driver's final probe status (e.g., verify interface creation, chip_id detection) rather than failing on any warning message containing "failed". No kernel fix is required. If the DMA allocation pressure is a concern on hamoa-evk, investigate CMA/DMA heap sizing in the device tree, but the current driver behavior (retry with smaller size) is correct and robust.
4. Detail analysis attachment: failed_case_job207674_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: Exclude KVM tests from the Hamoa platform test suite, as nested virtualization (KVM under Gunyah) is not supported on this hardware configuration. Update the LAVA job definition to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when machine='Qualcomm Technologies, Inc. Hamoa IoT EVK'.
4. Detail analysis attachment: failed_case_job207674_5_detailed.md

Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression. To enable KVM on hamoa-evk: (1) Update bootloader/firmware to boot kernel into EL2, or (2) Configure a hypervisor stub that allows EL1 kernel to access EL2 features, or (3) Mark KVM tests as expected-fail for hamoa-evk in CI configuration until firmware is updated.
4. Detail analysis attachment: failed_case_job207674_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on hamoa-evk because the Gunyah hypervisor is already running at EL2 (Hypervisor mode), and ARM architecture permits only one hypervisor at EL2 at a time. Kernel message "kvm [1]: HYP mode not available" confirms EL2 is unavailable to KVM.
3. Possible fix: This is a platform configuration issue, not a PR regression. To enable KVM testing on hamoa-evk: (1) disable Gunyah hypervisor in the boot firmware/device tree, or (2) use nested virtualization if Gunyah supports it, or (3) exclude KVM tests from hamoa-evk CI runs and test KVM on platforms without Gunyah (e.g., standard QEMU or bare-metal ARM boards).
4. Detail analysis attachment: failed_case_job207674_7_detailed.md

Case 8: 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: Update the LAVA test suite configuration to skip KVM tests on platforms where Gunyah hypervisor is enabled, or disable Gunyah in the firmware if KVM testing is required. This is a test environment configuration issue, not a kernel bug. The PR (GPIO and PCIe WAKE# support) is unrelated to this failure.
4. Detail analysis attachment: failed_case_job207674_8_detailed.md

Job 207675 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: ath11k_pci WiFi driver probe failed with -ETIMEDOUT (-110) on monaco-evk because the WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to fail during PCIe device initialization.
3. Possible fix: Add the missing WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). The firmware package for ath11k WCN6855 must be installed in the build or the firmware files must be manually copied to the target.
4. Detail analysis attachment: failed_case_job207675_1_detailed.md

Case 2: WiFi Driver Probe Failure — Missing Firmware Dependency

1. Failed case: WiFi Driver Probe Failure — Missing Firmware Dependency
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (Direct firmware load for ath11k/WCN6855/hw2.1/nfa765/amss.bin failed with error -2 = -ENOENT). The MHI bus failed to load the firmware, causing the power-up sequence to timeout, which cascaded into probe failure.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs build at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin. This is a build/packaging issue in the qcom-multimedia-image-iq-8275-evk rootfs, not a kernel regression introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788 (which only adds PCI wake GPIO support and does not touch WiFi driver or firmware paths).
4. Detail analysis attachment: failed_case_job207675_2_detailed.md

Case 3: WiFi_OnOff — ath11k_pci probe failure (driver initialization failure)

1. Failed case: WiFi_OnOff — ath11k_pci probe failure (driver initialization failure)
2. Root cause: WiFi driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to time out waiting for firmware load completion.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). This is a build/image configuration issue, not a kernel regression introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788.
4. Detail analysis attachment: failed_case_job207675_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure issue — test runner completed successfully (<LAVA_TEST_RUNNER EXIT> and "lava_test_shell seems to have completed" logged), but LAVA dispatcher incorrectly marked the test definition as "unfinished" and failed it despite all individual test cases completing execution.
3. Possible fix: Re-trigger the LAVA job. This is a known LAVA dispatcher race condition where the test completion signal is not properly synchronized with the test result aggregation logic. If the issue persists, investigate LAVA dispatcher logs for test result collection timing issues and consider increasing the lava-test-shell completion timeout.
4. Detail analysis attachment: failed_case_job207675_4_detailed.md

Job 207676 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing firmware load failures unrelated to PR788 changes: (1) cfg80211 regulatory database firmware file (regulatory.db) missing from rootfs (error -2 = -ENOENT), and (2) Renesas xHCI USB controller firmware file (renesas_usb_fw.mem) missing from rootfs (error -2 = -ENOENT). Both are infrastructure/rootfs packaging issues, not kernel regressions. The PR788 changes (PCIe WAKE# GPIO support) introduce no new probe failures and produce no error messages in the log.
3. Possible fix: Add the missing firmware files to the root filesystem image: (1) regulatory.db (from linux-firmware package, typically in /lib/firmware/) for cfg80211 wireless regulatory support, and (2) renesas_usb_fw.mem (from linux-firmware package) for the Renesas xHCI USB controller on the PCIe bus at 0001:04:00.0. These are rootfs packaging issues, not kernel bugs. The Probe_Failure_Check test should be updated to suppress known benign firmware load failures for optional hardware (regulatory.db is non-critical; Renesas USB controller is an add-on PCIe device not required for core platform functionality on qcs6490-rb3gen2).
4. Detail analysis attachment: failed_case_job207676_1_detailed.md

Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Renesas xHCI USB host controller (PCIe device 0001:04:00.0) failed to probe due to missing firmware file renesas_usb_fw.mem in /lib/firmware (error -ENOENT). This is a pre-existing infrastructure/image configuration issue, not introduced by PR FROMLIST: PCI: Add support for PCIe WAKE# interrupt #788 (which adds PCIe WAKE# GPIO support and does not modify USB, xHCI, or Renesas driver code).
3. Possible fix: Add the Renesas USB firmware package to the rootfs image build configuration. The firmware file renesas_usb_fw.mem must be present in /lib/firmware/ for the xhci-pci-renesas driver to successfully probe the USB host controller on this board.
4. Detail analysis attachment: failed_case_job207676_2_detailed.md

Case 3: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test infrastructure limitation, not a kernel bug. The PR introduces PCIe WAKE# GPIO support and has no Bluetooth code changes. Recommended actions: (1) Suppress BT_SCAN failures in CI when BT_ON_OFF passes, as this indicates functional Bluetooth hardware/firmware with no nearby devices; (2) Add a known Bluetooth beacon device to the LAVA lab environment for rb3gen2 boards to ensure consistent scan results; (3) Merge the PR — this failure is unrelated to the changes and does not indicate a regression.
4. Detail analysis attachment: failed_case_job207676_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the kernel is running as a guest under the Gunyah hypervisor (EL1), not on bare metal (EL2). KVM requires direct access to ARM EL2 (Hypervisor mode) to function, but EL2 is occupied by Gunyah. The kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is not accessible to the kernel.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression (the PR only modifies GPIO and PCIe WAKE# support). To enable KVM testing on qcs6490-rb3gen2, either: (1) boot the kernel on bare metal without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-based platforms, or (3) implement nested virtualization support in Gunyah (requires hypervisor changes, not kernel changes).
4. Detail analysis attachment: failed_case_job207676_4_detailed.md

Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM requires ARM EL2 (hypervisor mode) to create /dev/kvm, but qcs6490-rb3gen2 boots in EL1 (kernel mode) — kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is not available on this platform.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression. To enable KVM on qcs6490-rb3gen2: (1) verify bootloader/firmware supports EL2 entry, (2) ensure secure firmware (TZ/ATF) does not trap EL2, (3) if EL2 is unavailable by design on this SoC/board, exclude KVM tests from the CI test suite for this target.
4. Detail analysis attachment: failed_case_job207676_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add platform detection logic to the KVM test suite to skip KVM tests when running under a hypervisor (check for Gunyah/hypervisor boot signatures in dmesg or /sys/hypervisor/type). Alternatively, configure the qcs6490-rb3gen2 LAVA job to boot bare-metal (without Gunyah) if KVM testing is required, or mark KVM tests as expected-fail for Gunyah-based configurations.
4. Detail analysis attachment: failed_case_job207676_6_detailed.md

Case 7: 0_qcom-next-ci-premerge-tests (KVM test failures: KVM_Driver, KVM_EL2_DTB, KVM_Infra)

1. Failed case: 0_qcom-next-ci-premerge-tests (KVM test failures: KVM_Driver, KVM_EL2_DTB, KVM_Infra)
2. Root cause: Platform does not support KVM virtualization — kernel reports "HYP mode not available" at boot (line 2239: [ 3.469613][ T1] kvm [1]: HYP mode not available), preventing /dev/kvm device creation. CONFIG_KVM is enabled in kernel config, but the qcs6490-rb3gen2 hardware/firmware does not provide EL2 (hypervisor) support required for KVM operation.
3. Possible fix: This is not a PR-introduced regression (PR only modifies GPIO/PCIe WAKE# code). Either: (1) Skip KVM tests on qcs6490-rb3gen2 in the CI test plan since this platform lacks virtualization support, or (2) Run KVM tests only on platforms with confirmed EL2/HYP mode support (e.g., platforms that boot with hypervisor enabled).
4. Detail analysis attachment: failed_case_job207676_7_detailed.md