Skip to content

Enable IPCB for multiple QCOM platforms#602

Open
jiegan0107 wants to merge 5 commits into
qualcomm-linux:qcom-6.18.yfrom
jiegan0107:qcom-6.18.y
Open

Enable IPCB for multiple QCOM platforms#602
jiegan0107 wants to merge 5 commits into
qualcomm-linux:qcom-6.18.yfrom
jiegan0107:qcom-6.18.y

Conversation

@jiegan0107
Copy link
Copy Markdown

@jiegan0107 jiegan0107 commented May 19, 2026

Enable IPCB for Hamoa/Pakala/KNP/Glymur.
Enable ETE for Glymur

CRs-Fixed: 4542084

@jiegan0107 jiegan0107 requested review from a team, jingyiwang42, ndechesne and yijiyang May 19, 2026 14:01
@qswat-orbit-external
Copy link
Copy Markdown

qswat-orbit-external Bot commented May 19, 2026

Merge Check Failed: CR Not Eligible for Merge

CR 4542084 is not eligible for merge.

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

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

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

jiegan0107 added 5 commits May 20, 2026 09:24
@jiegan0107
PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso
1e1c58f 
Add TGU devices for supporting IPCB feature in staging dtso file and add
ETR devices for supporting DDR memory trace.

Signed-off-by: Jie Gan <[email protected]>
@jiegan0107
PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS deb…
a49642b 
…ug block

Add the following devices that are part of the APSS debug block to
enable debug features, including ETM, replicator, funnel, and
TMC ETF.

Signed-off-by: Jie Gan <[email protected]>
@jiegan0107
PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso
2384adb 
Add TGU devices for supporting IPCB feature in staging dtso file.

Signed-off-by: Jie Gan <[email protected]>
@jiegan0107
PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso
48a2fde 
Add TGU devices for supporting IPCB feature in staging dtso file.

Signed-off-by: Jie Gan <[email protected]>
@jiegan0107
PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso
02eeba0 
Add TGU devices for supporting IPCB feature in staging dtso file.

Signed-off-by: Jie Gan <[email protected]>
@knaveen-qc
Copy link
Copy Markdown

knaveen-qc commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
⚠️ 0 Full report

Final Summary

  1. Lore link present: Not provided in agent output
  2. Lore link matches PR commits: Not provided in agent output
  3. Upstream patch status: Not provided in agent output
  4. PR present in qcom-next: Not provided in agent output
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: qualcomm-linux/kernel #602 — arm64: dts: qcom: add TGU/ETR/Coresight staging overlays (glymur, hamoa, sm8750, kaanapali)
Upstream commit: N/A — all 5 commits carry PENDING: prefix; no lore.kernel.org link present or expected
Verdict: ⚠️ PARTIAL (N/A for lore validation; vendor-staging commits assessed on commit-message hygiene only)

Commit 1 of 5 — PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Brief but adequate: mentions IPCB and DDR memory trace
Fixes tag present/correct N/A New feature, no bug fix
Authorship preserved ✅ Single author; Signed-off-by matches From:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds glymur-staging.dtbo entry correctly
arch/arm64/boot/dts/qcom/glymur-staging.dtso ✅ New file; TGU + ETR + replicator + CTCU nodes look self-consistent

Issues

  • None for commit-message or diff correctness.

Verdict

Acceptable as a vendor-staging commit; no lore link required for PENDING: prefix.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only staging change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

Commit 2 of 5 — PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Lists device types added (ETM, replicator, funnel, TMC ETF)
Fixes tag present/correct N/A New feature
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/glymur-staging.dtso ✅ Large addition (1248 lines); 18 ETEs, 3 NCC clusters, funnels, replicators, TMC ETFs — topology appears internally consistent

Issues

  • None for commit-message or diff correctness.

Verdict

Acceptable as a vendor-staging commit; no lore link required for PENDING: prefix.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only staging change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

Commit 3 of 5 — PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Mentions IPCB feature
Fixes tag present/correct N/A New feature
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds hamoa-staging.dtbo entry correctly
arch/arm64/boot/dts/qcom/hamoa-staging.dtso ✅ New file; 3 TGU nodes at 0x10b0e000–0x10b10000, consistent structure

Issues

  • None for commit-message or diff correctness.

Verdict

Acceptable as a vendor-staging commit; no lore link required for PENDING: prefix.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only staging change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

Commit 4 of 5 — PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Mentions IPCB feature
Fixes tag present/correct N/A New feature
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds sm8750-staging.dtbo entry correctly
arch/arm64/boot/dts/qcom/sm8750-staging.dtso ⚠️ New file; 3 TGU nodes at 0x10b0e000–0x10b10000 — identical addresses to hamoa-staging.dtso (commit 3); may be intentional if both boards share the same SoC TGU layout, but worth confirming

Issues

  • ⚠️ sm8750-staging.dtso and hamoa-staging.dtso define TGU nodes at the exact same physical addresses (0x10b0e000, 0x10b0f000, 0x10b10000). If hamoa and sm8750 are different SoCs this is suspicious and should be verified against the respective TRM/hardware spec.

Verdict

Acceptable as a vendor-staging commit pending address-range confirmation; no lore link required for PENDING: prefix.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only staging change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

Commit 5 of 5 — PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Mentions IPCB feature
Fixes tag present/correct N/A New feature
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds kaanapali-staging.dtbo entry correctly
arch/arm64/boot/dts/qcom/kaanapali-staging.dtso ✅ New file; 4 TGU nodes at distinct addresses (0x11301000, 0x1130e000–0x11310000), consistent structure

Issues

  • None for commit-message or diff correctness.

Verdict

Acceptable as a vendor-staging commit; no lore link required for PENDING: prefix.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only staging change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

Overall PR Summary

PR #602 contains 5 commits, all prefixed PENDING:. Lore validation is not applicable by design for this prefix. Commit-message hygiene is clean across all 5 commits. One minor concern is flagged on commit 4 (sm8750 TGU addresses identical to hamoa), which should be verified against hardware documentation before merging.

Commit Prefix Lore Link Verdict
glymur: add TGU and ETR in staging dtso PENDING: None (expected) ✅ N/A
glymur: add Coresight devices for APSS debug block PENDING: None (expected) ✅ N/A
hamoa: add TGU in staging dtso PENDING: None (expected) ✅ N/A
sm8750: add TGU in staging dtso PENDING: None (expected) ⚠️ Address overlap with hamoa
kaanapali: add TGU in staging dtso PENDING: None (expected) ✅ N/A

@knaveen-qc
Copy link
Copy Markdown

knaveen-qc commented May 20, 2026

PR #602 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ All 5 commits clean — 0 errors, 0 warnings, 0 checks
dt-binding-check ⏭️ No changes in Documentation/devicetree/bindings — skipped
dtb-check ✅ Log Summary: Test passed — no new DTB errors introduced by PR
sparse-check ⏭️ No C/H file changes — skipped
check-uapi-headers ⏭️ No relevant file changes — skipped
check-patch-compliance ❌ All 5 commits fail: PENDING: is not an allowed prefix
tag-check ✅ All 5 commits carry PENDING: — valid tag-check prefix
qcom-next-check N/A PR targets qcom-6.18.y, not qcom-next

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #602 — arm64: dts: qcom: add TGU/ETR/Coresight staging dtso nodes
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/26135626742
Target branch: qcom-6.18.y (not qcom-next / qcom-next-staging)
Head SHA: 02eeba05fc7c3ced8283ae82c9beed288d1a8c84
Base SHA: 0136c1ed9c23851783df4ad39ad3556497cc3c2a

Checker Result Summary
checkpatch ✅ All 5 commits clean — 0 errors, 0 warnings, 0 checks
dt-binding-check ⏭️ No changes in Documentation/devicetree/bindings — skipped
dtb-check ✅ Log Summary: Test passed — no new DTB errors introduced by PR
sparse-check ⏭️ No C/H file changes — skipped
check-uapi-headers ⏭️ No relevant file changes — skipped
check-patch-compliance ❌ All 5 commits fail: PENDING: is not an allowed prefix
tag-check ✅ All 5 commits carry PENDING: — valid tag-check prefix
qcom-next-check N/A PR targets qcom-6.18.y, not qcom-next

❌ check-patch-compliance

Root cause: All 5 commits use the PENDING: subject prefix, which is not in the check-patch-compliance allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso
Commit summary does not start with a required prefix

##[error]Process completed with exit code 1.

Root cause analysis:
PENDING: is a known vendor-internal prefix that check-patch-compliance does not accept. This checker expects patches to have an upstream lore.kernel.org Link: tag and a prefix indicating upstream disposition (FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:). PENDING: patches by definition have no upstream link yet, so this checker will always fail for them — this is a known checker limitation for vendor-only / not-yet-posted patches.

Fix options:

Scenario Action
Patches have been posted to lore.kernel.org Change prefix to FROMLIST: and add Link: <lore-url> to each commit body
Patches are not yet posted upstream Keep PENDING: — check-patch-compliance failure is expected and accepted for this prefix; no patch change needed

If the patches are genuinely not yet posted upstream, this failure is a known false-positive for PENDING: commits and can be waived. If they have been posted, update the prefix and add the Link: tag:

git rebase -i 0136c1ed9c23   # mark each commit as 'edit'
# For each commit:
git commit --amend  # change PENDING: → FROMLIST: and add Link: <lore-url>
git rebase --continue

Reproduce locally:

bash kernel-checkers/check-patch-compliance.sh \
  --kernel-src <path/to/kernel> \
  --base 0136c1ed9c23851783df4ad39ad3556497cc3c2a \
  --head 02eeba05fc7c3ced8283ae82c9beed288d1a8c84

