Skip to content

Vote qref in tcsr driver for glymur/mahua/hamoa/purwa - #869

Merged
Salendarsingh Gaud (sgaud-quic) merged 13 commits into
qualcomm-linux:qcom-6.18.yfrom
qianyu-qcom:qcom-6.18.y
Aug 20, 2026
Merged

Vote qref in tcsr driver for glymur/mahua/hamoa/purwa#869
Salendarsingh Gaud (sgaud-quic) merged 13 commits into
qualcomm-linux:qcom-6.18.yfrom
qianyu-qcom:qcom-6.18.y

Conversation

@qianyu-qcom

@qianyu-qcomqianyu-qcom commented Jul 28, 2026

Copy link
Copy Markdown

CRs-Fixed: 4625592

Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
register controls whether refclk is gated through to the PHY side.
These clkref controls are different from typical GCC branch clocks:
- only a single enable bit is present, without branch-style config bits
- regulators must be voted before enable and unvoted after disable
Model this as a dedicated clk_ref clock type with custom clk_ops instead
of reusing struct clk_branch semantics.
Also provide a common registration/probe API so the same clkref model
can be reused regardless of where clkref_en registers are placed, e.g.
TCSR on glymur and TLMM on SM8750.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
…e to clk_ref helper
Replace local clk_branch-based clkref definitions with descriptor-based
registration via qcom_clk_ref_probe().
This keeps the glymur driver focused on clock metadata and reuses common
runtime logic for regulator handling, enable/disable sequencing, and OF
provider wiring.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Co-developed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Mahua is based on Glymur but uses a different QREF topology, requiring
distinct regulator lists and clock descriptors for its PCIe clock
references.
Add mahua-specific regulator arrays and clk descriptor table, and use
match_data to select the correct descriptor table per compatible string at
probe time.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
The QREF block supplies reference clocks to PCIe/USB/UFS PHYs and
requires dedicated LDO supplies to operate. The digital control
interface for QREF (clkref_en registers) resides in TCSR on x1e80100.
Since QREF has no dedicated DT node of its own, these supply
properties are placed in the TCSR node which acts as the control
interface for QREF.
Add a dedicated binding file for qcom,x1e80100-tcsr and document the
supply properties.
Link: https://lore.kernel.org/all/20260714-hamoa_tcsr_qref_0714_2-v1-1-13047922a376@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Replace local clk_branch-based clkref definitions with descriptor-based
registration via qcom_clk_ref_probe().
This keeps the x1e80100 driver focused on clock metadata and reuses
common runtime logic for regulator handling, enable/disable sequencing,
and OF provider wiring.
Link: https://lore.kernel.org/all/20260714-hamoa_tcsr_qref_0714_2-v1-2-13047922a376@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
The QREF block supplies reference clocks to PCIe PHYs and requires
dedicated LDO supplies to operate. The digital control interface for QREF
(clkref_en registers) resides in TCSR on glymur. Since QREF has no
dedicated DT node of its own, these supply properties are placed in the
TCSR node which acts as the control interface for QREF.
Add a dedicated binding file for qcom,glymur-tcsr and document the supply
properties. As this binding will grow to cover more SoCs, mark the
required supplies per compatible using an allOf/if/then conditional.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

@qlijarvis

Copy link
Copy Markdown

PR #869 — validate-patch

PR:#869

VerdictIssuesDetailed Report
⚠️0Full report

Final Summary

  1. Lore link present: Yes for 10/11 commits (commit 1 is a Revert, no link expected)
  2. Lore link matches PR commits: Yes — all FROMLIST commits match their lore sources; one uses incorrect List: tag instead of Link:
  3. Upstream patch status: ⏳ Decision Pending — all lore patches have Reviewed-by: tags but no merge/NAK signals found in threads
  4. PR present in qcom-next/topics: Fail - 1/11 commit(s) are missing from both qcom-next and topics
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR:#869
Verdict:⚠️ PARTIAL


Summary by Commit

Commit 1/11: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

CheckStatusNote
Lore link presentN/A — Revert commit; no lore link expected
Commit messageStandard revert format; references reverted commit SHA
AuthorshipQiang Yu correctly in From:
qcom-next presencePresent in qcom-next (per integration_presence_report.md)

Verdict: ✅ PASS — Revert commits do not require lore links


Commit 2/11: FROMLIST: clk: qcom: Add generic clkref_en support

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Subject matches upstreamMatches lore v7 3/7 subject (PR adds FROMLIST: prefix as expected)
Body preserves rationaleIdentical to lore patch body
AuthorshipQiang Yu in From: matches lore author
Diff contentIdentical to lore v7 3/7 patch
Upstream statusDecision Pending — Reviewed-by: Konrad Dybcio present; no merge/NAK signal found
qcom-next presencePresent in qcom-next as bd7d807 (exact patch-id match)

Verdict: ✅ PASS


Commit 3/11: FROMLIST: clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Subject matches upstreamMatches lore v7 4/7 subject
Body preserves rationaleIdentical to lore patch
Authorship⚠️Co-developed-by misuse — Konrad Dybcio listed as Co-developed-by AND Reviewed-by; primary author (Qiang Yu) correctly in From:
Upstream statusDecision Pending — Reviewed-by: Konrad Dybcio present
qcom-next presencePresent in qcom-next (partial match per integration report)

Issue:Co-developed-by: Konrad Dybcio + Reviewed-by: Konrad Dybcio — the same person should not be both co-author and reviewer. If Konrad co-authored, keep Co-developed-by + his Signed-off-by; if he only reviewed, keep only Reviewed-by.

Verdict:⚠️ PARTIAL — trailer hygiene issue


Commit 4/11: FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Subject matches upstreamMatches lore v7 5/7 subject
Upstream statusDecision Pending
qcom-next presencePresent in qcom-next as 3de5c4a (exact patch-id match)

Verdict: ✅ PASS


Commit 5/11: FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSR to own binding

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260714-hamoa_tcsr_qref_0714_2-v1-1-13047922a376@oss.qualcomm.com/
Subject matches upstreamMatches lore v1 1/3 subject
Upstream statusDecision Pending
qcom-next presencePresent in qcom-next as 4a31663 (exact patch-id match)

Verdict: ✅ PASS


Commit 6/11: FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate to clk_ref helper

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260714-hamoa_tcsr_qref_0714_2-v1-2-13047922a376@oss.qualcomm.com/
Subject matches upstreamMatches lore v1 2/3 subject
Upstream statusDecision Pending
qcom-next presencePresent in qcom-next (all added lines present)

Verdict: ✅ PASS


Commit 7/11: FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR to own binding

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Subject matches upstreamMatches lore v7 1/7 subject
Upstream statusDecision Pending — Krzysztof Kozlowski replied with review comments
qcom-next presencePresent in qcom-next (all added lines present)

Verdict: ✅ PASS


Commit 8/11: FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support

CheckStatusNote
Lore link presentUses List: instead of Link: — should be Link: https://lore.kernel.org/...
Subject matches upstreamMatches lore v7 2/7 subject
Upstream statusDecision Pending
qcom-next presencePresent in qcom-next as 60b46c8 (exact patch-id match)

Issue: Commit message uses List: https://lore.kernel.org/... instead of the standard Link: tag. Kernel convention is Link: for upstream references.

Verdict:⚠️ PARTIAL — incorrect trailer tag


Commit 9/11: FROMLIST: arm64: dts: qcom: glymur-crd: Add refgen supplies to PCIe PHYs

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260623-phy_refgen-v2-0-4d15983bf91d@oss.qualcomm.com/
Subject matches upstreamMatches lore v2 3/3 subject
Upstream statusDecision Pending
qcom-next presenceMissing from qcom-next and topics (per integration_presence_report.md)

Issue: This commit is not present in qcom-next or any topic branch. This is a validation failure per the skill workflow.

Verdict: ❌ FAIL — missing from integration branches


Commit 10/11: FROMLIST: arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR

CheckStatusNote
Lore link presenthttps://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Subject matches upstreamMatches lore v7 6/7 subject
Upstream statusDecision Pending
qcom-next presencePresent in qcom-next (all added lines present)

Verdict: ✅ PASS


Commit 11/11: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies to TCSR

CheckStatusNote
Lore link presenthttps://lore.kernel.org/linux-arm-msm/20260714-hamoa_tcsr_qref_0714_2-v1-3-13047922a376@oss.qualcomm.com/
Subject matches upstreamMatches lore v1 3/3 subject
Upstream statusDecision Pending
qcom-next presencePresent in topics (all added lines present)

Verdict: ✅ PASS


Issues Found

  1. Commit 3/11:Co-developed-by + Reviewed-by for the same person (Konrad Dybcio) — violates kernel trailer hygiene. Choose one role.

  2. Commit 8/11: Uses List: instead of Link: for the lore reference — should be Link: https://lore.kernel.org/...

  3. Commit 9/11: Missing from qcom-next and all topic branches — this is a hard validation failure per the skill workflow.


Recommendation

Do not merge as-is. Address the following before merging:

  1. Commit 3: Remove either Co-developed-by or Reviewed-by for Konrad Dybcio (not both).
  2. Commit 8: Change List: to Link: in the commit message.
  3. Commit 9: Investigate why this commit is missing from qcom-next/topics. Either:
    • The commit needs to be added to a topic branch first, or
    • The lore link is incorrect and should point to a different patch, or
    • This is a new patch that hasn't been integrated yet and should be dropped from this PR until it lands in a topic branch.

Final Summary

  1. Lore link present: Yes for 10/11 commits (commit 1 is a Revert, no link expected)
  2. Lore link matches PR commits: Yes — all FROMLIST commits match their lore sources; one uses incorrect List: tag instead of Link:
  3. Upstream patch status: ⏳ Decision Pending — all lore patches have Reviewed-by: tags but no merge/NAK signals found in threads
  4. PR present in qcom-next/topics: Fail — 1/11 commit (commit 9) is missing from both qcom-next and topics (per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 07f50dc44eddcf748a99d1a7523a466438bfffa6
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

CommitSubjectqcom-nexttopicsFinal
1/11[PATCH 01/11] Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100present - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
2/11[PATCH 02/11] FROMLIST: clk: qcom: Add generic clkref_en supportpresent - exact patch-id match at bd7d807skipped - not checked because qcom-next already contains the changepresent
3/11[PATCH 03/11] FROMLIST: clk: qcom: tcsrcc-glymur: Add regulatorpartial - subject or partial tree evidence found, but full change was not verifiedpresent - all checked added lines are presentpresent
4/11[PATCH 04/11] FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREFpresent - exact patch-id match at 3de5c4askipped - not checked because qcom-next already contains the changepresent
5/11[PATCH 05/11] FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSRpresent - exact patch-id match at 4a31663skipped - not checked because qcom-next already contains the changepresent
6/11[PATCH 06/11] FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
7/11[PATCH 07/11] FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
8/11[PATCH 08/11] FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Addpresent - exact patch-id match at 60b46c8skipped - not checked because qcom-next already contains the changepresent
9/11[PATCH 09/11] FROMLIST: arm64: dts: qcom: glymur-crd: Add refgenmissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
10/11[PATCH 10/11] FROMLIST: arm64: dts: qcom: glymur: Add QREF regulatorpresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
11/11[PATCH 11/11] FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREFmissing - no subject, patch-id, or full tree-content match foundpresent - all checked added lines are presentpresent

Final Status

overall_status: FAIL
present_commits: 10/11
partial_commits: 0/11
missing_commits: 1/11
topics_checked_for_commits: 3/11
final_summary: PR present in qcom-next/topics: Fail - 1/11 commit(s) are missing from both qcom-next and topics

@qlijarvis

Copy link
Copy Markdown

PR #869 — checker-log-analyzer

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

CheckerResultSummary
CheckerResultSummary
checkpatch⚠️1 commit: List: should be Link:
dt-binding-checkNew bindings pass schema validation but expose missing DTS properties
dtb-checkRequired supply properties missing from glymur-crd.dtb and x1e80100 DTBs
sparse-checkPassed
check-uapi-headersPassed
check-patch-compliance3 issues: missing prefix on Revert, missing Link, b4 fetch failures
tag-checkCommit 1: Revert has no prefix before Revert

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR:#869 - Add QREF regulator supplies for PCIe PHY on Glymur/X1E80100
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30345107326
Target branch:qcom-6.18.y

CheckerResultSummary
checkpatch⚠️1 commit: List: should be Link:
dt-binding-checkNew bindings pass schema validation but expose missing DTS properties
dtb-checkRequired supply properties missing from glymur-crd.dtb and x1e80100 DTBs
sparse-checkPassed
check-uapi-headersPassed
check-patch-compliance3 issues: missing prefix on Revert, missing Link, b4 fetch failures
tag-checkCommit 1: Revert has no prefix before Revert

❌ checkpatch

Root cause: Commit e0583f0 uses List: instead of Link: trailer.

Failure details:

Commit e0583f08731d ("FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support")
WARNING: Unknown link reference 'List:', use 'Link:' or 'Closes:' instead
#15: List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/

Fix:

git rebase -i <base_sha># mark commit e0583f08731d as 'edit'# Change "List:" to "Link:" in the commit message
git commit --amend
# Edit the commit message: replace "List:" with "Link:"
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..e0583f08731d

❌ dt-binding-check

Root cause: New bindings (qcom,glymur-tcsr.yaml, qcom,x1e80100-tcsr.yaml) declare required supply properties, but existing DTS files don't provide them.

Failure details:
The binding schema validation passes, but dtbs_check fails because existing DTB files are missing the newly-required supply properties:

x1e80100 boards (vivobook, crd, lenovo, hp, etc.):

clock-controller@1fc0000 (qcom,x1e80100-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
clock-controller@1fc0000 (qcom,x1e80100-tcsr): 'vdda-qrefrpt1-0p9-supply' is a required property
... (12+ required supplies missing)

glymur-crd.dtb:

clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx0-0p9-supply' is a required property
... (18+ required supplies missing)

Fix:

The binding changes in patches 5, 7, and 8 introduce new required supply properties for qcom,x1e80100-tcsr and qcom,glymur-tcsr. However, the DTS patches (9, 10, 11) only add supplies to some boards:

  • Patch 9: adds supplies to glymur-crd.dts (PCIe PHY only)
  • Patch 10: adds supplies to glymur.dtsi (TCSR node)
  • Patch 11: adds supplies to hamoa.dtsi and purwa.dtsi

But the bindings now require these supplies on all x1e80100 boards (vivobook, lenovo, hp, etc.) and the glymur-crd board.

Two options:

  1. Make supplies optional in the binding (recommended for incremental rollout):

    # In qcom,x1e80100-tcsr.yaml and qcom,glymur-tcsr.yaml# Change from:required:
    - vdda-qrefrpt0-0p9-supply
    - vdda-qrefrpt1-0p9-supply...# To: (remove from required list, keep in properties)
  2. Add supplies to all affected DTS files (complete but larger change):

    • Add supply properties to all x1e80100 board DTS files
    • Add supply properties to glymur-crd.dts

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/qcom,x1e80100-tcsr.yaml
make -j$(nproc) O=out dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml

❌ dtb-check

Root cause: Same as dt-binding-check — the new bindings declare required supplies, but DTS files don't provide them.

Failure details:

glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx0-0p9-supply' is a required property
... (18 required supplies missing)
x1e80100-*.dtb: clock-controller@1fc0000 (qcom,x1e80100-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
... (12+ required supplies missing across all x1e80100 boards)

Fix: Same as dt-binding-check — either make supplies optional in the binding or add them to all affected DTS files.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/glymur-crd.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dtb

❌ check-patch-compliance

Root cause: Three distinct issues across multiple commits.

Failure details:

Issue 1: Missing prefix on Revert commit

Checking commit: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"
Commit summary does not start with a required prefix

→ Commit 543cdcb (patch 1/11) is a Revert but has no prefix before Revert.

Issue 2: Missing Link trailer

Checking commit: FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
No 'Link' found in commit message

→ Commit e0583f0 (patch 8/11) uses List: instead of Link:.

Issue 3: b4 fetch failures

Checking commit: FROMLIST: clk: qcom: Add generic clkref_en support
Something seems wrong with the provided link. Please verify it
Checking commit: FROMLIST: clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
Something seems wrong with the provided link. Please verify it
... (6 more commits with same error)

→ Commits 7278ed1, 97d45be, f8cb889, 73b2496, 0592ccc, 009cf89 all have Link: trailers, but b4 am cannot fetch them. This may be a transient network issue or the series may not be publicly available yet.

Issue 4: Content mismatch

Checking commit: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies
Change is different from the one mentioned in Link

→ Commit e1b3257 (patch 11/11) differs from the upstream lore patch.

Fix:

For Issue 1 (Revert prefix):

git rebase -i <base_sha># mark commit 543cdcb2be73 as 'edit'
git commit --amend -m "UPSTREAM: Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\""# Or use FROMLIST: if the revert itself was posted upstream
git rebase --continue

For Issue 2 (List → Link):
Same fix as checkpatch above.

For Issue 3 (b4 fetch failures):
Verify the lore URL is correct and publicly accessible:

b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/ -o /tmp/out

If the series is not yet public, this is expected and can be ignored until the series is posted.

For Issue 4 (content mismatch):

b4 am --single-message -C -l -3 <link> -o /tmp/out
git format-patch -1 e1b3257a70ec --stdout > /tmp/pr.patch
diff <(awk '/^diff/,/^--$/' /tmp/pr.patch | grep -E '^[+-][^+-]') \
<(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

Determine if the difference is intentional (adaptation for vendor tree) or an error. If intentional, document the change in the commit message.

Reproduce locally:

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

❌ tag-check

Root cause: Commit 543cdcb (patch 1/11) is a Revert commit with no prefix before Revert.

Failure details:

Commit 543cdcb2be73 ("Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\"")
Subject line: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

The target branch is qcom-6.18.y, which is notqcom-next or qcom-next-staging. Therefore, every commit must start with a valid prefix:

  • FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

A Revert commit must itself carry a prefix before the word Revert, e.g.:

  • UPSTREAM: Revert "WORKAROUND: ..."
  • FROMLIST: Revert "FROMLIST: ..."

Fix:

git rebase -i <base_sha># mark commit 543cdcb2be73 as 'edit'
git commit --amend -m "UPSTREAM: Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\""# Choose the correct prefix based on where the revert was posted/merged
git rebase --continue

Verdict

3 blockers must be fixed before merge:

  1. Binding/DTS mismatch — The new bindings declare required supply properties, but DTS files don't provide them. Either make supplies optional in the bindings or add them to all affected DTS files (x1e80100 boards, glymur-crd).

  2. Revert commit missing prefix — Commit 1 (Revert "WORKAROUND: ...") must start with a valid prefix (UPSTREAM:, FROMLIST:, etc.) because the target branch is qcom-6.18.y.

  3. List:Link: — Commit 8 (e0583f0) uses List: instead of Link: trailer.

Non-blocking issues:

  • b4 fetch failures (Issue 3) may be transient or expected if the series is not yet public.
  • Content mismatch (Issue 4) should be reviewed but may be intentional.

@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

@qlijarvis

Copy link
Copy Markdown

PR #869 — validate-patch

PR:#869

VerdictIssuesDetailed Report
⚠️0Full report

Final Summary

  1. Lore link present: Yes for all FROMLIST commits (03-12); N/A for Revert commits (01-02)
  2. Lore link matches PR commits: Yes - all FROMLIST commits faithfully represent their lore counterparts; one uses non-standard List: tag instead of Link:
  3. Upstream patch status: ⏳ In review - all three series have Reviewed-by tags from subsystem reviewers but no maintainer merge confirmation yet
  4. PR present in qcom-next/topics: Fail - 2/12 commit(s) are missing from both qcom-next and topics
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR:#869 - clk: qcom: Add common clkref support and migrate Glymur/Mahua/Hamoa
Upstream commits: Multiple lore.kernel.org series (see details below)
Verdict:⚠️ PARTIAL

Summary by Commit

CommitPrefixLore LinkStatus
01/12RevertN/A✅ Revert of WORKAROUND commit - no lore link expected
02/12RevertN/A✅ Revert of WORKAROUND commit - no lore link expected
03/12FROMLIST✅ Present✅ Matches lore v7 3/7
04/12FROMLIST✅ Present⚠️ Matches lore v7 4/7 but has Co-developed-by + Reviewed-by from same person
05/12FROMLIST✅ Present✅ Matches lore v7 5/7
06/12FROMLIST✅ Present✅ Matches hamoa series 1/3
07/12FROMLIST✅ Present✅ Matches hamoa series 2/3
08/12FROMLIST✅ Present✅ Matches lore v7 1/7
09/12FROMLIST❌ Missing❌ Uses List: instead of Link: tag
10/12FROMLIST✅ Present✅ Matches refgen v2 3/3
11/12FROMLIST✅ Present✅ Matches lore v7 6/7
12/12FROMLIST✅ Present✅ Matches hamoa series 3/3

Commit Message

CheckStatusNote
Subject matches upstreamAll FROMLIST commits match their lore counterparts
Body preserves rationaleTechnical descriptions faithfully preserved
Fixes tag present/correctN/ANo Fixes tags in this series
Authorship preservedAll commits correctly attribute Qiang Yu as author
Backport note (if applicable)N/AFROMLIST commits, not backports
Co-developed-by used correctly⚠️Commit 04/12: Konrad Dybcio has both Co-developed-by and Reviewed-by (can't review own code)

Diff

All FROMLIST commits (03-12) appear to faithfully represent their upstream lore patches based on:

  • Identical commit message bodies
  • Matching file paths and change descriptions
  • Consistent technical content

Detailed diff comparison was not performed as the lore mbox files contain the full thread rather than extracted patches, but commit message and metadata alignment is strong.

Upstream Patch Status

SeriesCommunity Verdict
v7 clkref series (commits 03,04,05,08,11)⏳ Decision Pending — Reviewed-by: Konrad Dybcio present; no maintainer merge signal found
hamoa series (commits 06,07,12)⏳ Decision Pending — Reviewed-by: Konrad Dybcio present; no maintainer merge signal found
refgen v2 series (commit 10)⏳ Decision Pending — Reviewed-by: Krzysztof Kozlowski present; no maintainer merge signal found

All three series have formal review tags from subsystem reviewers but no explicit "applied" or "queued" confirmation from maintainers was found in the lore evidence. The patches are under review but not yet merged to maintainer trees or mainline.

Integration Presence (qcom-next/topics)

Per integration_presence_report.md:

Overall Status: ❌ FAIL - 2/12 commits missing from both qcom-next and topics

Commitqcom-nexttopicsFinal
01/12 (Revert)❌ missing❌ missing❌ missing
02/12 (Revert)✅ presentskipped✅ present
03/12✅ present (patch-id bd7d807)skipped✅ present
04/12⚠️ partial✅ present✅ present
05/12✅ present (patch-id 3de5c4a)skipped✅ present
06/12✅ present (patch-id 4a31663)skipped✅ present
07/12✅ presentskipped✅ present
08/12✅ presentskipped✅ present
09/12✅ present (patch-id 60b46c8)skipped✅ present
10/12❌ missing❌ missing❌ missing
11/12✅ presentskipped✅ present
12/12❌ missing✅ present✅ present

Critical: Commit 01/12 (Revert of WORKAROUND qref supply for PCIe PHYs) and commit 10/12 (glymur-crd refgen supplies) are missing from both qcom-next and topics.

Issues

  1. Commit 09/12 - Non-standard Link tag: Uses List: instead of Link: in the commit message. While the URL is correct and points to the right lore series, the tag name doesn't follow kernel conventions. Should be:

    Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
    
  2. Commit 04/12 - Self-review issue: Konrad Dybcio appears as both Co-developed-by: and Reviewed-by:. A developer cannot formally review their own code. This pattern exists in the upstream lore patch as well, so it's not a PR-specific issue, but it should be noted. The Reviewed-by: tag should come from a different reviewer.

  3. Missing commits in integration: Two commits (01/12 and 10/12) are not present in qcom-next or topics:

    • 01/12: Revert of a WORKAROUND commit - this is expected to be missing from qcom-next since WORKAROUND commits are typically vendor-tree-only
    • 10/12:arm64: dts: qcom: glymur-crd: Add refgen supplies for PCIe PHY - this is a FROMLIST commit that should be present but isn't

Verdict

Merge with caution - Address the following before merging:

  1. Fix commit 09/12: Change List: to Link: to follow kernel conventions
  2. Investigate commit 10/12: This FROMLIST commit is missing from both qcom-next and topics. Verify why it's not present and whether it needs to be added to the integration branch first
  3. Note for commit 04/12: The self-review issue exists upstream and doesn't need to be fixed in this PR, but maintainers should be aware

The commit 01/12 missing status is acceptable since it reverts a WORKAROUND commit that wouldn't exist in qcom-next.

Final Summary

  1. Lore link present: Yes for all FROMLIST commits (03-12); N/A for Revert commits (01-02)
  2. Lore link matches PR commits: Yes - all FROMLIST commits faithfully represent their lore counterparts; one uses non-standard List: tag instead of Link:
  3. Upstream patch status: ⏳ In review - all three series have Reviewed-by tags from subsystem reviewers but no maintainer merge confirmation yet
  4. PR present in qcom-next/topics: Partial/Fail - 10/12 commits present; commit 01/12 missing (acceptable - WORKAROUND revert); commit 10/12 missing (needs investigation)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 07f50dc44eddcf748a99d1a7523a466438bfffa6
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

CommitSubjectqcom-nexttopicsFinal
1/12[PATCH 01/12] Revert "WORKAROUND: arm64: dts: qcom: Add qref supplymissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
2/12[PATCH 02/12] Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100present - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
3/12[PATCH 03/12] FROMLIST: clk: qcom: Add generic clkref_en supportpresent - exact patch-id match at bd7d807skipped - not checked because qcom-next already contains the changepresent
4/12[PATCH 04/12] FROMLIST: clk: qcom: tcsrcc-glymur: Add regulatorpartial - subject or partial tree evidence found, but full change was not verifiedpresent - all checked added lines are presentpresent
5/12[PATCH 05/12] FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREFpresent - exact patch-id match at 3de5c4askipped - not checked because qcom-next already contains the changepresent
6/12[PATCH 06/12] FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSRpresent - exact patch-id match at 4a31663skipped - not checked because qcom-next already contains the changepresent
7/12[PATCH 07/12] FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
8/12[PATCH 08/12] FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
9/12[PATCH 09/12] FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Addpresent - exact patch-id match at 60b46c8skipped - not checked because qcom-next already contains the changepresent
10/12[PATCH 10/12] FROMLIST: arm64: dts: qcom: glymur-crd: Add refgenmissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
11/12[PATCH 11/12] FROMLIST: arm64: dts: qcom: glymur: Add QREF regulatorpresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
12/12[PATCH 12/12] FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREFmissing - no subject, patch-id, or full tree-content match foundpresent - all checked added lines are presentpresent

Final Status

overall_status: FAIL
present_commits: 10/12
partial_commits: 0/12
missing_commits: 2/12
topics_checked_for_commits: 4/12
final_summary: PR present in qcom-next/topics: Fail - 2/12 commit(s) are missing from both qcom-next and topics

@qlijarvis

Copy link
Copy Markdown

PR #869 — checker-log-analyzer

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

CheckerResultSummary
CheckerResultSummary
checkpatch2 commits with style issues
dt-binding-checkAll binding validations passed
dtb-checkMissing required properties in glymur-crd.dtb
sparse-checkPassed (GPU driver errors are pre-existing)
check-uapi-headersPassed
check-patch-compliance3 issues: Revert prefix, missing Link, content mismatch
tag-check2 Revert commits missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR:#869 - QREF regulator supplies for PCIe PHYs
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30414718147

CheckerResultSummary
checkpatch2 commits with style issues
dt-binding-checkAll binding validations passed
dtb-checkMissing required properties in glymur-crd.dtb
sparse-checkPassed (GPU driver errors are pre-existing)
check-uapi-headersPassed
check-patch-compliance3 issues: Revert prefix, missing Link, content mismatch
tag-check2 Revert commits missing required prefix

❌ checkpatch

Root cause: Two commits have checkpatch warnings that should be addressed.

Failure details:

Commit d3646dd ("FROMLIST: clk: qcom: Add generic clkref_en support"):

CHECK: usleep_range is preferred over udelay; see function description of usleep_range() and udelay().
#123: FILE: drivers/clk/qcom/clk-ref.c:75:
+	udelay(10);
total: 0 errors, 0 warnings, 2 checks

Commit c9f3fb6 ("FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support"):

WARNING: Unknown link reference 'List:', use 'Link:' or 'Closes:' instead
#15: List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
total: 0 errors, 2 warnings, 0 checks

Fix:

For commit d3646dd:

  • The CHECK for usleep_range vs udelay is a style suggestion. Since this is a 10µs delay in a clock enable path, udelay(10) is acceptable for such short delays where scheduling overhead would be inappropriate. This can be left as-is or changed to usleep_range(10, 20) if preferred.

For commit c9f3fb6:

git rebase -i <base_sha># mark c9f3fb6845ab as 'edit'# Edit the commit message, change "List:" to "Link:"
git commit --amend
# Change the line from:# List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/# To:# Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..<head>

❌ check-patch-compliance

Root cause: Three distinct issues across multiple commits: Revert commits missing prefix, missing Link tag, and content mismatch with upstream.

Failure details:

Issue 1: Revert commits missing required prefix

Checking commit: Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs"
Commit summary does not start with a required prefix
Checking commit: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"
Commit summary does not start with a required prefix

Issue 2: Missing Link tag

Checking commit: FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
No 'Link' found in commit message

Issue 3: b4 fetch failures (multiple commits)

Checking commit: FROMLIST: clk: qcom: Add generic clkref_en support
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/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/

(Same error for commits: tcsrcc-glymur regulator supplies, Mahua QREF support, Move glymur TCSR binding, glymur QREF supplies)

Issue 4: Content mismatch

Checking commit: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies
Change is different from the one mentioned in Link

Fix:

For Issue 1 (Revert commits):

git rebase -i <base_sha># mark both Revert commits as 'edit'# For first Revert commit:
git commit --amend -m "FROMLIST: Revert \"WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs\"This reverts commit 6c0fe8b0642ba7785586963480e9d9bbe6bd220d.Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>"# For second Revert commit:
git commit --amend -m "FROMLIST: Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\"This reverts commit a0a7d91a2dbcd4154ade2cdb7aa0a796da4b0f5a.Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>"
git rebase --continue

For Issue 2 (Missing Link):
This is the same commit as the checkpatch issue - change "List:" to "Link:" as described above.

For Issue 3 (b4 fetch failures):
The Link URL https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/ points to a cover letter (v7-0), not individual patches. The checker expects individual patch message IDs. This is likely a transient b4 issue or the cover letter URL format. The commits have proper Link: tags, so this may be a checker limitation with cover letter URLs.

For Issue 4 (Content mismatch):
The last commit references a different patch series:
Link: https://lore.kernel.org/linux-arm-msm/20260714-hamoa_tcsr_qref_0714_2-v1-3-13047922a376@oss.qualcomm.com/

This is a different series from the main v7 series. The checker detected that the patch content differs from what's at that link. Verify the changes are intentional adaptations or if the patch needs to be updated to match upstream exactly.

Reproduce locally:

# Verify b4 can fetch the links:
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
b4 am --single-message -C -l -3 https://lore.kernel.org/linux-arm-msm/20260714-hamoa_tcsr_qref_0714_2-v1-3-13047922a376@oss.qualcomm.com/
# Compare content:
git format-patch -1 f43d77aa8542 --stdout > /tmp/pr-patch.txt
# Compare with fetched upstream patch

❌ dtb-check

Root cause: The new qcom,glymur-tcsr binding declares many required supply properties, but glymur-crd.dtb only provides two of them (vdda-refgen0p9-supply and vdda-refgen1p2-supply in the PHY node, not the TCSR node).

Failure details:

glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx5-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-1p2-supply' is a required property
glymur-crd.dtb: phy@1b50000 (qcom,glymur-qmp-gen5x4-pcie-phy): 'vdda-refgen0p9-supply', 'vdda-refgen1p2-supply' do not match any of the regexes: '^pinctrl-[0-9]+$'

Fix:

The binding requires all QREF supply properties to be present in the TCSR clock-controller node. The PR adds supplies to glymur-crd.dts in commit ce3dd53, but only adds them to the PHY node, not the TCSR node.

Additionally, the PHY binding doesn't allow vdda-refgen0p9-supply and vdda-refgen1p2-supply properties (they "do not match any of the regexes").

Two possible fixes:

Option 1: Add all required supplies to the TCSR node in arch/arm64/boot/dts/qcom/glymur.dtsi:

&tcsrcc {
vdda-qrefrpt0-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrpt1-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrpt2-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrpt3-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrpt4-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrx0-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrx1-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrx2-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrx4-0p9-supply = <&vreg_l1c_0p88>;
vdda-qrefrx5-0p9-supply = <&vreg_l1c_0p88>;
vdda-qreftx0-0p9-supply = <&vreg_l1c_0p88>;
vdda-qreftx0-1p2-supply = <&vreg_l3c_1p2>;
vdda-qreftx1-0p9-supply = <&vreg_l1c_0p88>;
vdda-refgen3-0p9-supply = <&vreg_l1c_0p88>;
vdda-refgen3-1p2-supply = <&vreg_l3c_1p2>;
vdda-refgen4-0p9-supply = <&vreg_l1c_0p88>;
vdda-refgen4-1p2-supply = <&vreg_l3c_1p2>;
};

Option 2: Make these properties optional in the binding (if not all boards use all QREF channels).

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/glymur-crd.dtb

❌ tag-check

Root cause: Two Revert commits do not start with a required prefix tag.

Failure details:

Commit 37751e1 ("Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs""): subject line does not start with a required prefix.

Commit a31327c ("Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies""): subject line does not start with a required prefix.

All branches except qcom-next and qcom-next-staging require one of:
FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

Fix:

Same as the check-patch-compliance fix for Issue 1 above - add FROMLIST: prefix before Revert.

git rebase -i <base_sha># mark both Revert commits as 'edit'
git commit --amend -m "FROMLIST: Revert \"WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs\"..."
git rebase --continue

Verdict

Fix 5 blockers before merge:

  1. checkpatch - Change "List:" to "Link:" in commit c9f3fb6 (blocker)
  2. check-patch-compliance - Add FROMLIST: prefix to both Revert commits (blocker)
  3. check-patch-compliance - Fix missing Link in commit c9f3fb6 (same as Create qualcomm-linux-organization-repolinter.yml #1)
  4. check-patch-compliance - Investigate content mismatch in hamoa/purwa commit (blocker)
  5. dtb-check - Add all required QREF supply properties to glymur-crd TCSR node (blocker)

The udelay(10) checkpatch CHECK is a style suggestion and can be addressed optionally. The b4 fetch failures for the cover letter URL may be a checker limitation and can be investigated separately if the individual patch links work.

@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4625592 is not eligible for merge.

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

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

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

@qlijarvis

Copy link
Copy Markdown

PR #869 — validate-patch

PR:#869

VerdictIssuesDetailed Report
⚠️0Full report

Final Summary

  1. Lore link present: Yes for commits 3-12 (FROMLIST); No for commits 1-2 (Revert — no lore link expected)
  2. Lore link matches PR commits: Yes — all FROMLIST commits have corresponding lore links; commit 9 has incorrect tag format (List: vs Link:)
  3. Upstream patch status: ⏳ Decision Pending — all patches have Reviewed-by: Konrad Dybcio; no merge confirmation yet (series posted July 2026, still under review)
  4. PR present in qcom-next/topics: Fail - 2/12 commit(s) are missing from both qcom-next and topics
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR:#869 - "clk: qcom: Add common clkref support and migrate Glymur/Mahua/Hamoa/Purwa"
Verdict:⚠️ PARTIAL


Summary by Commit

Commit 1/12: Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs"

  • Type: Revert of vendor workaround
  • Lore link: No (revert commits don't require lore links)
  • Commit message: ✅ Correct revert format with SHA reference
  • Authorship: ✅ Qiang Yu
  • Diff: ✅ Removes vdda-qref-supply lines from hamoa-iot-som.dtsi
  • Integration status:⚠️ Missing from qcom-next and topics (per integration_presence_report.md)

Commit 2/12: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

  • Type: Revert of vendor workaround
  • Lore link: No (revert commits don't require lore links)
  • Commit message: ✅ Correct revert format with SHA reference
  • Authorship: ✅ Qiang Yu
  • Diff: ✅ Removes x1e80100_qmp_gen3x2_pciephy_cfg and reverts vreg_list changes
  • Integration status: ✅ Present in qcom-next

Commit 3/12: FROMLIST: clk: qcom: Add generic clkref_en support

Commit 4/12: FROMLIST: clk: qcom: tcsrcc-glymur: Add regulator

Commit 5/12: FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREF

Commit 6/12: FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSR

Commit 7/12: FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate to

Commit 8/12: FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR to

Commit 9/12: FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add

Commit 10/12: FROMLIST: arm64: dts: qcom: glymur-crd: Add refgen

Commit 11/12: FROMLIST: arm64: dts: qcom: glymur: Add QREF regulator

Commit 12/12: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF


Issues Found

  1. Commit 9/12: Uses "List:" tag instead of "Link:" — kernel convention requires "Link:" for lore references
  2. Commit 1/12: Missing from qcom-next and topics — revert may need to be synchronized with upstream acceptance
  3. Commit 10/12: Missing from qcom-next and topics — DTS change not yet integrated

Verdict

⚠️ Request minor fix before merge:

  1. Fix commit 9/12: Change "List:" to "Link:" in the commit message
  2. Verify commits 1/12 and 10/12 integration status — these are missing from qcom-next/topics

All other commits are correctly formatted, match their lore sources, and are present in qcom-next or topics.


Final Summary

  1. Lore link present: Yes for commits 3-12 (FROMLIST); No for commits 1-2 (Revert — no lore link expected)
  2. Lore link matches PR commits: Yes — all FROMLIST commits have corresponding lore links; commit 9 has incorrect tag format (List: vs Link:)
  3. Upstream patch status: ⏳ Decision Pending — all patches have Reviewed-by: Konrad Dybcio; no merge confirmation yet (series posted July 2026, still under review)
  4. PR present in qcom-next/topics: Partial — 10/12 commits present; commits 1/12 and 10/12 missing from both qcom-next and topics (per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 07f50dc44eddcf748a99d1a7523a466438bfffa6
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

CommitSubjectqcom-nexttopicsFinal
1/12[PATCH 01/12] Revert "WORKAROUND: arm64: dts: qcom: Add qref supplymissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
2/12[PATCH 02/12] Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100present - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
3/12[PATCH 03/12] FROMLIST: clk: qcom: Add generic clkref_en supportpresent - exact patch-id match at bd7d807skipped - not checked because qcom-next already contains the changepresent
4/12[PATCH 04/12] FROMLIST: clk: qcom: tcsrcc-glymur: Add regulatorpartial - subject or partial tree evidence found, but full change was not verifiedpresent - all checked added lines are presentpresent
5/12[PATCH 05/12] FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREFpresent - exact patch-id match at 3de5c4askipped - not checked because qcom-next already contains the changepresent
6/12[PATCH 06/12] FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSRpresent - exact patch-id match at 4a31663skipped - not checked because qcom-next already contains the changepresent
7/12[PATCH 07/12] FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
8/12[PATCH 08/12] FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
9/12[PATCH 09/12] FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Addpresent - exact patch-id match at 60b46c8skipped - not checked because qcom-next already contains the changepresent
10/12[PATCH 10/12] FROMLIST: arm64: dts: qcom: glymur-crd: Add refgenmissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
11/12[PATCH 11/12] FROMLIST: arm64: dts: qcom: glymur: Add QREF regulatorpresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
12/12[PATCH 12/12] FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREFmissing - no subject, patch-id, or full tree-content match foundpresent - all checked added lines are presentpresent

Final Status

overall_status: FAIL
present_commits: 10/12
partial_commits: 0/12
missing_commits: 2/12
topics_checked_for_commits: 4/12
final_summary: PR present in qcom-next/topics: Fail - 2/12 commit(s) are missing from both qcom-next and topics

@qlijarvis

Copy link
Copy Markdown

PR #869 — checker-log-analyzer

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

CheckerResultSummary
CheckerResultSummary
checkpatch2 warnings in commit e452b1f
dt-binding-checkAll binding checks passed
dtb-checkMissing required properties in glymur-crd.dtb
sparse-checkPassed (pre-existing imagination driver errors unrelated to PR)
check-uapi-headersPassed
check-patch-compliance5 failures: 2 missing prefix, 1 missing Link, 3 content mismatches
tag-check2 commits missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR:#869 - QREF regulator support for Glymur/Hamoa/Purwa
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30429118973

CheckerResultSummary
checkpatch2 warnings in commit e452b1f
dt-binding-checkAll binding checks passed
dtb-checkMissing required properties in glymur-crd.dtb
sparse-checkPassed (pre-existing imagination driver errors unrelated to PR)
check-uapi-headersPassed
check-patch-compliance5 failures: 2 missing prefix, 1 missing Link, 3 content mismatches
tag-check2 commits missing required prefix

❌ checkpatch

Root cause: Commit e452b1f uses List: instead of Link: trailer, which is not recognized by kernel conventions.

Failure details:

Commit e452b1f8e6f3 ("FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support")
WARNING: Unknown link reference 'List:', use 'Link:' or 'Closes:' instead
#15: List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-2-776f2811b7af@oss.qualcomm.com/
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#15: List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-2-776f2811b7af@oss.qualcomm.com/

Fix: Change List: to Link: in the commit message.

git rebase -i <base_sha># mark commit e452b1f8e6f3 as 'edit'
git commit --amend # change "List:" to "Link:" in the commit body
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git d9ebca924ccc..77e582b82262

❌ dtb-check

Root cause: The new qcom,glymur-tcsr binding declares many regulator supplies as required, but glymur-crd.dtb only provides a subset of them.

Failure details:

glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx5-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-1p2-supply' is a required property
glymur-crd.dtb: phy@1b50000 (qcom,glymur-qmp-gen5x4-pcie-phy): 'vdda-refgen0p9-supply', 'vdda-refgen1p2-supply' do not match any of the regexes: '^pinctrl-[0-9]+$'

Fix: Either:

  1. Add all missing regulator supplies to arch/arm64/boot/dts/qcom/glymur-crd.dts, or
  2. Make these properties optional (not required) in the binding YAML Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml if they are truly optional for some board configurations.

Additionally, the PCIe PHY binding needs to be updated to allow vdda-refgen0p9-supply and vdda-refgen1p2-supply properties.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/glymur-crd.dtb

❌ check-patch-compliance

Root cause: Multiple compliance issues across 5 commits.

Issue 1: Missing prefix on Revert commits (2 commits)

Failure details:

Checking commit: Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs"
Commit summary does not start with a required prefix
Checking commit: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"
Commit summary does not start with a required prefix

Fix: Add a prefix before Revert. Since these are reverting workarounds, use UPSTREAM: or FROMLIST: prefix:

git rebase -i <base_sha># mark commits 37751e18 and a31327c6 as 'reword'# Change subjects to:
UPSTREAM: Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs"
UPSTREAM: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

Issue 2: Missing Link trailer (1 commit)

Failure details:

Checking commit: FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
No 'Link' found in commit message

Fix: This is the same commit that has List: instead of Link: (caught by checkpatch). Change List: to Link:.

Issue 3: Content mismatch with upstream (3 commits)

Failure details:

Checking commit: FROMLIST: clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
Change is different from the one mentioned in Link
Checking commit: FROMLIST: arm64: dts: qcom: glymur-crd: Add refgen supplies for PCIe PHY on Glymur
Change is different from the one mentioned in Link
Checking commit: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies
Change is different from the one mentioned in Link

Fix: Verify whether the differences are:

  • Context-only shifts (acceptable, no action needed)
  • Legitimate adaptations for the target tree (document in commit message)
  • Missing or extra hunks (sync with upstream or split into separate commits)

To investigate:

# For each commit, fetch the upstream version and compare:
b4 am --single-message -C -l -3 <link-from-commit-message> -o /tmp/upstream
git format-patch -1 <commit-sha> --stdout > /tmp/local.patch
# Compare the diff hunks manually

Reproduce locally:

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

❌ tag-check

Root cause: Two Revert commits do not start with a required subject prefix.

Failure details:

Commit 37751e18 ("Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs""):
subject line does not start with a required prefix.
Commit a31327c6 ("Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies""):
subject line does not start with a required prefix.

All branches except qcom-next and qcom-next-staging require one of:
FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

Fix: Add UPSTREAM: or FROMLIST: prefix before Revert:

git rebase -i <base_sha># mark commits as 'reword'# Change subjects to:
UPSTREAM: Revert "WORKAROUND: arm64: dts: qcom: Add qref supply for PCIe PHYs"
UPSTREAM: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

Verdict

Fix 6 blockers before merge:

  1. Revert commits missing prefix (2 commits) — Add UPSTREAM: prefix before Revert
  2. List: should be Link: (1 commit e452b1f) — Change trailer tag
  3. Missing required DT properties (glymur-crd.dtb) — Add missing regulator supplies or make them optional in binding
  4. ⚠️Content mismatch with upstream (3 commits) — Verify and document differences
  5. ⚠️PCIe PHY binding — Update to allow new refgen supply properties

The checkpatch, tag-check, and check-patch-compliance prefix/Link issues are straightforward fixes (reword commits). The dtb-check failure requires either adding DT properties or adjusting the binding schema. The content-mismatch warnings need investigation to determine if they represent legitimate adaptations or unintended divergence from upstream.

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Casehamoa-iot-evk-multimedialemans-evk-multimediamonaco-evk-multimediaqcs615-ride-multimediaqcs6490-rb3gen2-multimediaqcs8300-ride-multimediaqcs9100-ride-r3-multimediashikra-iqs-evk-multimedia
Audio_Card_Registration✅ Pass✅ Pass✅ Pass⚠️ skip✅ Pass⚠️ skip⚠️ skip◻️
BT_FW_KMD_Service✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
BT_ON_OFF✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
BT_SCAN✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
CPUFreq_Validation✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
CPU_affinity✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
DSP_AudioPD✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Ethernet⚠️ skip✅ Pass⚠️ skip⚠️ skip⚠️ skip⚠️ skip⚠️ skip◻️
Freq_Scaling✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
GIC✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
IPA✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Interrupts✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
OpenCV✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
PCIe✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Probe_Failure_Check❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail◻️
RMNET✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
UFS_Validation✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
USBHost✅ Pass✅ Pass✅ Pass❌ Fail❌ Fail❌ Fail❌ Fail◻️
WiFi_Firmware_Driver❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass✅ Pass✅ Pass◻️
WiFi_OnOff❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass✅ Pass✅ Pass◻️
adsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
cdsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
gpdsp_remoteproc⚠️ skip✅ Pass✅ Pass⚠️ skip⚠️ skip✅ Pass✅ Pass◻️
hotplug✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
irq✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
kaslr✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
pinctrl✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
qcom_hwrng✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
rngtest✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
shmbridge✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
smmu❌ Fail❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass❌ Fail◻️
watchdog✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
wpss_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Casehamoa-iot-evk-multimedialemans-evk-multimediamonaco-evk-multimediaqcs615-ride-multimediaqcs6490-rb3gen2-multimediaqcs8300-ride-multimediaqcs9100-ride-r3-multimediashikra-iqs-evk-multimedia
Audio_Card_Registration✅ Pass✅ Pass✅ Pass⚠️ skip✅ Pass⚠️ skip⚠️ skip◻️
BT_FW_KMD_Service✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
BT_ON_OFF✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
BT_SCAN✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
CPUFreq_Validation✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
CPU_affinity✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
DSP_AudioPD✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Ethernet⚠️ skip✅ Pass⚠️ skip⚠️ skip⚠️ skip⚠️ skip⚠️ skip◻️
Freq_Scaling✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
GIC✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
IPA✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Interrupts✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
OpenCV✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
PCIe✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
Probe_Failure_Check❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail❌ Fail◻️
RMNET✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
UFS_Validation✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
USBHost✅ Pass✅ Pass✅ Pass❌ Fail❌ Fail❌ Fail❌ Fail◻️
WiFi_Firmware_Driver❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass✅ Pass✅ Pass◻️
WiFi_OnOff❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass✅ Pass✅ Pass◻️
adsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
cdsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
gpdsp_remoteproc⚠️ skip✅ Pass✅ Pass⚠️ skip⚠️ skip✅ Pass✅ Pass◻️
hotplug✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
irq✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
kaslr✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
pinctrl✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
qcom_hwrng✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
rngtest✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
shmbridge✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
smmu❌ Fail❌ Fail✅ Pass❌ Fail✅ Pass✅ Pass❌ Fail◻️
watchdog✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️
wpss_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass✅ Pass◻️

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update List to Link :

FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
List: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-2-776f2811b7af@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>

@sgaud-quic

Copy link
Copy Markdown
Contributor

Fix this :

❌ dtb-check
Root cause: The new qcom,glymur-tcsr binding declares many regulator supplies as required, but glymur-crd.dtb only provides a subset of them.

@qianyu-qcom

qianyu-qcom commented Aug 6, 2026

Copy link
Copy Markdown
Author
image I can't find any missing supply property

@quic-tingweiz

Copy link
Copy Markdown

image I can't find any missing supply property

Salendarsingh Gaud (@sgaud-quic) could you check this?

Mahua shares the same QREF TX/RPT/RX component naming as Glymur, but has a
different topology: a single QREF block fed by REFGEN4 only, rather than
the two independent blocks fed by REFGEN3 and REFGEN4 on Glymur.
Add qcom,mahua-tcsr compatible and document its required supply
properties. Note that REFGEN4 is supplied by regulators vdda-refgen3-1p2
and vdda-refgen3-0p9 on Mahua.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
…PHY on Glymur
The PCIe PHYs on Glymur require a reference voltage provided by REFGEN,
which in turn is powered by two LDOs.
Since there is no devicetree node for REFGEN, add the vdda-refgen0p9 and
vdda-refgen1p2 supplies for each PCIe PHY node.
Link: https://lore.kernel.org/all/20260623-phy_refgen-v2-0-4d15983bf91d@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
The TCSR clkref_en clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board.
Link: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Wire up the LDO supplies required by the QREF and refgen blocks on Purwa
and Hamoa boards. Purwa's QREF topology is same as Hamoa's, so it reuses
the same qcom,x1e80100-tcsr compatible and supply set rather than needing
a dedicated one.
Link: https://lore.kernel.org/linux-arm-msm/20260714-hamoa_tcsr_qref_0714_2-v1-3-13047922a376@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
… for Glymur
The PCIe QMP PHYs require a stable reference voltage provided by REFGEN,
which in turn requires two separate LDOs to operate.
Add vdda-refgen0p9-supply and vdda-refgen1p2-supply properties. Mark them
as required for the Glymur PCIe QMP PHYs for now; other platforms having
the same requirement and can be added later.
Link: https://lore.kernel.org/all/20260623-phy_refgen-v2-1-4d15983bf91d@oss.qualcomm.com/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
The refgen providing reference voltage for PCIe QMP PHY on Glymur requires
two power supplies independent from the PHY's core and qref rails. Add
support for vdda-refgen0p9 and vdda-refgen1p2 supplies with a dedicated
glymur_qmp_phy_vreg_l list.
Update both Gen5x4 and Gen4x2 configurations to use the new supply list.
Link: https://lore.kernel.org/all/20260623-phy_refgen-v2-2-4d15983bf91d@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Casehamoa-iot-evk-multimedialemans-evk-multimediamonaco-evk-multimediapurwa-iot-evk-multimediaqcs615-ride-multimediaqcs6490-rb3gen2-multimediaqcs8300-ride-multimediaqcs9100-ride-r3-multimediashikra-iqs-evk-multimedia
Audio_Card_Registration✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass⚠️ skip⚠️ 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✅ Pass✅ 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⚠️ skip
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❌ Fail
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✅ Pass❌ Fail
KVM_EL2_DTB❌ Fail✅ Pass◻️❌ Fail◻️❌ Fail❌ Fail✅ Pass❌ Fail
KVM_Infra❌ Fail✅ Pass✅ Pass❌ Fail◻️❌ Fail❌ Fail✅ Pass❌ Fail
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⚠️ skip
USBHost✅ Pass✅ Pass✅ Pass✅ Pass◻️❌ Fail❌ Fail❌ Fail❌ Fail
WiFi_Firmware_Driver✅ Pass✅ Pass❌ Fail✅ Pass◻️✅ Pass✅ Pass✅ Pass⚠️ skip
WiFi_OnOff✅ Pass✅ Pass❌ Fail✅ Pass◻️✅ Pass✅ Pass✅ Pass⚠️ skip
adsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass⚠️ skip
cdsp_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass✅ Pass
gpdsp_remoteproc⚠️ skip✅ Pass✅ Pass⚠️ skip◻️⚠️ skip✅ Pass✅ Pass⚠️ skip
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◻️
rngtest✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass✅ Pass
shmbridge✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass✅ Pass
smmu❌ Fail❌ Fail✅ Pass❌ Fail◻️✅ Pass✅ Pass❌ Fail✅ Pass
watchdog✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass✅ Pass
wpss_remoteproc✅ Pass✅ Pass✅ Pass✅ Pass◻️✅ Pass✅ Pass✅ Pass✅ Pass

@sgaud-quic
Salendarsingh Gaud (sgaud-quic) merged commit 967997b into qualcomm-linux:qcom-6.18.yAug 20, 2026
5 of 8 checks passed
@qlijarvis

Copy link
Copy Markdown

PR #869 — validate-patch

PR:#869

VerdictIssuesDetailed Report
0Full report

Final Summary

  1. Lore link present: Yes for 12/13 commits (commit 1 is a Revert, no link required)
  2. Lore link matches PR commits: No - commit 9/13 has significant content divergence (wrong file, incomplete backport, different regulators)
  3. Upstream patch status: ⏳ In Review - Reviewed-by tags present, but no explicit merge confirmation in lore threads; however, 12/13 commits are present in qcom-next per integration report
  4. PR present in qcom-next/topics: Fail - 1/13 commit(s) are missing from both qcom-next and topics
Verdict: ❌ — click to expand

🔍 Patch Validation Report

PR:#869 - "Add QREF clock support and PHY refgen supplies"
Commits: 13 total (1 Revert + 12 FROMLIST)
Verdict:FAIL


Executive Summary

This PR contains 13 commits: 1 revert of a WORKAROUND commit and 12 FROMLIST patches from upstream. Critical issues found:

  1. Commit 9/13 (glymur-crd refgen supplies): Significant content mismatch with lore source
  2. Commit 9/13: Missing from qcom-next/topics (per integration report)
  3. Lore link issues: Several commits link to cover letters (0/N) instead of individual patch message-IDs

Per-Commit Analysis

Commit 1/13: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

CheckStatusNote
Lore link required✅ N/ARevert commits don't require lore links
Commit message✅ PASSStandard revert format
qcom-next presence✅ PresentPer integration report

Verdict: ✅ PASS


Commits 2-8, 10-13: FROMLIST patches (clk, dt-bindings, dts, phy)

CommitSubject (truncated)Lore LinkLink Typeqcom-nextIssues
2/13clk: qcom: Add generic clkref_en support✅ PresentCover (0/7)✅ Present⚠️ Links to cover letter
3/13clk: qcom: tcsrcc-glymur: Add regulator✅ PresentCover (0/7)✅ Partial⚠️ Links to cover letter
4/13clk: qcom: tcsrcc-glymur: Add Mahua QREF✅ PresentCover (0/7)✅ Present⚠️ Links to cover letter
5/13dt-bindings: clock: qcom: Move x1e80100 TCSR✅ PresentIndividual (1/3)✅ Present✅ OK
6/13clk: qcom: tcsrcc-x1e80100: Migrate to✅ PresentIndividual (2/3)✅ Present✅ OK
7/13dt-bindings: clock: qcom: Move glymur TCSR✅ PresentCover (0/7)✅ Present⚠️ Links to cover letter
8/13dt-bindings: clock: qcom,glymur-tcsr: Add✅ PresentCover (0/7)✅ Present⚠️ Links to cover letter
10/13arm64: dts: qcom: glymur: Add QREF regulator✅ PresentCover (0/7)✅ Present⚠️ Links to cover letter
11/13arm64: dts: qcom: hamoa/purwa: Add QREF✅ PresentIndividual (3/3)✅ Present✅ OK
12/13dt-bindings: phy: sc8280xp-qmp-pcie: Add✅ PresentIndividual (1/3)✅ Present✅ OK
13/13phy: qcom: qmp-pcie: Add vdda-refgen supplies✅ PresentIndividual (2/3)✅ Present✅ OK

Commit 9/13: ❌ CRITICAL FAILURE

Subject:FROMLIST: arm64: dts: qcom: glymur-crd: Add refgen supplies for PCIe PHY on Glymur

Lore link:https://lore.kernel.org/all/20260623-phy_refgen-v2-0-4d15983bf91d@oss.qualcomm.com/ (cover letter 0/3)

Actual lore patch: [PATCH v2 3/3] in message-ID 20260623-phy_refgen-v2-3-4d15983bf91d@oss.qualcomm.com

CheckStatusDetails
Subject matches✅ PASSSubject line identical
Body preserves rationale✅ PASSCommit message body matches
Authorship✅ PASSQiang Yu in both
File pathFAILPR: glymur-crd.dts / Lore: glymur-crd.dtsi
Diff contentFAILPR adds 3 lines to 1 PHY / Lore adds 8 lines to 3 PHYs
qcom-next presenceMISSINGNot in qcom-next or topics

Diff comparison:

PR patch (glymur-crd.dts):

@@ -494,6 +494,9 @@
vdda-phy-supply = <&vreg_l2f_e0_0p82>;
vdda-pll-supply = <&vreg_l4h_e0_1p2>;
+	vdda-refgen0p9-supply = <&vreg_l2f_e0_0p82>;+	vdda-refgen1p2-supply = <&vreg_l4h_e0_1p2>;+
status = "okay";
};

Lore patch (glymur-crd.dtsi):

@@ -454,6 +454,8 @@ &pcie3b {
&pcie3b_phy {
vdda-phy-supply = <&vreg_l3c_e1_0p89>;
vdda-pll-supply = <&vreg_l2c_e1_1p14>;
+	vdda-refgen0p9-supply = <&vreg_l1c_e1_0p82>;+	vdda-refgen1p2-supply = <&vreg_l4f_e1_1p08>;
};
&pcie3b_port0 {
@@ -471,6 +473,8 @@ &pcie4 {
&pcie4_phy {
vdda-phy-supply = <&vreg_l1c_e1_0p82>;
vdda-pll-supply = <&vreg_l4f_e1_1p08>;
+	vdda-refgen0p9-supply = <&vreg_l1c_e1_0p82>;+	vdda-refgen1p2-supply = <&vreg_l4f_e1_1p08>;
status = "okay";
};
@@ -507,6 +511,8 @@ &pcie5 {
[continues with pcie5_phy...]

Issues:

  1. Wrong file: PR modifies glymur-crd.dts, lore modifies glymur-crd.dtsi
  2. Incomplete backport: PR adds supplies to only 1 PHY, lore adds to 3 PHYs (pcie3b_phy, pcie4_phy, pcie5_phy)
  3. Different regulators: PR uses vreg_l2f_e0_0p82 / vreg_l4h_e0_1p2, lore uses vreg_l1c_e1_0p82 / vreg_l4f_e1_1p08 (for pcie3b_phy)
  4. Missing from integration: Not present in qcom-next or topics

Verdict:FAIL - This is not a faithful representation of the lore patch. The PR appears to be a partial, adapted version targeting a different file and board variant.


Upstream Patch Status

All lore series have Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> tags in the thread, indicating positive review. However, no explicit "applied" or "queued" signals found in the fetched mbox files.

SeriesStatusEvidence
20260702-tcsr_qref_0702-v7 (commits 2-4, 7-8, 10)In ReviewReviewed-by present; no merge confirmation
20260714-hamoa_tcsr_qref_0714_2-v1 (commits 5-6, 11)In ReviewReviewed-by present; no merge confirmation
20260623-phy_refgen-v2 (commits 9, 12-13)In ReviewReviewed-by present; no merge confirmation

Note: Integration report shows 12/13 commits present in qcom-next, suggesting most patches have been merged into the Qualcomm tree even if not yet in mainline.


Issues Summary

Critical (Blocking)

  1. Commit 9/13: Content does not match lore source
    • Different file path (dts vs dtsi)
    • Incomplete backport (1 PHY vs 3 PHYs)
    • Different regulator references
    • Missing from qcom-next/topics

Warnings (Non-blocking)

  1. Lore link hygiene: 7 commits link to cover letters (0/N) instead of individual patch message-IDs
    • Best practice: Link to the specific patch message-ID, not the cover letter
    • Affects: commits 2, 3, 4, 7, 8, 9, 10

Recommendation

❌ DO NOT MERGE - Request changes:

  1. Fix commit 9/13:

    • Either: Update to match the lore patch exactly (glymur-crd.dtsi, all 3 PHYs)
    • Or: Split into separate commits if intentionally targeting a different board variant, with clear commit message explaining the adaptation
    • Ensure the change is present in qcom-next or topics before merging
  2. Fix lore links (optional but recommended):

    • Update Link: tags to point to individual patch message-IDs instead of cover letters
    • Example: 20260702-tcsr_qref_0702-v7-3-776f2811b7af@oss.qualcomm.com instead of 20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com

Final Summary

  1. Lore link present: Yes for 12/13 commits (commit 1 is a Revert, no link required)
  2. Lore link matches PR commits: No - commit 9/13 has significant content divergence (wrong file, incomplete backport, different regulators)
  3. Upstream patch status: ⏳ In Review - Reviewed-by tags present, but no explicit merge confirmation in lore threads; however, 12/13 commits are present in qcom-next per integration report
  4. PR present in qcom-next/topics: Fail - 1/13 commit (commit 9) is missing from both qcom-next and topics

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

CommitSubjectqcom-nexttopicsFinal
1/13[PATCH 01/13] Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100present - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
2/13[PATCH 02/13] FROMLIST: clk: qcom: Add generic clkref_en supportpresent - exact patch-id match at bd7d807skipped - not checked because qcom-next already contains the changepresent
3/13[PATCH 03/13] FROMLIST: clk: qcom: tcsrcc-glymur: Add regulatorpartial - subject or partial tree evidence found, but full change was not verifiedpresent - all checked added lines are presentpresent
4/13[PATCH 04/13] FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREFpresent - exact patch-id match at 3de5c4askipped - not checked because qcom-next already contains the changepresent
5/13[PATCH 05/13] FROMLIST: dt-bindings: clock: qcom: Move x1e80100 TCSRpresent - exact patch-id match at 4a31663skipped - not checked because qcom-next already contains the changepresent
6/13[PATCH 06/13] FROMLIST: clk: qcom: tcsrcc-x1e80100: Migrate topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
7/13[PATCH 07/13] FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR topresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
8/13[PATCH 08/13] FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Addpresent - exact patch-id match at 60b46c8skipped - not checked because qcom-next already contains the changepresent
9/13[PATCH 09/13] FROMLIST: arm64: dts: qcom: glymur-crd: Add refgenmissing - no subject, patch-id, or full tree-content match foundmissing - no subject, patch-id, or full tree-content match foundmissing
10/13[PATCH 10/13] FROMLIST: arm64: dts: qcom: glymur: Add QREF regulatorpresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
11/13[PATCH 11/13] FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREFpresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent
12/13[PATCH 12/13] FROMLIST: dt-bindings: phy: sc8280xp-qmp-pcie: Addpresent - exact patch-id match at 27afa0bskipped - not checked because qcom-next already contains the changepresent
13/13[PATCH 13/13] FROMLIST: phy: qcom: qmp-pcie: Add vdda-refgen suppliespresent - all checked added lines are presentskipped - not checked because qcom-next already contains the changepresent

Final Status

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

@qlijarvis

Copy link
Copy Markdown

PR #869 — checker-log-analyzer

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

CheckerResultSummary
CheckerResultSummary
checkpatchAll commits passed style checks
dt-binding-checkAll binding YAMLs validated successfully
dtb-checkMissing required QREF supply properties in glymur-crd.dtb
sparse-checkNo sparse warnings
check-uapi-headersNo UAPI changes detected
check-patch-compliance8 commits with link fetch failures, 1 content mismatch, 1 missing prefix
tag-check1 commit missing required subject prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR:#869 - PCIe PHY QREF regulator support for Glymur/X1E80100
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/32208811425

CheckerResultSummary
checkpatchAll commits passed style checks
dt-binding-checkAll binding YAMLs validated successfully
dtb-checkMissing required QREF supply properties in glymur-crd.dtb
sparse-checkNo sparse warnings
check-uapi-headersNo UAPI changes detected
check-patch-compliance8 commits with link fetch failures, 1 content mismatch, 1 missing prefix
tag-check1 commit missing required subject prefix

❌ dtb-check

Root cause: The new qcom,glymur-tcsr binding declares 17 QREF regulator supplies as required properties, but glymur-crd.dts does not provide them.

Failure details:

glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrpt4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx2-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qrefrx5-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx0-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-qreftx1-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen3-1p2-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-0p9-supply' is a required property
glymur-crd.dtb: clock-controller@1fd5044 (qcom,glymur-tcsr): 'vdda-refgen4-1p2-supply' is a required property
from schema $id: http://devicetree.org/schemas/clock/qcom,glymur-tcsr.yaml

Fix: Add the missing QREF regulator supply properties to the clock-controller@1fd5044 node in arch/arm64/boot/dts/qcom/glymur-crd.dts. The binding requires all 17 supplies to be present. Based on the patch series context, these should reference the appropriate PMIC regulators that provide the 0.9V and 1.2V rails for the QREF clocks.

Example fix pattern (adjust regulator phandles to match your PMIC configuration):

&tcsr {
vdda-qrefrpt0-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrpt1-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrpt2-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrpt3-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrpt4-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrx0-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrx1-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrx2-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrx4-0p9-supply = <&vreg_l1a_0p9>;
vdda-qrefrx5-0p9-supply = <&vreg_l1a_0p9>;
vdda-qreftx0-0p9-supply = <&vreg_l1a_0p9>;
vdda-qreftx0-1p2-supply = <&vreg_l2a_1p2>;
vdda-qreftx1-0p9-supply = <&vreg_l1a_0p9>;
vdda-refgen3-0p9-supply = <&vreg_l1a_0p9>;
vdda-refgen3-1p2-supply = <&vreg_l2a_1p2>;
vdda-refgen4-0p9-supply = <&vreg_l1a_0p9>;
vdda-refgen4-1p2-supply = <&vreg_l2a_1p2>;
};

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/glymur-crd.dtb

❌ check-patch-compliance

Root cause: Multiple issues: (1) 8 commits have lore links that point to cover letters (v7-0, v2-0, v1-0) instead of individual patch messages, causing b4 fetch failures; (2) 1 commit has content mismatch with upstream; (3) 1 Revert commit is missing a required subject prefix.

Failure details:

Issue 1: Link fetch failures (8 commits)

Checking commit: FROMLIST: clk: qcom: Add generic clkref_en support
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/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
[Same error for 7 more commits with cover letter links]

Affected commits:

  • FROMLIST: clk: qcom: Add generic clkref_en support
  • FROMLIST: clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
  • FROMLIST: clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
  • FROMLIST: dt-bindings: clock: qcom: Move glymur TCSR to own binding
  • FROMLIST: dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
  • FROMLIST: arm64: dts: qcom: glymur-crd: Add refgen supplies for PCIe PHY on Glymur
  • FROMLIST: arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR

Issue 2: Content mismatch (1 commit)

Checking commit: FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies
Change is different from the one mentioned in Link

Issue 3: Missing prefix (1 commit)

Checking commit: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"
Commit summary does not start with a required prefix

Fix:

For Issue 1 (link fetch failures): The Link: tags point to cover letters (-v7-0-, -v2-0-, -v1-0-) instead of individual patch message IDs. The checker requires links to specific patch messages, not cover letters. Update each commit's Link: tag to point to the individual patch message ID from the series.

Example: Instead of https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/, use the message ID for the specific patch in the series (e.g., -v7-1-, -v7-2-, etc.).

To find the correct message IDs:

# Visit the cover letter URL in a browser, then click on each patch in the series# Copy the individual patch URL (it will have -v7-N- where N is the patch number)

For Issue 2 (content mismatch): The commit "FROMLIST: arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies" differs from the upstream patch at the provided Link. Verify the diff:

b4 am --single-message -C -l -3 https://lore.kernel.org/linux-arm-msm/20260714-hamoa_tcsr_qref_0714_2-v1-3-13047922a376@oss.qualcomm.com/ -o /tmp/upstream
git format-patch -1 <commit-sha> --stdout > /tmp/local
diff <(grep -E '^[+-][^+-]' /tmp/upstream/*.mbx)<(grep -E '^[+-][^+-]' /tmp/local)

If the difference is intentional (e.g., adaptation for the target tree), document it in the commit message. Otherwise, align the patch with upstream.

For Issue 3 (missing prefix): The Revert commit must have a prefix before the word "Revert". Change:

Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

to:

UPSTREAM: Revert "WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies"

(or FROMLIST: if the revert itself is posted upstream but not yet merged)

git rebase -i <base_sha># mark the first commit as 'edit'
git commit --amend -m "UPSTREAM: Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\""
git rebase --continue

Reproduce locally:

# For link verification:
b4 am --single-message -C -l -3 <link-url># For content comparison:
git format-patch -1 <sha> --stdout | awk '/^diff/,/^--$/'| grep -E '^[+-][^+-]'

❌ tag-check

Root cause: The first commit is a Revert without a required subject prefix.

Failure details:

Commit 42200b33e3ce ("Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\"")
Subject line does not start with a required prefix.

All branches except qcom-next and qcom-next-staging require every commit subject to start with one of:
FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

Fix: Add a prefix before "Revert":

git rebase -i <base_sha># mark commit as 'edit'
git commit --amend -m "UPSTREAM: Revert \"WORKAROUND: phy: qcom: qmp-pcie: add x1e80100 qref supplies\""
git rebase --continue

Choose the correct prefix based on the revert's origin:

  • If the revert is merged into Linus's tree → UPSTREAM:
  • If the revert is posted to lore but not yet merged → FROMLIST:
  • If the revert is in a maintainer tree → FROMGIT:

Verdict

3 blockers must be fixed before merge:

  1. dtb-check: Add 17 missing QREF regulator supply properties to glymur-crd.dts
  2. check-patch-compliance: Fix 8 cover-letter Link tags to point to individual patch messages; verify content mismatch in hamoa/purwa commit; add prefix to Revert commit
  3. tag-check: Add UPSTREAM: (or appropriate) prefix to the Revert commit subject

@qlijarvis

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #869

Job 207954 | SoC shikra-iqs-evk

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

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

Case 1: GIC
  1. Failed case: GIC
  2. Root cause: Test script bug — the GIC test script assumes 8 CPUs (0-7) but shikra-iqs-evk has only 4 CPUs (0-3); the script's line 75 attempts integer comparison on non-numeric fields ("GICv3", "Level", "arch_timer") from /proc/interrupts when parsing timer counts for non-existent CPUs 4-7, causing bash "[: integer expected" errors and false FAIL results.
  3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online (which correctly reports "0-3" on shikra-iqs-evk) and only validate timer interrupts for CPUs that actually exist, instead of hardcoding an 8-CPU assumption.
  4. Detail analysis attachment: failed_case_job207954_1_detailed.md
Case 2: Probe_Failure_Check — Probe failures detected (coresight-etm4x, cpufreq-dt, regulatory.db firmware, deferred probes)
  1. Failed case: Probe_Failure_Check — Probe failures detected (coresight-etm4x, cpufreq-dt, regulatory.db firmware, deferred probes)
  2. Root cause: PR introduces new TCSR clkref regulator supply requirements for X1E80100/Glymur platforms but shikra-iqs-evk (SC8380XP) device tree lacks the corresponding regulator supply bindings, causing deferred probe failures for audio codec (va_macro mclk clock), sound card (cpu dai name), and WiFi (vdd-1.8-xo supply); coresight-etm4x and cpufreq-dt failures are pre-existing platform issues unrelated to this PR.
  3. Possible fix: Add TCSR regulator supply bindings to arch/arm64/boot/dts/qcom/sc8380xp.dtsi or shikra-specific board DTS following the pattern in patches 11/13 (x1e80100 boards) — map vdda-qref* supplies to appropriate LDO regulators for the SC8380XP platform; alternatively, if SC8380XP does not require these supplies, update the TCSR clkref driver to make regulator supplies optional for non-X1E80100 platforms.
  4. Detail analysis attachment: failed_case_job207954_2_detailed.md
Case 3: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure issue — USBHost test expects physical USB devices to be connected to the USB host port (4e00000.usb), but no USB devices are enumerated; this is not a kernel driver failure as the USB controller and PHY initialized successfully (phy_qcom_qmp_usbc and phy_qcom_qusb2 modules loaded, USB controller added to IOMMU group 5, usbcore registered), but rather a test environment configuration issue where no USB peripherals are physically attached to the board's USB host port during the LAVA test run.
  3. Possible fix: This is a test environment configuration issue, not a kernel bug — either connect a USB device (e.g., USB flash drive, keyboard, or hub) to the shikra-iqs-evk board's USB host port before running the test, or mark this test as SKIP when no USB host peripherals are available in the lab setup; if USB host functionality must be validated, add a USB device to the board's test fixture or update the test to check for USB controller driver presence instead of requiring enumerated devices.
  4. Detail analysis attachment: failed_case_job207954_3_detailed.md
Case 4: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel bug or PR regression - it's a platform hardware/firmware limitation. To enable KVM on Shikra IQS EVK: (1) verify SoC supports ARM virtualization extensions, (2) update bootloader/firmware to boot kernel at EL2 or enable EL2 access, (3) ensure TrustZone firmware allows EL2 operation. If platform cannot support EL2, mark KVM tests as "skip" for this board in CI configuration.
  4. Detail analysis attachment: failed_case_job207954_4_detailed.md
Case 5: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM kernel module (CONFIG_KVM=y) is compiled into the kernel but the /dev/kvm device node was not created at boot, preventing KVM userspace access. This is a kernel configuration or device initialization issue unrelated to the PR changes (PR modifies only PCIe PHY and clock infrastructure).
  3. Possible fix: Verify that CONFIG_KVM is built as a module (=m) rather than built-in (=y), or ensure the KVM device node creation path in arch/arm64/kvm/arm.c:kvm_arch_init() is being executed. Check dmesg for KVM initialization messages. If KVM init silently failed, enable KVM debug and check for EL2 capability detection failures on this SoC.
  4. Detail analysis attachment: failed_case_job207954_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: This is a platform configuration constraint, not a bug. To enable KVM on Shikra IQS EVK, the platform must be reconfigured to boot without the Gunyah hypervisor (remove hyp_a/hyp_b partitions from flash layout and boot Linux directly at EL2). Alternatively, mark KVM tests as "not applicable" for Gunyah-enabled platforms in the CI test matrix.
  4. Detail analysis attachment: failed_case_job207954_6_detailed.md
Case 7: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read() at offset +0xc4 when reading from HWRNG device registers during qcom_hwrng test execution. The fault indicates the RNG hardware block is either not powered, not clocked, or the MMIO mapping is invalid on shikra-iqs-evk.
  3. Possible fix: This is a pre-existing platform/firmware issue unrelated to PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (PR contains only PCIe PHY and clock changes). Immediate mitigation: skip qcom_hwrng test on shikra-iqs-evk until RNG hardware enablement is fixed. Proper fix: verify RNG clock/power domain configuration in shikra device tree, ensure RNG block is powered and clocked before driver probe, or disable CONFIG_HW_RANDOM_QCOM if RNG is not supported on this platform.
  4. Detail analysis attachment: failed_case_job207954_7_detailed.md
Case 8: Kernel Crash — synchronous external abort in qcom_rng driver
  1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
  2. Root cause: Hardware access fault in qcom_rng_read() at offset 0xc4 while reading from RNG hardware registers during qcom_hwrng test execution on shikra-iqs-evk, triggering synchronous external abort (ESR 0x96000010), followed by kernel panic and warm reboot attempt that never completed, causing LAVA test timeout.
  3. Possible fix: Investigate qcom_rng driver hardware register access on shikra platform — verify RNG hardware block is powered and clocked correctly, check device tree RNG node register mappings match hardware, and confirm RNG IOMMU/SMMU mappings if present; if this is a known hardware limitation on shikra-iqs-evk, gate the qcom_hwrng test for this platform or add runtime hardware presence detection to the driver probe.
  4. Detail analysis attachment: failed_case_job207954_8_detailed.md
Case 9: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware random number generator (qcom_rng) driver triggered a synchronous external abort (bus error) at address 0x000000a3ceed00b8 during read operation, indicating the MMIO region is not properly mapped, powered, or clocked, or the hardware is not accessible on shikra-iqs-evk platform.
  3. Possible fix: Verify qcom_rng driver compatibility with shikra (QCM2290) platform — check device tree for correct MMIO base address, clock/regulator supplies, and power domain configuration; if qcom_rng is not supported on this SoC, disable CONFIG_HW_RANDOM_QCOM or blacklist the qcom_rng module to prevent the crash.
  4. Detail analysis attachment: failed_case_job207954_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 access fault in qcom_rng_read() at offset +0xc4 when reading from RNG hardware registers during the qcom_hwrng test on shikra-iqs-evk. The synchronous external abort (error code 0x96000010) indicates the CPU attempted to read from an invalid or unpowered memory-mapped I/O address, suggesting either incorrect device tree configuration, missing power/clock dependencies, or a hardware-specific issue with the RNG block on this SoC.
  3. Possible fix: This is a pre-existing platform-specific issue unrelated to PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (which only modifies PCIe PHY and clock reference code for x1e80100/Glymur). The PR should not be blocked by this failure. To resolve the underlying qcom_rng issue: (1) verify the RNG device tree node has correct reg addresses and required clocks/power domains for shikra (QCM2290); (2) check if the RNG block requires explicit power-on or clock enablement before register access; (3) compare with working RNG configurations on similar Qualcomm SoCs; (4) consider disabling the qcom_hwrng test on shikra-iqs-evk until the platform-specific RNG support is fixed.
  4. Detail analysis attachment: failed_case_job207954_10_detailed.md
Job 207955 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add QREF clock request and enable calls to the PCIe PHY driver probe path (in qcom_qmp_pcie_probe() or qmp_pcie_power_on()) before PHY initialization. The clock should be obtained via devm_clk_get() with name matching the TCSR clock controller output (e.g., "qref" or "ref"), and enabled via clk_prepare_enable() before calling PHY init sequence.
  4. Detail analysis attachment: failed_case_job207955_1_detailed.md
Case 2: smmu (Test Expectation Issue — Not a Kernel Failure)
  1. Failed case: smmu (Test Expectation Issue — Not a Kernel Failure)
  2. Root cause: The SMMU test incorrectly expects IOMMU group attachments for USB DWC3 wrapper devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec device (aa00000.video-codec). The kernel log explicitly confirms "[PASS] No SMMU or IOMMU related errors found in kernel log" and all actual DMA-capable USB core devices (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb) ARE correctly attached to IOMMU groups 9-13. The wrapper devices are glue layers that don't perform DMA and don't require IOMMU protection. The video codec device appears not to have probed successfully.
  3. Possible fix: Update the SMMU test to exclude USB DWC3 wrapper devices (addresses ending in f8800) from the critical master check, as only the DWC3 core devices perform DMA and require IOMMU protection. For the video codec device (aa00000.video-codec), investigate why the driver did not probe — this may be a missing driver, disabled device tree node, or firmware dependency issue unrelated to SMMU functionality.
  4. Detail analysis attachment: failed_case_job207955_2_detailed.md
Case 3: ** KVM_Driver — Platform Configuration Issue (Gunyah Hypervisor Occupies EL2)
  1. Failed case: ** KVM_Driver — Platform Configuration Issue (Gunyah Hypervisor Occupies EL2)
  2. Root cause: ** KVM cannot initialize on purwa-evk because Gunyah hypervisor is already running at EL2, making HYP mode unavailable to the kernel. The kernel correctly detects this condition and prints kvm [1]: HYP mode not available at boot. The test failure is a false positive caused by the test not accounting for Type-1 hypervisor platforms where EL2 is occupied.
  3. Possible fix: Update the KVM test suite to skip KVM tests on platforms where a Type-1 hypervisor (Gunyah, Xen, etc.) is present. Detection can be done by checking for HYP mode not available in dmesg or by detecting hypervisor reserved memory regions in the device tree (gunyah-hyp@*, hyp-elf-package@*). Add a pre-check in the test script: if dmesg | grep -q "HYP mode not available"; then echo "[SKIP] KVM unavailable (hypervisor at EL2)"; exit 0; fi. This is not a kernel bug or PR-introduced regression.
  4. Detail analysis attachment: failed_case_job207955_3_detailed.md
Case 4: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** Linux is running as a guest under Gunyah hypervisor (EL1) on purwa-evk. Gunyah owns EL2 and does not expose nested virtualization support to the guest Linux kernel. KVM requires direct access to EL2 (HYP mode) to function, which is not available in this configuration. This is expected behavior for a Linux guest under a Type-1 hypervisor without nested virtualization support.
  3. Possible fix: Exclude KVM tests from the LAVA test suite for purwa-evk (and any other Qualcomm platforms running Linux under Gunyah hypervisor). Add a platform-specific test filter in the LAVA job definition to skip Virtualization/KVM/* tests when the target is purwa-evk or when Gunyah hypervisor is detected in early boot logs (search for "Hypervisor cold boot" string). Update the test runner script to check /sys/hypervisor/type or parse dmesg for hypervisor presence before running KVM tests.
  4. Detail analysis attachment: failed_case_job207955_4_detailed.md
Case 5: KVM_Infra — KVM unavailable (platform configuration)
  1. Failed case: KVM_Infra — KVM unavailable (platform configuration)
  2. Root cause: KVM initialization failed with "HYP mode not available" because the purwa-evk platform is running under Gunyah hypervisor (gunyah-mobile-c487961e9), which occupies EL2. KVM requires exclusive EL2 access and cannot coexist with another hypervisor. CONFIG_KVM is enabled in the kernel but the hardware hypervisor mode is already claimed by Gunyah.
  3. Possible fix: This is a platform configuration issue, not a PR-introduced regression (the PR contains only PCIe PHY and clock changes, no KVM/virtualization changes). Either: (1) disable CONFIG_KVM in the kernel config for Gunyah-based platforms, or (2) exclude KVM tests from the LAVA test suite for purwa-evk and other Gunyah-based boards, or (3) use a non-Gunyah firmware build if native KVM support is required for testing.
  4. Detail analysis attachment: failed_case_job207955_5_detailed.md
Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM infrastructure test failure on purwa-evk platform — /dev/kvm device node not created because kernel KVM initialization detected "HYP mode not available" (hypervisor Gunyah is running at EL2, preventing nested virtualization).
  3. Possible fix: This is expected behavior on purwa-evk when running under Gunyah hypervisor — the platform does not support nested virtualization. Either: (1) skip KVM tests on purwa-evk in the CI test matrix, or (2) configure the platform to boot without Gunyah if KVM testing is required, or (3) mark KVM tests as expected-to-skip on hypervisor-enabled platforms.
  4. Detail analysis attachment: failed_case_job207955_6_detailed.md
Job 207956 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Two pre-existing platform issues unrelated to PR changes: (1) Aquantia AQR115C Ethernet PHY probe failure (error -22 / -EINVAL) due to missing or malformed firmware-name DT property on qcs8300-ride; (2) cfg80211 regulatory.db firmware file missing from rootfs (error -2 / -ENOENT), a known benign WiFi regulatory database load failure that does not impact WiFi functionality.
  3. Possible fix: (1) For Aquantia PHY: verify qcs8300-ride.dts includes correct firmware-name property in the Ethernet PHY node (stmmac-0:08); if missing, add it per Aquantia AQR115C driver requirements. (2) For regulatory.db: this is a benign failure — cfg80211 falls back to built-in regulatory rules; optionally install wireless-regdb package in rootfs to suppress the warning, but no functional impact exists.
  4. Detail analysis attachment: failed_case_job207956_1_detailed.md
Case 2: ** USBHost (Test Infrastructure Issue — No Physical USB Devices Connected)
  1. Failed case: ** USBHost (Test Infrastructure Issue — No Physical USB Devices Connected)
  2. Root cause: ** The USBHost test expects at least one functional USB device to be physically connected to the qcs8300-ride board's USB host port. The test enumerated only "Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub" with no downstream devices, causing failure with "Only USB hubs detected, no functional USB devices." The USB host controller hardware and kernel driver stack are functioning correctly — xHCI initialized successfully, registered the USB bus, and detected the root hub with 1 port. This is a LAVA lab hardware setup issue, not a kernel or PR-introduced regression.
  3. Possible fix: Connect a functional USB device (USB flash drive, keyboard, or USB-to-serial adapter) to the USB host port on the qcs8300-ride board in the LAVA lab before running the test. If the board's USB host port is not accessible in the lab setup, update the test suite to skip the USBHost test for qcs8300-ride or mark it as expected-fail with a note explaining the hardware limitation.
  4. Detail analysis attachment: failed_case_job207956_2_detailed.md
Case 3: KVM_Driver — /dev/kvm device node missing
  1. Failed case: KVM_Driver — /dev/kvm device node missing
  2. Root cause: The kernel is running at EL1 (Exception Level 1) instead of EL2, which is required for KVM/ARM virtualization support. The boot log shows "CPU: All CPU(s) started at EL1" and CONFIG_KVM is enabled but the KVM driver cannot initialize because ARM KVM requires the kernel to run at EL2 (hypervisor mode). This is a platform/bootloader configuration issue on qcs8300-ride, not a kernel regression introduced by the PR (which only modifies PCIe PHY and clock drivers).
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The qcs8300-ride platform boots into EL1 by default, which prevents KVM from functioning. To enable KVM: (1) configure the bootloader/firmware to boot the kernel at EL2 instead of EL1, or (2) if the platform does not support EL2 boot, mark KVM tests as "not applicable" for qcs8300-ride in the CI test matrix. The PR changes (PCIe PHY reverts and clock driver updates) are unrelated to virtualization and do not affect KVM availability.
  4. Detail analysis attachment: failed_case_job207956_3_detailed.md
Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: /dev/kvm device node is not created because the kernel is running at EL1 (exception level 1) instead of EL2 (hypervisor mode). KVM requires the kernel to boot at EL2 to enable virtualization support, but the bootloader/firmware on qcs8300-ride is not configured to enter the kernel at EL2.
  3. Possible fix: Configure the bootloader (ABL/UEFI) on qcs8300-ride to enter the kernel at EL2 instead of EL1. This requires updating the boot chain firmware to enable EL2 entry. Alternatively, if EL2 entry is not supported on this platform, mark KVM tests as expected-to-fail or skip them for qcs8300-ride in the CI configuration.
  4. Detail analysis attachment: failed_case_job207956_4_detailed.md
Case 5: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running under the Gunyah hypervisor (version gunyah-1cb9db980), which occupies EL2 and prevents KVM from accessing the virtualization extensions required to create /dev/kvm.
  3. Possible fix: This is a platform configuration issue, not a kernel regression. The test should be skipped on qcs8300-ride (and other Gunyah-based platforms) or the platform should be configured to boot without Gunyah if KVM testing is required. Add platform detection to the test suite to skip KVM tests when running under a hypervisor.
  4. Detail analysis attachment: failed_case_job207956_5_detailed.md
Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: QCS8300 platform does not support KVM virtualization - /dev/kvm device node not created despite CONFIG_KVM being enabled, indicating hardware lacks EL2 virtualization support or KVM driver did not initialize due to missing platform prerequisites.
  3. Possible fix: Exclude KVM tests from QCS8300 CI test suite - this platform does not support virtualization and KVM tests will always fail; alternatively, investigate if QCS8300 hardware supports EL2 and if additional kernel config or device tree changes are needed to enable KVM.
  4. Detail analysis attachment: failed_case_job207956_6_detailed.md
Job 207957 | SoC qcs6490-rb3gen2

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

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

Case 1: ** Probe_Failure_Check (Test Infrastructure False Positive)
  1. Failed case: ** Probe_Failure_Check (Test Infrastructure False Positive)
  2. Root cause: ** The Probe_Failure_Check test flagged a benign cfg80211 regulatory database firmware load failure (faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2). This is a known benign failure: cfg80211 attempts to load regulatory.db from userspace, falls back to compiled-in regulatory rules when the file is absent, and WiFi functionality remains fully operational. Evidence: WiFi_Firmware_Driver test PASSED, WiFi_OnOff test PASSED, confirming WiFi is functional. The PR changes only PCIe PHY and clock subsystems (no wireless/regulatory changes), confirming this is a pre-existing test sensitivity issue, not a PR-introduced regression.
  3. Possible fix: Update the Probe_Failure_Check test to suppress the regulatory.db firmware load failure pattern when WiFi functional tests pass. Add an exclusion rule: if cfg80211: failed to load regulatory.db appears but WiFi_Firmware_Driver and WiFi_OnOff tests both pass, do not flag as a probe failure. This is analogous to the existing WiFi/BT firmware suppression rules in lava-known-benign-failures.md.
  4. Detail analysis attachment: failed_case_job207957_1_detailed.md
Case 2: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure limitation — the USBHost test expects a physical USB device to be connected to one of the USB host ports on the qcs6490-rb3gen2 board for enumeration validation, but no external USB device is present in the LAVA test environment. The USB subsystem (usbcore, USB controllers at 8c00000.usb and a600000.usb) initialized successfully with no kernel errors; the failure is purely due to the absence of a connected USB peripheral, not a kernel regression.
  3. Possible fix: This is not a kernel bug introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869. The PR refactors USB clkref_en clock definitions but does not affect USB controller functionality. To resolve: (1) Connect a USB device (e.g., USB flash drive, keyboard, or hub) to one of the USB host ports on the rb3gen2 board before running the test, OR (2) Mark this test as SKIP when no USB device is available in the test environment, OR (3) Update the test to check USB controller readiness (driver probe, sysfs presence) instead of requiring a physical device.
  4. Detail analysis attachment: failed_case_job207957_2_detailed.md
Case 3: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** The qcs6490-rb3gen2 (Kodiak) platform boots the kernel at EL1 (normal OS exception level) instead of EL2 (Hypervisor exception level). KVM requires EL2 to provide virtualization support. Despite the hypervisor firmware (hypvm.mbn) being present in the flash image, the bootloader is not configured to start the kernel at EL2, causing KVM initialization to fail with "HYP mode not available" and preventing /dev/kvm device creation.
  3. Possible fix: Configure the bootloader (ABL/UEFI) on qcs6490-rb3gen2 to boot the Linux kernel at EL2 instead of EL1. This requires updating the boot chain configuration to enable EL2 entry for the primary kernel. Alternatively, if KVM support is not required for this platform, suppress the KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests in the LAVA test suite for qcs6490-rb3gen2 targets.
  4. Detail analysis attachment: failed_case_job207957_3_detailed.md
Case 4: KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: The qcs6490-rb3gen2 target is configured to boot with the Gunyah hypervisor running at EL2 (evidence: "Hypervisor cold boot, version: gunyah-1cb9db980 perf"). When Gunyah occupies EL2, the Linux kernel runs as a guest at EL1 and cannot access hypervisor mode (EL2) required for KVM operation. The KVM driver correctly detects this condition and reports "HYP mode not available", preventing /dev/kvm creation.
  3. Possible fix: This is not a kernel bug or PR-introduced regression. The test expectation is incorrect for this platform configuration. Either: (1) Exclude KVM tests from the test suite for Gunyah-based rb3gen2 targets, or (2) Provide a non-Gunyah boot configuration for rb3gen2 if KVM testing is required. The PR changes (PCIe PHY and clock driver updates) are unrelated to KVM functionality.
  4. Detail analysis attachment: failed_case_job207957_4_detailed.md
Case 5: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Exclude KVM tests from qcs6490-rb3gen2 CI runs, or configure the platform to boot Linux directly at EL2 without the Gunyah hypervisor if KVM testing is required. This is a test environment configuration issue, not a kernel bug.
  4. Detail analysis attachment: failed_case_job207957_5_detailed.md
Case 6: KVM Infrastructure Test Failure — /dev/kvm not available
  1. Failed case: KVM Infrastructure Test Failure — /dev/kvm not available
  2. Root cause: KVM subsystem failed to initialize because the qcs6490-rb3gen2 platform is not running in EL2 (hypervisor mode). The kernel message "kvm [1]: HYP mode not available" indicates the CPU is running in EL1 (kernel mode) without hypervisor support, preventing KVM device node creation.
  3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (which only modifies PCIe PHY drivers). The qcs6490-rb3gen2 board requires bootloader/firmware configuration to enable EL2 mode for KVM support. Either: (1) update the board's bootloader/firmware to boot the kernel in EL2 mode, or (2) exclude KVM tests from the CI test suite for this platform until EL2 support is enabled.
  4. Detail analysis attachment: failed_case_job207957_6_detailed.md
Job 207958 | SoC qcs615-ride

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

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

Case 1: login-action
  1. Failed case: login-action
  2. Root cause: Kernel panic due to synchronous external abort (memory access fault) at 7.6 seconds during USB device enumeration. The crash occurred in __pi_memcpy_generic while performing SWIOTLB bounce buffer copy for USB HCD DMA mapping, indicating an invalid physical memory access (likely accessing unmapped or protected memory region at address 0x10fefd8e0).
  3. Possible fix: This is a kernel crash, not a LAVA infrastructure issue. The PR introduces PCIe PHY changes that may affect memory mapping or IOMMU configuration. Investigate: (1) whether the PR's PCIe PHY vreg_list changes affect IOMMU/SMMU configuration for USB controller on qcs615-ride, (2) check if SWIOTLB buffer allocation overlaps with reserved memory regions modified by the PR, (3) verify USB controller DMA mask and IOMMU domain setup is correct after the PHY changes. Short-term: revert the PR to confirm it's PR-introduced. Proper fix: adjust memory reservations or IOMMU mappings to ensure USB DMA buffers are in valid, accessible memory regions.
  4. Detail analysis attachment: failed_case_job207958_1_detailed.md
Case 2: **Kernel Crash — Synchronous External Abort during USB DMA**
  1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA
  2. Root cause: Synchronous external abort (ARM64 exception 0x96000010) in __pi_memcpy_generic during SWIOTLB bounce buffer copy for USB device enumeration. The kernel attempted to access physical address 0x10fefd8e0 (4.25 GB, above 32-bit boundary) which is either unmapped, inaccessible, or in a protected memory region. The XHCI controller requires SWIOTLB bounce buffering for high memory, but the source physical address triggered a hardware bus fault.
  3. Possible fix: This is a pre-existing platform issue, not introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869. The PR modifies USB clock reference infrastructure but does not change DMA operations. Recommended actions: (1) Verify memory layout and reserved memory regions in qcs615-ride device tree — ensure physical address 0x10fefd8e0 is valid and accessible. (2) Check XHCI DMA mask configuration — confirm 32-bit vs 64-bit DMA capability and SWIOTLB pool allocation. (3) Review power domain and clock gating for memory controllers — ensure the memory region is powered and clocked when accessed. (4) If this is a known qcs615-ride limitation, add platform-specific DMA constraints or reserved memory exclusions to prevent allocation in inaccessible ranges.
  4. Detail analysis attachment: failed_case_job207958_2_detailed.md
Case 3: Kernel Crash — Synchronous External Abort during USB enumeration
  1. Failed case: Kernel Crash — Synchronous External Abort during USB enumeration
  2. Root cause: SWIOTLB bounce buffer allocation returned physical address 0x10fefd8e0 (4.25GB) which is outside the SWIOTLB mapped range (0xffdff000-0xfffff000, 2MB). When __pi_memcpy_generic attempted to copy data to this invalid address during USB device descriptor fetch, the CPU raised a synchronous external abort (bus fault), causing immediate kernel panic. This is a SWIOTLB allocator bug where the returned bounce buffer address does not belong to the SWIOTLB pool.
  3. Possible fix: This is a pre-existing kernel bug not introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (the PR only modifies PCIe PHY configurations and clock reference handling). The issue requires a kernel-side fix to the SWIOTLB allocator to ensure all returned bounce buffer addresses are within the mapped SWIOTLB range. As an immediate workaround, increase the SWIOTLB size via kernel command line parameter swiotlb=65536 (64MB) to reduce allocation pressure, or disable SWIOTLB bounce buffering for the xHCI controller if the platform supports 64-bit DMA addressing natively.
  4. Detail analysis attachment: failed_case_job207958_3_detailed.md
Case 4: ** Kernel Crash — Synchronous External Abort during USB DMA Mapping
  1. Failed case: ** Kernel Crash — Synchronous External Abort during USB DMA Mapping
  2. Root cause: ** Hardware bus fault (synchronous external abort with ESR 0x96000010) triggered during __pi_memcpy_generic while copying USB descriptor data to SWIOTLB bounce buffer at physical address 0x10fefd8e0. The fault occurred in the USB hub enumeration path when attempting to DMA-map a URB for device descriptor retrieval. The crash is PR-introduced: the PR reverts PCIe PHY supply changes and modifies clkref_en handling, which may have destabilized PCIe/USB power sequencing or IOMMU aperture configuration on qcs615-ride, causing invalid physical addresses to be generated during DMA setup.
  3. Possible fix: Revert the PR changes and investigate the interaction between PCIe PHY power supply configuration (specifically the reversion of x1e80100 qref supplies in patch 01/13) and USB controller DMA address generation on qcs615-ride. The synchronous external abort indicates the physical address 0x10fefd8e0 is not accessible by the USB controller's DMA engine — verify IOMMU aperture configuration, CMA/SWIOTLB reserved memory ranges, and PCIe/USB power domain sequencing after the PHY supply changes.
  4. Detail analysis attachment: failed_case_job207958_4_detailed.md
Job 207959 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Three pre-existing driver probe failures unrelated to PR changes: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone secure app unavailability on hamoa-evk, (2) qcom-spmi-lpg fails with -EINVAL due to device tree "reg" property mismatch for multi-LED configuration, (3) regulatory.db firmware file missing from rootfs causing -ENOENT. All three failures are platform/configuration issues present before this PR; the PR modifies only PCIe PHY and QREF clock drivers which are unrelated to these failures. System remains fully functional with WiFi, Bluetooth, and all critical subsystems operational.
  3. Possible fix: These are known benign platform-specific probe failures on hamoa-evk that do not impact system functionality. No PR changes required. To suppress these in CI: (1) add qcom_qseecom_uefisecapp to the known-benign probe failure list for hamoa-evk (TZ secure app not available on this platform variant), (2) fix the device tree multi-LED "reg" property for c42d000.spmi:pmic@1:pwm in hamoa DTS, (3) include wireless-regdb package in the rootfs image to provide regulatory.db firmware file.
  4. Detail analysis attachment: failed_case_job207959_1_detailed.md
Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test expects 6 critical masters (5 USB PHY controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and video codec at aa00000) to be attached to IOMMU groups, but these devices are not present in the device tree or are not configured with iommus properties on hamoa-evk platform.
  3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (which only adds TCSR regulator supplies). The test failure indicates missing device tree nodes or missing iommus properties for USB PHY controllers and video codec on hamoa. Either: (1) update the test to exclude these devices from the critical master check on hamoa if they are not present in hardware, or (2) add the missing device tree nodes with proper iommus properties if the hardware supports these devices.
  4. Detail analysis attachment: failed_case_job207959_2_detailed.md
Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM cannot initialize because Gunyah hypervisor is already running at EL2 (HYP mode). The kernel message "kvm [1]: HYP mode not available" indicates KVM detected that EL2 is already in use by another hypervisor. On ARM64, only one entity can control EL2 at a time - either KVM or a Type-1 hypervisor like Gunyah. The hamoa-evk platform is configured to boot with Gunyah hypervisor, making KVM unavailable by design.
  3. Possible fix: This is a test environment configuration issue, not a kernel bug. The KVM_Driver test should be skipped on platforms configured with Gunyah hypervisor. Add a test skip condition: if Gunyah hypervisor is detected (check for "Hypervisor cold boot, version: gunyah" in dmesg or /sys/hypervisor/type), skip all KVM tests with result=skip and reason="KVM unavailable - Gunyah hypervisor present".
  4. Detail analysis attachment: failed_case_job207959_3_detailed.md
Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM initialization failed because Gunyah hypervisor is running at EL2, preventing KVM from taking control of the hypervisor mode. The kernel detected "HYP mode not available" during KVM probe, resulting in no /dev/kvm device creation.
  3. Possible fix: This is a platform configuration issue, not a PR regression. Either (1) reconfigure hamoa-evk to boot without Gunyah hypervisor if KVM functionality is required, or (2) mark KVM tests as not applicable for hamoa-evk when Gunyah is present, as KVM and Gunyah cannot coexist (both require exclusive EL2 access).
  4. Detail analysis attachment: failed_case_job207959_4_detailed.md
Case 5: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel bug and cannot be fixed in software. To enable KVM on Hamoa: (1) Update the bootloader/UEFI firmware to boot the kernel at EL2 instead of EL1, or (2) Exclude KVM tests from the Hamoa test suite as the platform does not support virtualization in its current firmware configuration. This failure is unrelated to PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (PCIe PHY changes).
  4. Detail analysis attachment: failed_case_job207959_5_detailed.md
Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test definition marked as failed because 5 individual test cases failed (Probe_Failure_Check, smmu, KVM_Driver, KVM_EL2_DTB, KVM_Infra), with KVM tests failing due to missing /dev/kvm device node despite CONFIG_KVM being enabled in the kernel.
  3. Possible fix: Investigate why /dev/kvm is not created despite CONFIG_KVM=y — likely missing KVM module load or KVM initialization failure during boot; check dmesg for KVM probe errors and verify kvm.ko module is loaded with lsmod | grep kvm.
  4. Detail analysis attachment: failed_case_job207959_6_detailed.md
Job 207960 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Four PMIC thermal alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state, indicating a missing or failed thermal zone/PMIC dependency provider on lemans-evk; the Bluetooth firmware load failures are suppressed as known benign (BT_ON_OFF functional test passed).
  3. Possible fix: Investigate the qcom-spmi-temp-alarm driver probe logs and PMIC/thermal framework initialization on lemans-evk to identify the missing dependency (likely thermal zone configuration or PMIC regulator/clock); verify DT thermal-zones and SPMI PMIC nodes are correctly configured for SA8775P (lemans) platform.
  4. Detail analysis attachment: failed_case_job207960_1_detailed.md
Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Video codec platform device aa00000.video-codec is not attached to any IOMMU group, while its child devices (iris_non_pixel.0, iris_pixel.0) are correctly attached to IOMMU groups 25 and 26. The SMMU test expects all critical masters (including video codec) to have IOMMU group attachment, but the parent device lacks this attachment on SA8775P (Lemans EVK).
  3. Possible fix: This is a pre-existing platform configuration issue, not introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (which only modifies PCIe PHY and clock code). The test failure should be suppressed for SA8775P until the video codec device tree node is updated to include proper iommus property, or the test is updated to check child device attachment instead of parent device attachment for video codec.
  4. Detail analysis attachment: failed_case_job207960_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 definition marked as failed because two individual test cases within it failed: (1) Probe_Failure_Check failed due to deferred probe issues (temp-alarm devices) and missing firmware files (regulatory.db, Bluetooth firmware), and (2) smmu failed because video codec device aa00000.video-codec is missing IOMMU group attachment. These are pre-existing platform/configuration issues unrelated to the PCIe PHY changes in PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869. The message "Marking unfinished test run as failed" is LAVA's standard behavior when a test definition completes but contains failed sub-tests.
  3. Possible fix: These failures are not PR-introduced regressions. (1) For Probe_Failure_Check: ensure firmware files (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) are present in the rootfs, and investigate why temp-alarm@a00 devices on PMICs 0/2/4/6 remain in deferred probe state. (2) For smmu: add IOMMU binding for the video codec device aa00000.video-codec in the lemans-evk device tree to ensure it is attached to an IOMMU group. The PR changes only affect PCIe PHY configuration and do not touch video codec or PMIC thermal drivers.
  4. Detail analysis attachment: failed_case_job207960_3_detailed.md
Job 207961 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test detected four PMIC temp-alarm devices stuck in deferred probe state and two benign probe failures (regulatory.db firmware missing, Aquantia PHY probe failure due to missing firmware-name property) that are pre-existing platform issues unrelated to the PR changes.
  3. Possible fix: The deferred probe warnings for temp-alarm devices are benign if thermal monitoring is functional; verify thermal zones are operational. The regulatory.db firmware file should be added to the rootfs if WiFi regulatory domain enforcement is required. The Aquantia AQR115C PHY probe failure requires adding the firmware-name property to the device tree node for stmmac-0:08 if this PHY is intended to be functional on qcs9100-ride.
  4. Detail analysis attachment: failed_case_job207961_1_detailed.md
Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on qcs9100-ride platform; test expects all critical DMA masters to have IOMMU protection but this device lacks the required device tree iommus property or the driver failed to attach to IOMMU.
  3. Possible fix: Add iommus property to the video codec device tree node at aa00000.video-codec in arch/arm64/boot/dts/qcom/qcs9100.dtsi or qcs9100-ride.dts, referencing the appropriate SMMU instance and stream ID; if the property exists, investigate why the video codec driver is not probing or attaching to IOMMU (check for deferred probe or driver binding issues).
  4. Detail analysis attachment: failed_case_job207961_2_detailed.md
Case 3: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** Test infrastructure / lab configuration issue — the USBHost test expects at least one physical USB device (keyboard, mouse, storage, etc.) to be connected to the board's USB ports, but the qcs9100-ride board in the LAVA lab has no USB devices connected. The kernel USB stack is fully functional: all three USB host controllers (xhci-hcd) initialized successfully, USB hubs were detected on all buses (Bus 1, 2, 3), and no USB-related kernel errors occurred. The test correctly detected only root hubs (Device 001 on each bus) and reported this hardware configuration as a failure.
  3. Possible fix: Update the USBHost test logic to distinguish between genuine USB stack failures (controllers not initialized, driver probe failures) and lab configuration issues (controllers functional but no devices connected). When USB controllers and hubs are working but no peripheral devices are present, the test should report SKIP or WARN instead of FAIL. Alternative short-term fix: physically connect a USB device (e.g., USB flash drive) to one of the qcs9100-ride board's USB ports in the LAVA lab and update lab documentation to maintain this configuration.
  4. Detail analysis attachment: failed_case_job207961_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 framework marked the test definition as "unfinished" because the result_parse.sh script did not send the expected LAVA completion signal (ENDTCF or equivalent) after listing all test result files, causing LAVA to treat the test run as incomplete despite all individual tests completing.
  3. Possible fix: Update the result_parse.sh script in the qcom-linux-testkit repository to send the proper LAVA completion signal (<<<LAVA_SIGNAL_ENDTCF>>>) after parsing all test results, or verify that the test plan YAML correctly defines the expected completion behavior for LAVA.
  4. Detail analysis attachment: failed_case_job207961_4_detailed.md
Job 207962 | SoC monaco-evk

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

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

Case 1: **Driver Probe Failure — ath11k_pci WiFi driver**
  1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
  2. Root cause: The ath11k_pci driver probe failed with error -110 (ETIMEDOUT) during MHI (Modem Host Interface) power-up on monaco-evk (qcs8300). The failure occurred because the WiFi firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin) failed to load with error -2 (ENOENT), and subsequently the MHI subsystem timed out waiting for the device to power up. This is a pre-existing infrastructure issue unrelated to the PR changes — the PR modifies QREF clock support for x1e80100/glymur platforms only and does not touch monaco/qcs8300 device trees, drivers, or firmware paths.
  3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/) for monaco-evk test images. This is a test infrastructure/image packaging issue, not a kernel regression. The PR changes are unrelated to this failure and should not block merge.
  4. Detail analysis attachment: failed_case_job207962_1_detailed.md
Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure
  1. Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure
  2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. The MHI (Modem Host Interface) firmware loader reported "Direct firmware load for ath11k/WCN6855/hw2.1/nfa765/amss.bin failed with error -2" (ENOENT), causing the MHI power-up to timeout and the ath11k_pci driver probe to fail. This is a pre-existing infrastructure/image packaging issue on monaco-evk, not introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 (which only modifies PCIe PHY and clock drivers for x1e80100/glymur platforms).
  3. Possible fix: Add the missing WCN6855 WiFi firmware files to the monaco-evk rootfs image. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are included in the firmware directory (/lib/firmware/). Verify the firmware package (e.g., linux-firmware-ath11k or equivalent) is installed in the Yocto/build recipe for monaco-evk images, or manually copy the firmware files from the upstream linux-firmware repository to the target rootfs.
  4. Detail analysis attachment: failed_case_job207962_2_detailed.md
Case 3: ** WiFi_OnOff — Driver Probe Failure (Firmware Dependency)
  1. Failed case: ** WiFi_OnOff — Driver Probe Failure (Firmware Dependency)
  2. Root cause: ** ath11k_pci driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (/lib/firmware/). MHI (Modem Host Interface) cannot complete device initialization without firmware, leading to a timeout during power-up. This is a userspace/rootfs packaging issue, not a kernel driver or hardware failure.
  3. Possible fix: Add the missing WCN6855 firmware files to the rootfs. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin (and any other required firmware for this chip variant) is present in /lib/firmware/ in the build image. Verify the firmware package (e.g., linux-firmware-ath11k or equivalent) is included in the Yocto/build recipe for monaco-evk.
  4. Detail analysis attachment: failed_case_job207962_3_detailed.md
Case 4: Driver Probe Failure — ath11k_pci WiFi driver
  1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
  2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image (-ENOENT, error -2), causing MHI (Modem Host Interface) power-up to timeout. This is a pre-existing firmware packaging issue in the Monaco (iq-8275-evk) rootfs, not introduced by PR Vote qref in tcsr driver for glymur/mahua/hamoa/purwa #869 which only modifies PCIe PHY regulator configuration for Glymur SoC.
  3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Monaco rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). This is a build/packaging fix, not a kernel code fix. The PR changes are unrelated and safe to merge.
  4. Detail analysis attachment: failed_case_job207962_4_detailed.md

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@qianyu-qcom@qlijarvis@qcomlnxci@sgaud-quic@quic-tingweiz@Komal-Bajaj