ℹ️ dtb-check — PASS with pre-existing warnings (informational)

The dtb-check log contains many reg_format warnings in hamoa-camera.dtsi and talos-evk-lvds-auo,g133han01.dtso, but these are pre-existing tree-wide issues not introduced by this PR. The checker's base-vs-head diff found no new errors and reported "Log Summary: Test passed". No action required.

Verdict

1 blocker: check-patch-compliance fails on all 5 commits due to PENDING: prefix.

  • If these patches are not yet posted upstream → this is a known limitation; the failure can be waived and the PR is otherwise ready to merge (checkpatch ✅, dtb-check ✅, tag-check ✅).
  • If these patches have been posted to lore → update each commit to FROMLIST: + add Link: <lore-url> before merging.

@qcomlnxci
Copy link
Copy Markdown

qcomlnxci commented May 20, 2026

Test jobs on 02eeba0

@qcomlnxci
Copy link
Copy Markdown

qcomlnxci commented May 20, 2026

Test Matrix

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

@knaveen-qc
Copy link
Copy Markdown

knaveen-qc commented May 20, 2026

LAVA Failed Case Triage Summary

PR: #602

Job 103202 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Two pre-existing driver probe/firmware errors on qcs8300-ride-sx triggered the Probe_Failure_Check scanner: (1) Aquantia AQR115C stmmac-0:08: failed to read firmware-name: -22 — the qcs8300-ride PHY DT node at MDIO address 0x08 is missing the mandatory firmware-name property required by the Aquantia AQR115C driver, causing a hard -EINVAL probe failure; (2) faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2 — the regulatory.db file is absent from the rootfs, causing cfg80211 to fail its firmware load. Neither failure is introduced by PR Enable IPCB for multiple QCOM platforms #602, which only modifies staging DT overlays for glymur/hamoa/sm8750/kaanapali platforms.
  3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs8300-ride DTS/DTSO, and ensure regulatory.db is included in the qcs8300-ride-sx rootfs image (or add both signatures to the Probe_Failure_Check allowlist if they are known-benign for this board configuration).
  4. Detail analysis attachment: failed_case_job103202_1_detailed.md
  Case 2: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** No physical USB peripheral device is connected to the qcs8300-ride board's USB host port in the LAVA lab; lsusb enumeration returns only the Linux Foundation 2.0 root hub (ID 1d6b:0002), which is the xHCI controller's own virtual hub — the test script correctly identifies this as "Only USB hubs detected, no functional USB devices" and fails.
  3. Possible fix: Attach a functional USB peripheral (e.g., USB storage or HID device) to the qcs8300-ride board's USB host port in the LAVA lab infrastructure, or mark USBHost as a known infra-dependent test and skip it when no USB device is physically present on this board.
  4. Detail analysis attachment: failed_case_job103202_2_detailed.md
  Case 3: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
  1. Failed case: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
  2. Root cause: ** The shmbridge test script greps the current-boot kernel log for any string matching qcom_scm and flags a failure if any match is found; the kernel command line itself contains qcom_scm.download_mode=1, which is always present on qcs8300-ride-sx and unconditionally triggers the test's error-detection heuristic — this is a known false-positive in the CI environment unrelated to any kernel regression.
  3. Possible fix: No action required — suppress this result per Rule 1 of lava-known-benign-failures.md; the shmbridge test is known CI infrastructure noise and does not indicate a kernel defect on qcs8300-ride or any other platform.
  4. Detail analysis attachment: failed_case_job103202_3_detailed.md
  Case 4: ** `0_qcom-next-ci-premerge-tests` — Suppressed (Known Benign: shmbridge CI noise)
  1. Failed case: ** 0_qcom-next-ci-premerge-tests — Suppressed (Known Benign: shmbridge CI noise)
  2. Root cause: ** The LAVA dispatcher marked the overall test definition as failed ("Marking unfinished test run as failed") because result_parse.sh found shmbridge.res containing a FAIL result; the shmbridge test itself failed because its run.sh matched the kernel command line string qcom_scm.download_mode=1 as a qcom_scm-related error in the boot log — a known false-positive pattern on qcs8300-ride that is always suppressed per Rule 1 of the known-benign failure policy.
  3. Possible fix: No action required on the PR; suppress the shmbridge failure per Rule 1 (always suppress). If the shmbridge test script is accessible, fix its qcom_scm error-scan regex to exclude the kernel command line string (qcom_scm.download_mode=) from its error pattern match to prevent future false positives.
  4. Detail analysis attachment: failed_case_job103202_4_detailed.md
Job 103203 | SoC qcs6490-rb3gen2

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Two pre-existing firmware-load failures in dmesg triggered the check: regulatory.db (ENOENT, cfg80211 regulatory database absent from CI rootfs) and renesas_usb_fw.mem (ENOENT, Renesas USB PCIe controller firmware absent from CI rootfs), both unrelated to the PR's DTS-only changes targeting glymur/hamoa/sm8750/kaanapali platforms.
  3. Possible fix: Add regulatory.db (from wireless-regdb) and renesas_usb_fw.mem (from linux-firmware) to the CI rootfs image used for qcs6490-rb3gen2 LAVA jobs, or add suppression rules for these two known-benign firmware-absent probe failures in the Probe_Failure_Check test script.
  4. Detail analysis attachment: failed_case_job103203_1_detailed.md
  Case 2: ** Driver Probe Failure — xhci-pci-renesas firmware missing
  1. Failed case: ** Driver Probe Failure — xhci-pci-renesas firmware missing
  2. Root cause: ** The Renesas USB 3.0 xHCI PCIe host controller (PCI ID 1912:0014, slot 0001:04:00.0) present on the qcs6490-rb3gen2 board failed to probe because the required firmware file renesas_usb_fw.mem is absent from the rootfs image (-ENOENT, errno -2), leaving no functional USB host controller and causing the USBHost test to report "No USB devices found."
  3. Possible fix: Add the Renesas xHCI firmware file (renesas_usb_fw.mem) to the rootfs image used for qcs6490-rb3gen2 CI runs (typically under /lib/firmware/), or suppress the xhci-pci-renesas driver probe on this board if the Renesas PCIe USB card is not a required test peripheral, by adding a kernel config or DT quirk to skip it.
  4. Detail analysis attachment: failed_case_job103203_2_detailed.md
  Case 3: ** shmbridge — Suppressed (Known Benign: CI Infrastructure Noise)
  1. Failed case: ** shmbridge — Suppressed (Known Benign: CI Infrastructure Noise)
  2. Root cause: ** The shmbridge test script performs a broad grep for any qcom_scm-related string in the current-boot kernel log and flags the pre-existing informational message qcom_scm firmware:scm: qseecom: untested machine, skipping as an error; this is a known false-positive in the CI environment on qcs6490-rb3gen2 and does not indicate any kernel regression.
  3. Possible fix: No action required — suppress this result per Rule 1 of lava-known-benign-failures.md; the shmbridge test is known CI noise and must not be treated as a PR-introduced failure.
  4. Detail analysis attachment: failed_case_job103203_3_detailed.md
  Case 4: ** `0_qcom-next-ci-premerge-tests`
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** Three sub-tests within the qcom-next-ci-premerge-tests suite reported RESULT=FAIL on the qcs6490-rb3gen2 board: (1) Probe_Failure_Check — triggered by two benign kernel probe errors (faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2 and xhci-pci-renesas 0001:04:00.0: probe with driver xhci-pci-renesas failed with error -2); (2) shmbridge — triggered by the qcom_scm firmware:scm: qseecom: untested machine, skipping message being matched as a qcom_scm-related error in the kernel log; (3) USBHost — no USB devices found on the board. These failures caused LAVA to mark the overall test run as failed ("Marking unfinished test run as failed") because the test runner exited with sub-test failures outstanding. The PR itself (5 patches adding DTS overlays for glymur/hamoa/sm8750/kaanapali staging — TGU/ETR/Coresight nodes) does not touch qcs6490, qcom_scm, USB host, or regulatory firmware paths, so these failures are pre-existing and PR-unrelated.
  3. Possible fix: These are pre-existing, board-environment failures unrelated to the PR; add Probe_Failure_Check, shmbridge, and USBHost to the known-benign suppression list for qcs6490-rb3gen2 in the CI test runner configuration, or re-trigger the job to confirm reproducibility before blocking the PR.
  4. Detail analysis attachment: failed_case_job103203_4_detailed.md
Job 103204 | SoC lemans-evk

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** The test scanner found 3 Direct firmware load ... failed with error -2 dmesg entries (Bluetooth qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv, and regulatory.db) and flagged them as probe failures; however, all three are known-benign false positives — BT_ON_OFF=PASS and WiFi_OnOff=PASS confirm both subsystems loaded their firmware and functioned correctly at runtime, and no deferred probes were outstanding.
  3. Possible fix: Suppress this Probe_Failure_Check result as a known-benign false positive per lava-known-benign-failures Rules 2 & 3; update the Probe_Failure_Check test script to cross-reference BT_ON_OFF and WiFi_OnOff functional test results before flagging firmware-load dmesg lines as failures, or add qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv, and regulatory.db to the test's firmware-load allowlist for lemans-evk (iq-9075-evk).
  4. Detail analysis attachment: failed_case_job103204_1_detailed.md
  Case 2: ** smmu
  1. Failed case: ** smmu
  2. Root cause: ** The smmu test script's critical-master IOMMU attachment check fails because two devices — aa00000.video-codec (Video codec) and interconnect-lpass-ag-noc (Audio LPASS interconnect) — are not attached to any IOMMU group on the lemans-evk (SA8775P/IQ-9075-EVK) board; no SMMU fault or kernel error is present, and the failure is pre-existing and unrelated to this PR's DTS changes (which only affect glymur/hamoa/sm8750/kaanapali platforms).
  3. Possible fix: Update the smmu test script's critical-master list to exclude aa00000.video-codec and interconnect-lpass-ag-noc for the lemans-evk platform (or mark them as non-critical/optional), as these devices are known to not have IOMMU group attachments on SA8775P; alternatively, add the missing iommus property to the aa00000.video-codec and interconnect-lpass-ag-noc DT nodes in the SA8775P/lemans DTS if IOMMU protection is required.
  4. Detail analysis attachment: failed_case_job103204_2_detailed.md
  Case 3: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** The USBHost test script requires at least one non-hub USB peripheral to be physically connected to the lemans-evk board's USB host port; at test time only two Genesys Logic hubs (ID 05e3:0610 USB 2.0, ID 05e3:0625 USB 3.1) were enumerated on buses 1 and 2, with no functional USB device present — the xhci-hcd controller and hub chain are fully operational.
  3. Possible fix: Attach a functional USB peripheral device (e.g. USB mass-storage stick or USB-to-serial adapter) to the lemans-evk board's USB host port in the LAVA lab setup so the USBHost test can detect a non-hub device; this is a lab infrastructure gap unrelated to the PR under test.
  4. Detail analysis attachment: failed_case_job103204_3_detailed.md
  Case 4: ** suppressed (known benign: shmbridge)
  1. Failed case: ** suppressed (known benign: shmbridge)
  2. Root cause: ** The shmbridge test script scanned the kernel log for any string matching qcom_scm and incorrectly flagged the benign boot-time message qcom_scm firmware:scm: qseecom: untested machine, skipping (and/or the kernel command-line parameter qcom_scm.download_mode=1) as a "qcom_scm-related error", triggering a false FAIL; per Rule 1 of the known-benign-failure suppressions, all shmbridge failures are unconditionally suppressed as CI infrastructure noise.
  3. Possible fix: No action required — suppress this result per Rule 1; the shmbridge test is a known false-positive in this CI environment and does not indicate any kernel regression introduced by PR Enable IPCB for multiple QCOM platforms #602.
  4. Detail analysis attachment: failed_case_job103204_4_detailed.md
  Case 5: ** WiFi_Firmware_Driver — Suppressed (Known Benign: WiFi Firmware False Positive — WiFi ON/OFF Passed)
  1. Failed case: ** WiFi_Firmware_Driver — Suppressed (Known Benign: WiFi Firmware False Positive — WiFi ON/OFF Passed)
  2. Root cause: ** The WiFi_Firmware_Driver test probed ath12k module load state before the driver had fully initialised on the lemans-evk (IQ-9075) board; the paired functional test WiFi_OnOff passed, confirming WiFi firmware loaded and operated correctly at runtime — this is a known false positive per suppression Rule 2.
  3. Possible fix: No fix required; suppress this result per the known-benign Rule 2 policy. If the test harness is generating noise, update the WiFi_Firmware_Driver test script to wait for driver initialisation to complete before checking module load state.
  4. Detail analysis attachment: failed_case_job103204_5_detailed.md
  Case 6: ** `0_qcom-next-ci-premerge-tests`
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** The LAVA dispatcher marked the overall test action as failed ("Marking unfinished test run as failed") because the test runner exited with genuine sub-test failures: smmu (two critical masters — aa00000.video-codec and interconnect-lpass-ag-noc — missing IOMMU group attachment on lemans-evk/sa8795p), USBHost (only USB hubs detected, no functional USB devices), and Probe_Failure_Check (BT firmware files qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv failed to load with error -2); all three are pre-existing platform issues on this board unrelated to the PR (which only modifies DTS for glymur, hamoa, sm8750, and kaanapali targets).
  3. Possible fix: Re-trigger the CI job to confirm reproducibility; the three genuine sub-failures (smmu, USBHost, Probe_Failure_Check) are pre-existing on lemans-evk and should be baselined or suppressed in the test plan — specifically, add aa00000.video-codec and interconnect-lpass-ag-noc to the SMMU test's known-missing-iommu allowlist, investigate USB hub-only topology on this board, and add BT firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) to the rootfs or suppress the Probe_Failure_Check entries for known-missing firmware.
  4. Detail analysis attachment: failed_case_job103204_6_detailed.md
Job 103205 | SoC qcs9100-ride

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

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

  Case 1: ** cdsp_remoteproc — Remoteproc Boot Failure (PAS/SCM authentication error)
  1. Failed case: ** cdsp_remoteproc — Remoteproc Boot Failure (PAS/SCM authentication error)
  2. Root cause: ** On qcs9100-ride (sa8775p "Lemans Ride Rev3"), qcom_scm logs qseecom: untested machine, skipping at boot (line 1399), leaving the PAS SCM interface uninitialized; every subsequent qcom_q6v5_pas call to qcom_scm_pas_init_image() returns -EINVAL (-22), preventing cdsp0 and cdsp1 from booting (state remains offline).
  3. Possible fix: Add qcs9100 (sa8775p) to the qseecom tested-machine list in the qcom_scm driver (or ensure the correct SCM/PAS path is used for this SoC) so that pas_init_image succeeds and the CDSP subsystems can boot; this failure is pre-existing and not introduced by this PR.
  4. Detail analysis attachment: failed_case_job103205_1_detailed.md
  Case 2: ** Remoteproc Boot Failure — PAS/SCM Authentication Error
  1. Failed case: ** Remoteproc Boot Failure — PAS/SCM Authentication Error
  2. Root cause: ** All five sa8775p DSP subsystems (adsp, cdsp0, cdsp1, gpdsp0, gpdsp1) fail to boot on qcs9100-ride because qcom_q6v5_pas returns error -22 (EINVAL) during PAS firmware initialization; the root cause is qcom_scm firmware:scm: qseecom: untested machine, skipping at boot, which disables the qseecom-based SCM PAS authentication path for this SoC, causing every subsequent qcom_scm_pas_init_image() call to return -EINVAL.
  3. Possible fix: Add sa8775p/qcs9100 to the qseecom machine allowlist in drivers/firmware/qcom/qcom_scm.c (or the equivalent qseecom init table) so that PAS authentication is enabled for this SoC; this failure is pre-existing and not introduced by this PR, so the PR can be merged independently while the SCM fix is tracked separately.
  4. Detail analysis attachment: failed_case_job103205_2_detailed.md
  Case 3: ** gpdsp_remoteproc — Remoteproc Boot Failure (PAS/SCM firmware init error -22)
  1. Failed case: ** gpdsp_remoteproc — Remoteproc Boot Failure (PAS/SCM firmware init error -22)
  2. Root cause: ** Both gpdsp0 (20c00000.remoteproc) and gpdsp1 (21c00000.remoteproc) fail to boot because qcom_q6v5_pas returns -22 (EINVAL) at the pas_init_image SCM call during firmware authentication/initialization of qcom/sa8775p/gpdsp0.mbn and gpdsp1.mbn; the SCM layer logs qseecom: untested machine, skipping for the qcs9100-ride SoC, indicating incomplete secure-side PAS support in this kernel build, and the same EINVAL pattern affects all DSPs (cdsp0, cdsp1, adsp) — this is a pre-existing platform issue not introduced by the PR.
  3. Possible fix: This failure is pre-existing and unrelated to the PR (which only adds Coresight/TGU DT overlays for glymur/hamoa/sm8750/kaanapali); no action required on the PR — the gpdsp boot failure on qcs9100-ride should be tracked separately as a platform bring-up issue requiring alignment of the kernel's qseecom/PAS machine-ID support with the sa8775p/qcs9100 secure firmware.
  4. Detail analysis attachment: failed_case_job103205_3_detailed.md
  Case 4: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error
  1. Failed case: ** Remoteproc Boot Failure — PAS/SCM firmware initialization error
  2. Root cause: ** All five sa8775p remoteproc subsystems (gpdsp0, gpdsp1, cdsp0, cdsp1, adsp) fail to boot because qcom_q6v5_pas returns error -22 (EINVAL) from pas_init_image; the SCM driver logs qcom_scm firmware:scm: qseecom: untested machine, skipping at boot, indicating the qseecom/PAS authentication path is not initialized for this qcs9100/sa8775p SoC variant in the kernel under test, causing every PAS firmware-load SCM call to be rejected with EINVAL.
  3. Possible fix: This is a pre-existing platform issue unrelated to PR Enable IPCB for multiple QCOM platforms #602; add the qcs9100/sa8775p SoC to the qcom_scm qseecom tested-machine list (or ensure the correct SCM firmware-load path is selected for sa8775p in drivers/firmware/qcom/qcom_scm.c), then re-run the LAVA job to confirm all five remoteproc subsystems reach running state.
  4. Detail analysis attachment: failed_case_job103205_4_detailed.md
  Case 5: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Two pre-existing probe/firmware errors on qcs9100-ride-sx triggered the test: (1) regulatory.db firmware file absent from rootfs (faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2), and (2) Aquantia AQR115C PHY at MDIO address stmmac-0:08 fails probe because the DT node lacks a valid firmware-name property (Aquantia AQR115C stmmac-0:08: probe with driver Aquantia AQR115C failed with error -22). Neither failure is introduced by this PR.
  3. Possible fix: Add regulatory.db to the qcs9100-ride-sx rootfs firmware package, and add or correct the firmware-name DT property in the stmmac-0:08 PHY node in the qcs9100-ride-sx (sa8775p-ride) DT; both are pre-existing platform issues unrelated to this PR's DT overlay additions for glymur/hamoa/sm8750/kaanapali.
  4. Detail analysis attachment: failed_case_job103205_5_detailed.md
  Case 6: ** smmu
  1. Failed case: ** smmu
  2. Root cause: ** The smmu test script on qcs9100-ride detected two critical DMA masters — aa00000.video-codec (video codec) and interconnect-lpass-ag-noc (audio LPASS interconnect) — not attached to any IOMMU group; aa00000.video-codec failed firmware initialization (error -22) so its IOMMU attach never completed, and interconnect-lpass-ag-noc has no iommus property in the qcs9100 DT, causing the test's critical-master coverage check to fail.
  3. Possible fix: Verify whether aa00000.video-codec and interconnect-lpass-ag-noc are expected to be IOMMU-protected on qcs9100-ride; if so, fix the video-codec firmware path/PIL auth issue so the driver probes fully and attaches to its IOMMU group, and add the missing iommus property for interconnect-lpass-ag-noc in the qcs9100 DT — or update the smmu test's critical-master list to exclude masters that are intentionally unprotected on this platform.
  4. Detail analysis attachment: failed_case_job103205_6_detailed.md
  Case 7: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** The USBHost test script enumerated only the three USB root hubs (Bus 001–003, all 1d6b:xxxx Linux Foundation virtual devices) and found no external/peripheral USB device attached to the qcs9100-ride board's host port, causing the test to evaluate the result as FAIL with + true (no real device matched the expected condition).
  3. Possible fix: Verify that a physical USB peripheral (e.g. USB storage or HID device) is connected to the qcs9100-ride board's USB host port in the LAVA lab; if the board has no USB device wired in the test fixture, this is a lab infrastructure gap — file a lab infra ticket to attach a USB device to the board, or mark USBHost as expected-skip for boards without a connected USB peripheral.
  4. Detail analysis attachment: failed_case_job103205_7_detailed.md
  Case 8: shmbridge
  1. Failed case: shmbridge
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: No action required — this failure is suppressed as known CI noise; no kernel change or re-trigger is needed for this case.
  4. Detail analysis attachment: failed_case_job103205_8_detailed.md
  Case 9: ** 0_qcom-next-ci-premerge-tests
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** All five sa8775p DSP remoteprocs (gpdsp0, gpdsp1, cdsp0, cdsp1, adsp) failed to boot at kernel init with error -22 initializing firmware qcom/sa8775p/*.mbn, leaving 0/5 subsystems running and causing cascading failures in remoteproc, smmu, shmbridge, and Probe_Failure_Check sub-tests; LAVA then marked the parent test definition as failed via "Marking unfinished test run as failed".
  3. Possible fix: Re-trigger the CI job to confirm reproducibility; if the failure recurs, investigate the rootfs/firmware image deployed to the qcs9100-ride board — the qcom_q6v5_pas PIL driver is rejecting all DSP firmware blobs with -EINVAL, which indicates a firmware-image/kernel-version mismatch or a missing/corrupt .mbn file in the rootfs image (qcom-multimedia-image-qcs9100-ride-sx.rootfs.qcomflash.tar.gz). This failure is pre-existing and unrelated to PR Enable IPCB for multiple QCOM platforms #602.
  4. Detail analysis attachment: failed_case_job103205_9_detailed.md
Job 103206 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** The Probe_Failure_Check test failed because its probe_failures.log scanner matched two early-boot Bluetooth firmware load errors (Direct firmware load for qca/wcnhpbtfw21.tlv failed with error -2 and qca/hpbtfw21.tlv failed with error -2) that are a known false positive on monaco-evk: the QCA WCN Bluetooth driver attempts to load a vendor-specific firmware file (wcnhpbtfw21.tlv) at early boot before the firmware partition is accessible, falls back gracefully, and Bluetooth operates correctly — confirmed by BT_ON_OFF RESULT=PASS and BT_FW_KMD_Service RESULT=PASS later in the same job.
  3. Possible fix: Suppress these two BT firmware load error strings (qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv with error -2) in the Probe_Failure_Check test's dmesg filter for monaco-evk, as they are pre-existing benign early-boot fallback messages that do not indicate a functional regression; no kernel or PR change is required.
  4. Detail analysis attachment: failed_case_job103206_1_detailed.md
  Case 2: ** WiFi_OnOff
  1. Failed case: ** WiFi_OnOff
  2. Root cause: ** On monaco-evk, both PCIe controllers (1c00000.pci and 1c10000.pci) report Phy link never came up at boot, preventing ath11k_pci from enumerating the WCN6855 WiFi device over PCIe; additionally, no ath11k WiFi firmware is present in the deployed firmware image (initramfs-firmware-qcs8300-ride-image-qcom-armv8a.cpio.gz is a QCS8300/RB3Gen2 image, not monaco-evk), so even if PCIe were functional the driver could not load firmware.
  3. Possible fix: This is a pre-existing infrastructure/board configuration issue unrelated to the PR (which only adds Coresight/TGU DT overlays for glymur/hamoa/sm8750/kaanapali); verify the monaco-evk PCIe PHY bring-up (power/clock/reset sequencing in DT or board bring-up) and ensure the correct monaco-evk firmware image is deployed in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job103206_2_detailed.md
  Case 3: ** `0_qcom-next-ci-premerge-tests`
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** The LAVA test definition wrapper 0_qcom-next-ci-premerge-tests was marked failed by the LAVA dispatcher ("Marking unfinished test run as failed") because two genuine sub-tests failed: (1) WiFi_OnOff — the firmware ramdisk deployed is initramfs-firmware-qcs8300-ride-image (QCS8300/RB3Gen2 firmware) rather than a monaco-evk-specific firmware image, so no ath11k WiFi firmware blobs are present under /lib/firmware and no WiFi interface appears after retries (WiFi stack present, but no usable WiFi interface was found after retries); (2) Probe_Failure_Check — the test scans kernel logs for firmware-related errors and flags early-boot BT firmware load failures (bluetooth hci0: Direct firmware load for qca/wcnhpbtfw21.tlv failed with error -2) that are benign because BT is functionally operational (BT_ON_OFF and BT_FW_KMD_Service both PASSED). Neither failure is introduced by PR Enable IPCB for multiple QCOM platforms #602, which only adds staging DT overlays for unrelated platforms (glymur, hamoa, sm8750, kaanapali).
  3. Possible fix: Update the LAVA job definition for monaco-evk to use the correct monaco-specific firmware ramdisk image (not initramfs-firmware-qcs8300-ride-image) so that ath11k WiFi firmware blobs are present; additionally, add a suppression rule for Probe_Failure_Check failures caused solely by BT firmware load errors when BT_ON_OFF and BT_FW_KMD_Service pass.
  4. Detail analysis attachment: failed_case_job103206_3_detailed.md
Job 103207 | SoC x1e80100

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

Failed test cases in LAVA job 103207 (SoC: x1e80100).

  Case 1: ** Build Load Failure — Fastboot boot failure
  1. Failed case: ** Build Load Failure — Fastboot boot failure
  2. Root cause: ** Result: Build Load Failure. The fastboot boot command at stage 3.4 successfully transferred boot.img (234912 KB, OKAY in ~0.66s) to the x1e80100-CRD board but the device's UEFI/ABL firmware (BOOT.MXF.2.4-00541-HAMOA-1) rejected it at the boot-image load/authentication step with the error FAILED (remote: 'Failed to load/authenticate boot image: Load Error'), repeated identically across all 3 retry attempts — indicating the boot image format or header version is incompatible with what the x1e80100 ABL expects (the image was built with mkbootimg --header_version 2, while the x1e80100 UEFI-based boot flow may require a higher header version or a different image format).
  3. Possible fix: Verify that the mkbootimg invocation in the LAVA job definition uses the correct --header_version for the x1e80100-CRD board (the x1e80100 platform typically requires header version 3 or higher); update the boot image build step accordingly and re-trigger the CI job.
  4. Detail analysis attachment: failed_case_job103207_1_detailed.md
  Case 2: ** Build Load Failure — Fastboot boot image authentication failure
  1. Failed case: ** Build Load Failure — Fastboot boot image authentication failure
  2. Root cause: ** Result: Build Load Failure; at stage 3.4 boot-fastboot, the x1e80100-crd ABL (BOOT.MXF.2.4-00541-HAMOA-1) rejected the boot image on all 3 attempts with the remote error "Failed to load/authenticate boot image: Load Error" — the image transfer succeeded (234912 KB OKAY) but the bootloader's image validation/authentication step failed, likely due to a boot image header version or format mismatch (mkbootimg --header_version 2) incompatible with this ABL version.
  3. Possible fix: Re-trigger the CI job to rule out a transient ABL state; if the failure recurs, update the mkbootimg invocation in the LAVA postprocess script for x1e80100-crd to use the correct --header_version expected by ABL BOOT.MXF.2.4-00541-HAMOA-1 (check if v3/v4 is required), or update the ABL firmware on the board to a version compatible with header_version 2 images.
  4. Detail analysis attachment: failed_case_job103207_2_detailed.md
  Case 3: ** Build Load Failure — Fastboot boot failure
  1. Failed case: ** Build Load Failure — Fastboot boot failure
  2. Root cause: ** Result: Build Load Failure. The LAVA fastboot-boot action failed at the boot stage (not deploy/flash) on all 3 retry attempts because the x1e80100-crd board's ABL/secure-boot firmware rejected the boot.img with the remote error FAILED (remote: 'Failed to load/authenticate boot image: Load Error'), preventing the kernel from ever loading; the final job result carries error_type: Infrastructure.
  3. Possible fix: Re-trigger the CI job; if the failure recurs, verify that the boot.img artifact built from this PR is correctly signed/packaged for the x1e80100-crd secure-boot policy — check whether the signing key or image format expected by the board's ABL has changed, and confirm the boot image passes fastboot boot on a known-good baseline build.
  4. Detail analysis attachment: failed_case_job103207_3_detailed.md
Job 103208 | SoC qcs615-ride

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** The cfg80211 wireless regulatory driver fails to load regulatory.db firmware at boot (faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2, ENOENT) because the file is absent from /lib/firmware/ in the qcs615-ride test rootfs; the Probe_Failure_Check test catches this dmesg line and reports FAIL.
  3. Possible fix: Add regulatory.db to the test rootfs image used for qcs615-ride LAVA jobs (place it under /lib/firmware/regulatory.db), or suppress this known-benign firmware-absent message in the Probe_Failure_Check test script since cfg80211 gracefully falls back to compiled-in regulatory data and WiFi functionality is unaffected (WiFi_Firmware_Driver and WiFi_OnOff both PASS).
  4. Detail analysis attachment: failed_case_job103208_1_detailed.md
  Case 2: ** smmu
  1. Failed case: ** smmu
  2. Root cause: ** The SMMU test script on qcs615-ride asserts that video sub-devices aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder each appear as independently IOMMU-group-attached devices in sysfs, but on qcs615 the Venus video-codec driver registers these as virtual child devices that do not receive their own IOMMU group entries — only the parent aa00000.video-codec is attached to group 7 — causing two [FAIL] Critical master is missing iommu_group attachment assertions and a final WARN=0, FAIL=2 result.
  3. Possible fix: Update the SMMU test script to recognize that aa00000.video-codec (parent) being attached to an IOMMU group is sufficient for qcs615-ride, and exempt the virtual child sub-device names (video-decoder, video-encoder) from the per-device IOMMU group attachment check on this platform; alternatively add a platform-specific allowlist entry for qcs615 video-codec child devices.
  4. Detail analysis attachment: failed_case_job103208_2_detailed.md
  Case 3: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** The USBHost test failed because lsusb enumerated only the xHCI root hub (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub) with no functional USB peripheral attached; the xHCI controller at 0x0a800000 probed correctly with one USB 2.0 port but no external USB device was plugged into the qcs615-ride board's USB host port at test execution time.
  3. Possible fix: Verify that a USB peripheral device (e.g. USB mass-storage stick or HID device) is physically connected to the qcs615-ride board's USB host port in the LAVA lab setup before re-triggering the job; if the board has no accessible USB host port in this lab configuration, mark USBHost as a known infrastructure skip for qcs615-ride.
  4. Detail analysis attachment: failed_case_job103208_3_detailed.md
  Case 4: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
  1. Failed case: ** shmbridge — Suppressed (Known Benign: shmbridge CI noise)
  2. Root cause: ** The shmbridge test script incorrectly flags the benign kernel log message qcom_scm firmware:scm: qseecom: untested machine, skipping as a "qcom_scm-related error," triggering a false FAIL; this is a known CI infrastructure false positive on qcs615-ride and all other Qualcomm platforms, unconditionally suppressed per Rule 1 of the known-benign-failures policy.
  3. Possible fix: No action required — suppress this result per Rule 1 (shmbridge always-suppress); the failure is not PR-introduced and does not indicate any kernel regression.
  4. Detail analysis attachment: failed_case_job103208_4_detailed.md
  Case 5: ** `0_qcom-next-ci-premerge-tests`
  1. Failed case: ** 0_qcom-next-ci-premerge-tests
  2. Root cause: ** The LAVA test shell marked the overall 0_qcom-next-ci-premerge-tests definition as failed because sub-tests within the suite reported FAIL: shmbridge (false positive — test script matched the benign kernel cmdline string qcom_scm.download_mode=1 as a qcom_scm error), USBHost (no USB device attached to the qcs615-ride board in this LAVA setup), and Probe_Failure_Check (regulatory.db firmware load failure, a known benign infra issue); none of these failures are caused by the PR's DTS-only changes targeting glymur/hamoa/sm8750/kaanapali platforms.
  3. Possible fix: Suppress the known false-positive sub-test failures in the qcom-linux-testkit: fix the shmbridge test to exclude kernel cmdline matches from its qcom_scm error scan, mark USBHost as SKIP when no USB device is present on the board, and suppress the regulatory.db firmware load failure in Probe_Failure_Check; then re-trigger the CI job to confirm the PR is clean.
  4. Detail analysis attachment: failed_case_job103208_5_detailed.md

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
⚠️ 0 Full report

Final Summary

  1. Lore link present: No — all 5 commits carry PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — all commits are vendor-only (PENDING:), not posted upstream
  4. PR present in qcom-next: Not checked — canonical kernel repo unavailable locally and network access is restricted; verify manually
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: qualcomm-linux/kernel #602 — "arm64: dts: qcom: add TGU/ETR/Coresight staging overlays for glymur, hamoa, sm8750, kaanapali"
Upstream commit: N/A — all 5 commits carry the PENDING: prefix; no lore.kernel.org link expected or required.
Verdict: ⚠️ PARTIAL

Step 1 — Lore Link Check

All five commits use the PENDING: prefix. Per the validate-patch skill rules, PENDING: commits have no upstream lore link by design. Lore-link validation is not applicable for any commit in this PR. Steps 2–9 (lore fetch, diff comparison, upstream status) are skipped for all commits.

Commit-by-Commit Summary

# Subject Prefix Lore link?
1 arm64: dts: qcom: glymur: add TGU and ETR in staging dtso PENDING: None — expected
2 arm64: dts: qcom: glymur: add Coresight devices for APSS debug block PENDING: None — expected
3 arm64: dts: qcom: hamoa: add TGU in staging dtso PENDING: None — expected
4 arm64: dts: qcom: sm8750: add TGU in staging dtso PENDING: None — expected
5 arm64: dts: qcom: kaanapali: add TGU in staging dtso PENDING: None — expected

Commit Message

Evaluated for each commit against the hygiene rules (subject clarity, body rationale, Fixes tag, authorship, Co-developed-by misuse):

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Each commit has a concise, accurate one-line description of what is added and why (IPCB/DDR trace support)
Fixes tag present/correct N/A New feature additions; no Fixes: tag required
Authorship preserved ✅ Single author Jie Gan <[email protected]> with matching Signed-off-by: on all 5 commits
Backport note (if applicable) N/A Not a backport
Co-developed-by misuse ✅ No Co-developed-by: present; not applicable

⚠️ WARNING — Commit 3 & 4 (hamoa / sm8750) identical TGU addresses:
Both hamoa-staging.dtso and sm8750-staging.dtso define TGU nodes at the exact same three addresses (0x10b0e000, 0x10b0f000, 0x10b10000). This is suspicious — either the hamoa and sm8750 SoCs genuinely share the same TGU register layout (possible if they are closely related), or one set of addresses was copy-pasted incorrectly. The commit messages do not explain this coincidence. This warrants a human review to confirm the addresses are intentional.

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile (commits 1–5) ✅ Each commit appends one dtb-$(CONFIG_ARCH_QCOM) += <board>-staging.dtbo line with a blank separator; consistent with existing Makefile style
arch/arm64/boot/dts/qcom/glymur-staging.dtso (commit 1) ✅ New file; SPDX header, /dts-v1/; /plugin/;, &soc overlay; TGU nodes at 0x11c02000, 0x11c0e000, 0x11c0f000, 0x11c10000; CTCU, replicator, and two ETR TMC nodes with correct iommus, arm,scatter-gather, and cross-linked remote-endpoint labels
arch/arm64/boot/dts/qcom/glymur-staging.dtso (commit 2) ⚠️ Large addition (1248 lines) to the same file: 18 ETE nodes (cpu0–cpu17) under &{/}, 18 per-CPU replicators, 3 cluster funnels, 3 cluster ETF TMCs, one APSS funnel, and a tn@11200000 port extension. All remote-endpoint cross-references appear internally consistent. See issue #1 below.
arch/arm64/boot/dts/qcom/hamoa-staging.dtso (commit 3) ⚠️ New file; 3 TGU nodes. See issue #2 below (address overlap with sm8750).
arch/arm64/boot/dts/qcom/sm8750-staging.dtso (commit 4) ⚠️ New file; 3 TGU nodes at identical addresses to hamoa. See issue #2 below.
arch/arm64/boot/dts/qcom/kaanapali-staging.dtso (commit 5) ✅ New file; 4 TGU nodes at distinct addresses (0x11301000, 0x1130e000, 0x1130f000, 0x11310000); consistent style

Upstream Patch Status

Commit Community Verdict
glymur: add TGU and ETR in staging dtso N/A — PENDING: vendor-only; not posted upstream
glymur: add Coresight devices for APSS debug block N/A — PENDING: vendor-only; not posted upstream
hamoa: add TGU in staging dtso N/A — PENDING: vendor-only; not posted upstream
sm8750: add TGU in staging dtso N/A — PENDING: vendor-only; not posted upstream
kaanapali: add TGU in staging dtso N/A — PENDING: vendor-only; not posted upstream

Dependency Check

  • No Depends-on: or prerequisite mentions in any commit message.
  • Commits 1 and 2 both target glymur-staging.dtso and are ordered correctly (commit 1 creates the file; commit 2 extends it).
  • No shared header or helper changes required for DTS-only additions.
  • Makefile entries are added in the same commit as the corresponding .dtso file — no split dependency.

qcom-next Presence

Commit Status
glymur: add TGU and ETR in staging dtso ⏭️ Skipped — canonical repo /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel not found; network access restricted
glymur: add Coresight devices for APSS debug block ⏭️ Skipped — same reason
hamoa: add TGU in staging dtso ⏭️ Skipped — same reason
sm8750: add TGU in staging dtso ⏭️ Skipped — same reason
kaanapali: add TGU in staging dtso ⏭️ Skipped — same reason

Issues Found

  1. Commit 2 — glymur-staging.dtso Coresight block: funnel@1d021000 uses arm,primecell without arm,coresight-dynamic-funnel
    The APSS funnel at 0x12080000 correctly uses "arm,coresight-dynamic-funnel", "arm,primecell", but the NCC cluster funnels (e.g. funnel@1d021000, funnel@1d081000, funnel@1d121000, etc.) use only "arm,primecell" with an explicit arm,primecell-periphid. This is a deliberate pattern (matching the primecell peripheral ID directly) and is consistent with how similar per-cluster funnels are described in other Qualcomm DTS files (e.g. sa8775p). Not a blocking issue, but reviewers should confirm the periphid 0x000bb908 is correct for the glymur funnel variant.

  2. Commits 3 & 4 — hamoa-staging.dtso and sm8750-staging.dtso share identical TGU register addresses
    Both files define TGU nodes at 0x10b0e000, 0x10b0f000, and 0x10b10000. If hamoa and sm8750 are distinct SoCs with different TGU layouts, one set of addresses is wrong. The commit messages do not explain the overlap. Human review required to confirm these addresses are intentional for both platforms.

  3. Commit 2 — glymur-staging.dtso: tn@11200000 node adds only an in-ports extension with no compatible or reg
    The tn@11200000 node in commit 2 is a partial overlay (adds port@36 / tn_ag_in54 endpoint only). This is valid DTS overlay syntax when the base node already exists in the non-staging DTS, but reviewers should confirm tn@11200000 is defined in the base glymur.dtsi / sa8775p.dtsi with the correct compatible and reg.

Recommendation

The PR is structurally sound for PENDING: vendor-only staging overlays. Commit messages are concise and accurate, authorship is consistent, Makefile entries follow existing style, and the Coresight topology in commits 1–2 is internally self-consistent. Before merging, the reviewer should:

Final Summary

  1. Lore link present: No — all 5 commits carry PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — all commits are vendor-only (PENDING:), not posted upstream
  4. PR present in qcom-next: Not checked — canonical kernel repo unavailable locally and network access is restricted; verify manually

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
❌ 2 Full report

Final Summary

  1. Lore link present: No — no lore.kernel.org link found in pr.patch
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — cannot determine without lore message-id/thread
  4. PR present in qcom-next: Not checked — constrained by scope and no lore-backed validation path
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #602 (title not available in local pr.patch)
Upstream commit: N/A (no lore link found)
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream ❌ No lore.kernel.org reference in PR patch/commit messages, so no upstream subject to compare.
Body preserves rationale ⚠️ Commit bodies are present, but upstream rationale cannot be validated without a lore source.
Fixes tag present/correct ⚠️ No Fixes: tags found; correctness cannot be assessed against upstream.
Authorship preserved ⚠️ Signed-off-by: Jie Gan present on all 5 commits, but upstream author parity cannot be checked without lore.
Backport note (if applicable) N/A Commits are PENDING: (not marked as backports).

Diff

File Status Notes
All files in 5 commits ⚠️ Local diff is readable, but faithful comparison to upstream cannot be performed without a lore patch link.

Issues

  • No lore.kernel.org URL found in PR commit messages (Link: / Patch-mainline: / raw lore URL missing).
  • All commits are prefixed PENDING:; per policy these are vendor/WIP style commits and are not validate-patch comparable to lore unless a specific lore link is provided.

Verdict

Do not merge under validate-patch gating until a valid lore link is provided for each upstream-intended commit (or explicitly treat this PR as vendor-only/non-upstream-tracked).

Final Summary

  1. Lore link present: No — no lore.kernel.org link found in pr.patch
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — cannot determine without lore message-id/thread
  4. PR present in qcom-next: Not checked — constrained by scope and no lore-backed validation path

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
⚠️ PARTIAL 1 Full report

Final Summary

  1. Lore link present: No — all 5 commits use the PENDING: prefix; no lore.kernel.org link is expected or required for any of them.
  2. Lore link matches PR commits: N/A — no lore link to compare against for any commit.
  3. Upstream patch status: N/A — all commits are vendor-only staging DT overlays, not posted upstream.
  4. PR present in qcom-next: Partially — Commit 1 (glymur: add TGU and ETR) is already present in qcom-next as ef11d92a47a0; Commits 2–5 are not yet in qcom-next.
Verdict: ⚠️ PARTIAL — click to expand

🔍 Patch Validation — PR #602

PR: qualcomm-linux/kernel #602 — "PENDING: arm64: dts: qcom: add TGU/ETR/Coresight staging overlays (glymur, hamoa, sm8750, kaanapali)"
Upstream commit: N/A — all 5 commits carry the PENDING: prefix; no lore.kernel.org links are present or expected.
Verdict: ⚠️ PARTIAL (see per-commit notes; structurally sound but Commit 1 is a duplicate of an already-merged qcom-next entry)

Commit 1 of 5 — PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso

Author: Jie Gan <[email protected]>
Files changed: arch/arm64/boot/dts/qcom/Makefile, arch/arm64/boot/dts/qcom/glymur-staging.dtso (new file, 201 lines)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream to compare
Body preserves rationale ✅ Brief but adequate: describes TGU (IPCB) and ETR (DDR trace) purpose
Fixes tag present/correct N/A Not a bug-fix commit
Authorship preserved ✅ Single author; From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds glymur-staging.dtbo entry cleanly
arch/arm64/boot/dts/qcom/glymur-staging.dtso ✅ New file; adds CTCU, replicators, ETR TMCs, and TGU nodes under &soc

Issues

  • ⚠️ Duplicate in qcom-next: This exact commit is already present in origin/qcom-next as ef11d92a47a0. Merging it again will create a duplicate commit. The PR should either drop this commit or rebase on top of qcom-next so it is a no-op.

Per-Commit Verdict

PENDING: vendor-only commit — lore validation not applicable. Content is correct, but the commit already landed in qcom-next (ef11d92a47a0); it must be dropped or the branch rebased before merging.

Commit 2 of 5 — PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block

Author: Jie Gan <[email protected]>
Files changed: arch/arm64/boot/dts/qcom/glymur-staging.dtso (+1248 lines)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream
Body preserves rationale ✅ Lists device types added (ETM, replicator, funnel, TMC ETF)
Fixes tag present/correct N/A Not a bug-fix commit
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/glymur-staging.dtso ✅ Adds 18 ETE nodes under &{/}, APSS funnel, NCC cluster funnels/ETFs/replicators for 3 clusters (cpu0–17), and tn@11200000 port extension

Issues

  • None identified for this commit.

Per-Commit Verdict

PENDING: vendor-only commit — lore validation not applicable. Content is self-consistent and well-structured. Not yet in qcom-next.

Commit 3 of 5 — PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso

Author: Jie Gan <[email protected]>
Files changed: arch/arm64/boot/dts/qcom/Makefile, arch/arm64/boot/dts/qcom/hamoa-staging.dtso (new file, 35 lines)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream
Body preserves rationale ✅ Describes TGU addition for IPCB feature
Fixes tag present/correct N/A Not a bug-fix commit
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds hamoa-staging.dtbo entry cleanly
arch/arm64/boot/dts/qcom/hamoa-staging.dtso ✅ New file; 3 TGU nodes at 0x10b0e000, 0x10b0f000, 0x10b10000

Issues

  • None identified.

Per-Commit Verdict

PENDING: vendor-only commit — lore validation not applicable. Content is correct. Not yet in qcom-next.

Commit 4 of 5 — PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso

Author: Jie Gan <[email protected]>
Files changed: arch/arm64/boot/dts/qcom/Makefile, arch/arm64/boot/dts/qcom/sm8750-staging.dtso (new file, 35 lines)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream
Body preserves rationale ✅ Describes TGU addition for IPCB feature
Fixes tag present/correct N/A Not a bug-fix commit
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds sm8750-staging.dtbo entry cleanly
arch/arm64/boot/dts/qcom/sm8750-staging.dtso ✅ New file; 3 TGU nodes at 0x10b0e000, 0x10b0f000, 0x10b10000 — same addresses as hamoa; intentional if both boards share the same SoC TGU layout

Issues

  • ⚠️ Address overlap with hamoa: sm8750-staging.dtso and hamoa-staging.dtso define TGU nodes at identical addresses (0x10b0e000, 0x10b0f000, 0x10b10000). This is only correct if both boards are based on the same SoC with the same TGU register map. Worth a reviewer double-check to confirm this is intentional and not a copy-paste error.

Per-Commit Verdict

PENDING: vendor-only commit — lore validation not applicable. Content is structurally correct. Address overlap with hamoa warrants a reviewer sanity-check. Not yet in qcom-next.

Commit 5 of 5 — PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso

Author: Jie Gan <[email protected]>
Files changed: arch/arm64/boot/dts/qcom/Makefile, arch/arm64/boot/dts/qcom/kaanapali-staging.dtso (new file, 43 lines)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING: — no upstream
Body preserves rationale ✅ Describes TGU addition for IPCB feature
Fixes tag present/correct N/A Not a bug-fix commit
Authorship preserved ✅ From: matches Signed-off-by:
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Adds kaanapali-staging.dtbo entry cleanly
arch/arm64/boot/dts/qcom/kaanapali-staging.dtso ✅ New file; 4 TGU nodes at 0x11301000, 0x1130e000, 0x1130f000, 0x11310000 — distinct addresses from hamoa/sm8750, consistent with a different SoC

Issues

  • None identified.

Per-Commit Verdict

PENDING: vendor-only commit — lore validation not applicable. Content is correct. Not yet in qcom-next.

Final Summary

  1. Lore link present: No — all 5 commits use the PENDING: prefix; no lore.kernel.org link is expected or required for any of them.
  2. Lore link matches PR commits: N/A — no lore link to compare against for any commit.
  3. Upstream patch status: N/A — all commits are vendor-only staging DT overlays, not posted upstream.
  4. PR present in qcom-next: Partially — Commit 1 (glymur: add TGU and ETR) is already present in qcom-next as ef11d92a47a0; Commits 2–5 are not yet in qcom-next.

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ All 5 commits clean — 0 errors, 0 warnings
dt-binding-check ⏭️ Skipped — no changes in Documentation/devicetree/bindings
dtb-check ✅ Test passed — pre-existing tree warnings filtered; no new errors introduced
sparse-check ⏭️ Skipped — no C/H file changes
check-uapi-headers ⏭️ Skipped — no C/H file changes
check-patch-compliance ❌ All 5 commits fail — PENDING: is not an accepted prefix
tag-check ✅ All 5 commits carry PENDING: — valid tag for qcom-6.18.y branch
qcom-next-check N/A PENDING: commits are not expected in qcom-next

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #602 — PENDING: arm64: dts: qcom: add TGU/ETR/Coresight staging DTS nodes (5 commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/26135626742
Target branch: qcom-6.18.y (tag-check is mandatory — not qcom-next / qcom-next-staging)

Checker Result Summary
checkpatch ✅ All 5 commits clean — 0 errors, 0 warnings
dt-binding-check ⏭️ Skipped — no changes in Documentation/devicetree/bindings
dtb-check ✅ Test passed — pre-existing tree warnings filtered; no new errors introduced
sparse-check ⏭️ Skipped — no C/H file changes
check-uapi-headers ⏭️ Skipped — no C/H file changes
check-patch-compliance ❌ All 5 commits fail — PENDING: is not an accepted prefix
tag-check ✅ All 5 commits carry PENDING: — valid tag for qcom-6.18.y branch
qcom-next-check N/A PENDING: commits are not expected in qcom-next

❌ check-patch-compliance

Root cause: All 5 commits use the PENDING: prefix, which is not in the allowed set (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:) that check-patch-compliance enforces.

Failure details:

Checking commit: PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso
Commit summary does not start with a required prefix

Checking commit: PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso
Commit summary does not start with a required prefix

##[error]Process completed with exit code 1.

Assessment: This is a known checker limitation — PENDING: is a valid vendor-internal prefix used in the tree for work-in-progress patches not yet posted upstream, but check-patch-compliance only accepts upstream-linkable prefixes. Since these are staging DTS overlays (.dtso) that are genuinely not yet posted to the mailing list, PENDING: is the correct prefix. No patch change is needed unless the patches have since been posted upstream.

Fix (if patches have been posted to lore):

# For each commit, if the patch is now on lore.kernel.org:
git rebase -i <base_sha>   # mark each commit as 'edit'
git commit --amend -m "FROMLIST: arm64: dts: qcom: <original subject>"
# Add: Link: https://lore.kernel.org/r/<message-id>
git rebase --continue

Fix (if patches remain vendor-only / not posted):
No action required — PENDING: is the correct prefix for unposted work-in-progress. The check-patch-compliance failure is a known false positive for PENDING: commits.

Reproduce locally:

./scripts/check-patch-compliance.sh --git <base_sha>..<head_sha>

Verdict

1 checker failure, 0 patch defects. The sole failure (check-patch-compliance) is a known checker limitation — PENDING: is a legitimate vendor-internal prefix that the compliance checker does not accept. All other checkers pass or are correctly skipped (DTS-only PR). The PR is ready to merge from a code-quality standpoint; the check-patch-compliance failure requires no patch change unless these patches have been posted upstream (in which case switch to FROMLIST: + add Link: trailers).

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
❌ FAIL 2 Full report

Final Summary

  1. Lore link present: No — all commits are PENDING: and contain no lore URL in commit messages/patch content
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only PENDING: series; no posted upstream reference to assess
  4. PR present in qcom-next: Not checked — per scope constraint, kernel tree lookup was not performed
Verdict: ❌ FAIL — click to expand

🔍 Patch Validation

PR: #602 (title unavailable in offline environment)
Upstream commit: N/A (no lore link found)
Verdict: ❌ FAIL

Commit 1 — PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso

Per-Commit Verdict

Verdict: ❌ FAIL (validate-patch not applicable without lore source)

Commit Message

Check Status Note
Subject matches upstream ❌ No lore/upstream link to compare
Body preserves rationale ⚠️ Cannot validate against upstream text
Fixes tag present/correct N/A New DTS feature addition; no upstream reference provided
Authorship preserved ⚠️ Cannot verify against lore author without link
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Change present, but no upstream patch to validate faithfulness
arch/arm64/boot/dts/qcom/glymur-staging.dtso ⚠️ New file added; no lore baseline for comparison

Issues

  • No Link: https://lore.kernel.org/... (or equivalent) found for this commit.
  • PENDING: prefix indicates vendor/WIP flow; upstream-alignment validation is not possible in this skill.

Verdict

Cannot validate upstream faithfulness; add lore link (or keep as vendor-only with explicit non-upstream intent).

Commit 2 — PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block

Per-Commit Verdict

Verdict: ❌ FAIL (validate-patch not applicable without lore source)

Commit Message

Check Status Note
Subject matches upstream ❌ No lore/upstream link to compare
Body preserves rationale ⚠️ Cannot validate against upstream text
Fixes tag present/correct N/A Feature addition; no upstream reference provided
Authorship preserved ⚠️ Cannot verify against lore author without link
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/glymur-staging.dtso ⚠️ Large insertion; no lore baseline for comparison

Issues

  • No lore link for commit-to-upstream mapping.

Verdict

Upstream alignment cannot be validated until a lore reference is provided.

Commit 3 — PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso

Per-Commit Verdict

Verdict: ❌ FAIL (validate-patch not applicable without lore source)

Commit Message

Check Status Note
Subject matches upstream ❌ No lore/upstream link to compare
Body preserves rationale ⚠️ Cannot validate against upstream text
Fixes tag present/correct N/A Feature addition; no upstream reference provided
Authorship preserved ⚠️ Cannot verify against lore author without link
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Change present, but no upstream patch to validate faithfulness
arch/arm64/boot/dts/qcom/hamoa-staging.dtso ⚠️ New file added; no lore baseline for comparison

Verdict

Cannot establish upstream faithfulness without lore linkage.

Commit 4 — PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso

Per-Commit Verdict

Verdict: ❌ FAIL (validate-patch not applicable without lore source)

Commit Message

Check Status Note
Subject matches upstream ❌ No lore/upstream link to compare
Body preserves rationale ⚠️ Cannot validate against upstream text
Fixes tag present/correct N/A Feature addition; no upstream reference provided
Authorship preserved ⚠️ Cannot verify against lore author without link
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Change present, but no upstream patch to validate faithfulness
arch/arm64/boot/dts/qcom/sm8750-staging.dtso ⚠️ New file added; no lore baseline for comparison

Verdict

Cannot establish upstream faithfulness without lore linkage.

Commit 5 — PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso

Per-Commit Verdict

Verdict: ❌ FAIL (validate-patch not applicable without lore source)

Commit Message

Check Status Note
Subject matches upstream ❌ No lore/upstream link to compare
Body preserves rationale ⚠️ Cannot validate against upstream text
Fixes tag present/correct N/A Feature addition; no upstream reference provided
Authorship preserved ⚠️ Cannot verify against lore author without link
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Change present, but no upstream patch to validate faithfulness
arch/arm64/boot/dts/qcom/kaanapali-staging.dtso ⚠️ New file added; no lore baseline for comparison

Verdict

Cannot establish upstream faithfulness without lore linkage.

Final Summary

  1. Lore link present: No — all commits are PENDING: and contain no lore URL in commit messages/patch content
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only PENDING: series; no posted upstream reference to assess
  4. PR present in qcom-next: Not checked — per scope constraint, kernel tree lookup was not performed

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ All 5 commits report 0 errors, 0 warnings, 0 checks; checker passed.
dt-binding-check ⏭️ No changes in Documentation/devicetree/bindings.
dtb-check ✅ Final result is Log Summary: Test passed (no new dtb-check deltas after base-vs-head filtering).
sparse-check ⏭️ Skipping sparse check as nothing changed...
check-uapi-headers ⏭️ Skipping uapi check as nothing changed...
check-patch-compliance ❌ All 5 commits failed prefix policy for this checker.
tag-check ✅ Base branch is qcom-6.18.y (non-qcom-next), and all subjects start with valid tag PENDING:.
qcom-next-check ⏭️ No FROMLIST:/UPSTREAM:/FROMGIT:/BACKPORT: commits in this PR, so not applicable.

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #602 — DTS staging TGU/Coresight additions (PENDING: series, 5 commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/26135626742

Checker Result Summary
checkpatch ✅ All 5 commits report 0 errors, 0 warnings, 0 checks; checker passed.
dt-binding-check ⏭️ No changes in Documentation/devicetree/bindings.
dtb-check ✅ Final result is Log Summary: Test passed (no new dtb-check deltas after base-vs-head filtering).
sparse-check ⏭️ Skipping sparse check as nothing changed...
check-uapi-headers ⏭️ Skipping uapi check as nothing changed...
check-patch-compliance ❌ All 5 commits failed prefix policy for this checker.
tag-check ✅ Base branch is qcom-6.18.y (non-qcom-next), and all subjects start with valid tag PENDING:.
qcom-next-check ⏭️ No FROMLIST:/UPSTREAM:/FROMGIT:/BACKPORT: commits in this PR, so not applicable.

❌ check-patch-compliance

Root cause: check-patch-compliance only accepts upstream-linkable prefixes (FROMLIST:/FROMGIT:/UPSTREAM:/BACKPORT:), but every commit in this PR uses PENDING:.

Failure details:

Checking commit: PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso
Commit summary does not start with a required prefix
##[error]Process completed with exit code 1.

Fix:
Use one accepted prefix per commit (FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:) and amend commit subjects accordingly.
If these are not upstream-posted patches, this checker will continue to fail by policy/limitation for PENDING:-style vendor/WIP commits.

Reproduce locally:
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src <kernel-src> --base 0136c1ed9c23851783df4ad39ad3556497cc3c2a --head 02eeba05fc7c3ced8283ae82c9beed288d1a8c84

Verdict

1 blocker to merge: check-patch-compliance prefix-policy failure on all 5 commits.

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — validate-patch

PR: #602

Verdict Issues Detailed Report
❌ FAIL 3 Full report

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit
Verdict: ❌ FAIL — click to expand

🔍 Patch Validation

PR: qualcomm-linux/kernel PR [#602] (title not present in provided artifact)
Upstream commit: N/A (no lore.kernel.org link found)
Verdict: ❌ FAIL

Step 1 result: all 5 commits in pr.patch are PENDING: and none contains Link: https://lore.kernel.org/... or equivalent.
PR changes these files: arch/arm64/boot/dts/qcom/Makefile, arch/arm64/boot/dts/qcom/glymur-staging.dtso, arch/arm64/boot/dts/qcom/hamoa-staging.dtso, arch/arm64/boot/dts/qcom/sm8750-staging.dtso, arch/arm64/boot/dts/qcom/kaanapali-staging.dtso.

Commit 1/5 — PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso

Commit Message

Check Status Note
Subject matches upstream ⚠️ No lore/upstream source provided for comparison
Body preserves rationale ⚠️ No lore/upstream source provided for comparison
Fixes tag present/correct ⚠️ No Fixes: tag; appears to be feature/addition, but not upstream-verifiable
Authorship preserved ⚠️ From/Signed-off-by internally consistent; no lore author to verify against
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Cannot validate faithfulness without lore source
arch/arm64/boot/dts/qcom/glymur-staging.dtso ⚠️ Cannot validate faithfulness without lore source

Per-Commit Verdict

Vendor-only PENDING: commit with no lore link; upstream-faithfulness validation is not possible.

Commit 2/5 — PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block

Commit Message

Check Status Note
Subject matches upstream ⚠️ No lore/upstream source provided for comparison
Body preserves rationale ⚠️ No lore/upstream source provided for comparison
Fixes tag present/correct ⚠️ No Fixes: tag; not upstream-verifiable
Authorship preserved ⚠️ Internally consistent only; no upstream author reference
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/glymur-staging.dtso ⚠️ Cannot validate faithfulness without lore source

Per-Commit Verdict

Vendor-only PENDING: commit with no lore link; upstream-faithfulness validation is not possible.

Commit 3/5 — PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream ⚠️ No lore/upstream source provided for comparison
Body preserves rationale ⚠️ No lore/upstream source provided for comparison
Fixes tag present/correct ⚠️ No Fixes: tag; not upstream-verifiable
Authorship preserved ⚠️ Internally consistent only; no upstream author reference
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Cannot validate faithfulness without lore source
arch/arm64/boot/dts/qcom/hamoa-staging.dtso ⚠️ Cannot validate faithfulness without lore source

Per-Commit Verdict

Vendor-only PENDING: commit with no lore link; upstream-faithfulness validation is not possible.

Commit 4/5 — PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream ⚠️ No lore/upstream source provided for comparison
Body preserves rationale ⚠️ No lore/upstream source provided for comparison
Fixes tag present/correct ⚠️ No Fixes: tag; not upstream-verifiable
Authorship preserved ⚠️ Internally consistent only; no upstream author reference
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Cannot validate faithfulness without lore source
arch/arm64/boot/dts/qcom/sm8750-staging.dtso ⚠️ Cannot validate faithfulness without lore source

Per-Commit Verdict

Vendor-only PENDING: commit with no lore link; upstream-faithfulness validation is not possible.

Commit 5/5 — PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso

Commit Message

Check Status Note
Subject matches upstream ⚠️ No lore/upstream source provided for comparison
Body preserves rationale ⚠️ No lore/upstream source provided for comparison
Fixes tag present/correct ⚠️ No Fixes: tag; not upstream-verifiable
Authorship preserved ⚠️ Internally consistent only; no upstream author reference
Backport note (if applicable) N/A Not marked as backport

Diff

File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Cannot validate faithfulness without lore source
arch/arm64/boot/dts/qcom/kaanapali-staging.dtso ⚠️ Cannot validate faithfulness without lore source

Per-Commit Verdict

Vendor-only PENDING: commit with no lore link; upstream-faithfulness validation is not possible.

Issues

  • No commit in this PR includes a lore.kernel.org link, so canonical upstream comparison cannot be performed.
  • Upstream status (ACKed/NACKed/Pending) cannot be determined for these commits from lore because no lore message-IDs are provided.
  • qcom-next presence was not checked, per your explicit constraint to avoid checking out/searching kernel source trees.

Verdict

Do not merge as an upstream-aligned/backport-validated series in current form; treat as vendor-only PENDING: changes unless lore links are added for upstream validation.

Final Summary

  1. Lore link present: No — PENDING: prefix; no lore link expected or required
  2. Lore link matches PR commits: N/A — no lore link to compare against
  3. Upstream patch status: N/A — vendor-only change, not posted upstream
  4. PR present in qcom-next: Not checked — PENDING: vendor-only commit

@rahujosh
Copy link
Copy Markdown

rahujosh commented May 20, 2026

PR #602 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ Passed (checkpatch.sh passed), no warnings/errors reported for all 5 commits.
dt-binding-check ⏭️ Skipped: No changes in Documentation/devicetree/bindings.
dtb-check ✅ Passed: Log Summary: Test passed.
sparse-check ⏭️ Skipped: Skipping sparse check as nothing changed....
check-uapi-headers ⏭️ Skipped: Skipping uapi check as nothing changed... (no SHA ancestry CI bug seen).
check-patch-compliance ❌ Failed on all 5 commits: Commit summary does not start with a required prefix.
tag-check ✅ Target branch is qcom-6.18.y (non-qcom-next), check is mandatory, and all commit subjects have valid tag prefixes (PENDING:).
qcom-next-check ⏭️ Not applicable: no FROMLIST:/FROMGIT:/UPSTREAM:/BACKPORT: commits (all are PENDING:).

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: PR #602 — PENDING: arm64: dts: qcom staging dtso series (5 commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/26135626742

Checker Result Summary
checkpatch ✅ Passed (checkpatch.sh passed), no warnings/errors reported for all 5 commits.
dt-binding-check ⏭️ Skipped: No changes in Documentation/devicetree/bindings.
dtb-check ✅ Passed: Log Summary: Test passed.
sparse-check ⏭️ Skipped: Skipping sparse check as nothing changed....
check-uapi-headers ⏭️ Skipped: Skipping uapi check as nothing changed... (no SHA ancestry CI bug seen).
check-patch-compliance ❌ Failed on all 5 commits: Commit summary does not start with a required prefix.
tag-check ✅ Target branch is qcom-6.18.y (non-qcom-next), check is mandatory, and all commit subjects have valid tag prefixes (PENDING:).
qcom-next-check ⏭️ Not applicable: no FROMLIST:/FROMGIT:/UPSTREAM:/BACKPORT: commits (all are PENDING:).

❌ check-patch-compliance

Root cause: Commit subjects use PENDING: which is rejected by check-patch-compliance (it only accepts upstream-linkable prefixes).

Failure details:

Checking commit: PENDING: arm64: dts: qcom: glymur: add TGU and ETR in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: glymur: add Coresight devices for APSS debug block
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: hamoa: add TGU in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: sm8750: add TGU in staging dtso
Commit summary does not start with a required prefix
Checking commit: PENDING: arm64: dts: qcom: kaanapali: add TGU in staging dtso
Commit summary does not start with a required prefix

Fix:

  1. Reword each commit subject to an accepted compliance prefix (FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:) based on origin.
  2. If using FROMLIST:, add a valid Link: trailer to lore in each commit message.
  3. If these are truly not posted upstream yet, this checker will continue to fail until policy/prefix changes or upstream posting is done.

Reproduce locally:
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src <kernel_src> --base 0136c1ed9c23851783df4ad39ad3556497cc3c2a --head 02eeba05fc7c3ced8283ae82c9beed288d1a8c84

Verdict

1 blocker to fix before merge: check-patch-compliance prefix policy failure on all 5 commits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@quic-tingweiz quic-tingweiz quic-tingweiz approved these changes

@ndechesne ndechesne Awaiting requested review from ndechesne ndechesne was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

@yijiyang yijiyang Awaiting requested review from yijiyang yijiyang was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

@jingyiwang42 jingyiwang42 Awaiting requested review from jingyiwang42 jingyiwang42 was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jiegan0107 @knaveen-qc @qcomlnxci @rahujosh @quic-tingweiz