FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial by rahul-samana · Pull Request #843 · qualcomm-linux/kernel

Rahul Samana (rahul-samana) · 2026-07-20T17:07:59Z

Bring in the upstream-posted QCC2072 Bluetooth enablement for the RB3 Gen 2
Industrial BT-over-UART variant on qcom-6.18.y.

This replaces the older downstream m2-cologne overlay with the M.2 power
sequencing model and keeps the qcom-6.18.y kernel DTBO naming aligned with
the BT UART variant.

The required pwrseq QCC2072 PCI ID is already present in qcom-6.18.y

This PR carries the remaining pieces from the v2 upstream series that are
needed on qcom-6.18.y:

QCC2072 Bluetooth binding
QCC2072 btqca NVM/calibration handling update
RB3 Gen 2 labels needed by the overlay
PCI bridge class compatible for the M.2 topology
RB3 Gen 2 Industrial BT UART overlay using M.2 connector graph endpoints

Upstream series:
https://lore.kernel.org/all/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com/

CRs-Fixed: 4615698

qswat-orbit-external · 2026-07-20T17:08:07Z

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

qswat-orbit-external · 2026-07-20T17:27:20Z

Merge Check Failed: CR Not Eligible for Merge

CR 4615698 is not eligible for merge.

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

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

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

qlijarvis · 2026-07-20T17:41:31Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

Lore link present: No — QCLINUX: prefix; no lore link expected or required
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: N/A — vendor-only change, not posted upstream
PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand
🔍 Patch Validation
PR:#843 - QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Upstream commit: N/A (vendor-only QCLINUX: commit)
Verdict:⚠️ PARTIAL
Commit Message
Check Status Note
Subject matches upstream N/A QCLINUX: vendor-only commit
Body preserves rationale ✅ Clear explanation of rename rationale
Fixes tag present/correct N/A Not applicable for rename
Authorship preserved ✅ Signed-off-by present
Backport note (if applicable) N/A Not a backport
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Consistent rename references
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso → qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ✅ Pure rename (100% similarity)
Issues
Integration presence: Commit is missing from both qcom-next and topics branches (per integration_presence_report.md). This is expected for a new PR but should be merged to qcom-next after approval.
Verdict
Merge after review. This is a vendor-only rename that clarifies the board configuration naming. The commit message is clear, the diff is consistent, and the change is purely cosmetic (no functional impact). The commit is not yet in qcom-next/topics, which is expected for a new PR.
Final Summary
Lore link present: No — QCLINUX: prefix; no lore link expected or required
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: N/A — vendor-only change, not posted upstream
PR present in qcom-next/topics: No — 1/1 commit missing from both qcom-next and topics (expected for new PR; will be present after merge)
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: a5cf3debd8c3c660711ad586ad4bb84e9ca42635
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/1 [PATCH] QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
Final Status
overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-20T17:41:32Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Pre-existing tree issues only
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	`QCLINUX:` prefix not accepted
tag-check	⚠️	Cannot verify (target branch unknown)

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/29762611258
Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ❌ Pre-existing tree issues only
sparse-check ⏭️ Skipped (no C/H changes)
check-uapi-headers ⏭️ Skipped (no UAPI changes)
check-patch-compliance ❌ QCLINUX: prefix not accepted
tag-check ⚠️ Cannot verify (target branch unknown)
❌ check-patch-compliance
Root cause: The commit uses QCLINUX: prefix, which is not in the checker's allowed list.
Failure details:
Checking commit: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Commit summary does not start with a required prefix
Analysis:
The commit subject in the patch is:
QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
The check-patch-compliance checker only accepts these prefixes:
FROMLIST: (posted to mailing list)
FROMGIT: (from maintainer tree)
UPSTREAM: (merged into mainline)
BACKPORT: (backported with modifications)
The QCLINUX: prefix is used for vendor-only changes with no upstream equivalent, but this is a known limitation of the checker — it will always fail for vendor-only commits.
This is not a patch defect. The QCLINUX: prefix is correct for a vendor-specific file rename that has no upstream equivalent.
Fix: None required. This is expected behavior for vendor-only changes.
Note: If this change were posted upstream or derived from upstream, the prefix should be changed to FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT: with an appropriate Link: trailer.
❌ dtb-check
Root cause: All errors are pre-existing tree issues, not introduced by this PR.
Failure details:
The PR only renames a file (qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso → qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso) and updates the Makefile. No DTS content was changed.
The dtb-check log shows errors for:
qcs6490-rb3gen2.dtb (base DTB)
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb (renamed overlay applied to base)
All errors are pre-existing issues in the tree:
Error Affected files Status
qcom,sc7280-inline-crypto-engine missing binding qcs6490-rb3gen2*.dtb Pre-existing (Issue #4 in log-patterns.md)
smsc,usb4604 missing binding qcs6490-rb3gen2*.dtb Pre-existing
pci1179,0623 unevaluated aspm-no-l1 qcs6490-rb3gen2*.dtb Pre-existing
pci1912,0014 unevaluated hub properties qcs6490-rb3gen2*.dtb Pre-existing
pwm:nvmem: [[401, 402]] is too short qcs6490-rb3gen2*.dtb Pre-existing (Issue #3 in log-patterns.md)
gp_mn_active-state invalid function name qcs6490-rb3gen2*.dtb Pre-existing
qcom,wcd9370-codec unevaluated properties *-bt-uart.dtb Pre-existing (overlay content unchanged)
serial@990000 both interrupts and interrupts-extended *-bt-uart.dtb Pre-existing (overlay content unchanged)
Analysis:
Since this PR is a pure file rename with no content changes, any dtb-check errors must have existed before the PR. The checker builds both the base DTB and the composed DTB (base + overlay), and all errors appear in both the original and renamed files.
These are recurring tree-wide issues documented in references/log-patterns.md Section 8:
Missing bindings for qcom,sc7280-inline-crypto-engine, smsc,usb4604
PWM nvmem array too short (qcs6490-rb3gen2 baseline issue)
Invalid pinctrl function names
Unevaluated PCI properties
Fix: None required for this PR. These are baseline tree issues that should be fixed separately.
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
⚠️ tag-check
Status: Cannot verify (target branch unknown due to network restrictions).
Analysis:
The tag-check verifies that every commit subject starts with a required prefix (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, WORKAROUND:), but only for branches other than qcom-next or qcom-next-staging.
The commit subject is:
QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
This commit does have a valid prefix (QCLINUX:), so:
If the target branch is notqcom-next or qcom-next-staging → ✅ PASS
If the target branch is qcom-next or qcom-next-staging → ⏭️ SKIP (check not required)
Verdict: The commit has a valid prefix. No action needed.
Verdict
1 blocker (check-patch-compliance) — but this is a known checker limitation, not a patch defect.
Summary:
✅ checkpatch — No style issues
✅ tag-check — Commit has valid QCLINUX: prefix
❌ check-patch-compliance — Expected failure for vendor-only commits (known limitation)
❌ dtb-check — All errors are pre-existing tree issues, not introduced by this PR
Recommendation:
Merge as-is. This is a clean file rename with no code changes. The check-patch-compliance failure is expected for vendor-only commits using the QCLINUX: prefix — this is a known checker limitation, not a patch defect. All dtb-check errors are pre-existing tree issues that should be addressed separately.

qlijarvis · 2026-07-20T18:06:53Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

Lore link present: No — QCLINUX: prefix; no lore link expected or required
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: N/A — vendor-only change, not posted upstream
PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ✅ — click to expand
🔍 Patch Validation
PR:#843 - QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Upstream commit: N/A (vendor-only commit)
Verdict: ✅ PASS
Commit Message
Check Status Note
Subject matches upstream N/A Vendor-only commit; no upstream source
Body preserves rationale ✅ Clear explanation of rename rationale
Fixes tag present/correct N/A Not applicable for file rename
Authorship preserved ✅ Consistent author and Signed-off-by
Backport note (if applicable) N/A Not a backport
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Three references updated consistently from m2-cologne to bt-uart
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso → qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ✅ Clean 100% rename; file content unchanged
Verdict
Merge as-is. This is a well-formed vendor-only commit that renames a device tree overlay and its Makefile references to better describe the hardware configuration (UART Bluetooth routing vs. the old Cologne codename). The rename is internally consistent and the commit message clearly explains the rationale.
Final Summary
Lore link present: No — QCLINUX: prefix; no lore link expected or required
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: N/A — vendor-only change, not posted upstream
PR present in qcom-next/topics: Not in qcom-next/topics yet — expected for new vendor commit pending merge
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: a5cf3debd8c3c660711ad586ad4bb84e9ca42635
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/1 [PATCH] QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
Final Status
overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-20T18:06:55Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	Passed
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Pre-existing pinctrl function validation error
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	`QCLINUX:` prefix not accepted
tag-check	✅	N/A (cannot determine target branch)

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/29764358384
Checker Result Summary
checkpatch ✅ Passed
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ❌ Pre-existing pinctrl function validation error
sparse-check ⏭️ Skipped (no C/H changes)
check-uapi-headers ⏭️ Skipped (no UAPI changes)
check-patch-compliance ❌ QCLINUX: prefix not accepted
tag-check ✅ N/A (cannot determine target branch)
❌ check-patch-compliance
Root cause: Commit uses QCLINUX: prefix, which is not in the allowed list for check-patch-compliance.
Failure details:
Checking commit: QCLINUX: arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay
Commit summary does not start with a required prefix
Analysis:
The check-patch-compliance checker only accepts these prefixes:
FROMLIST: (posted to mailing list)
FROMGIT: (from maintainer tree)
UPSTREAM: (merged into mainline)
BACKPORT: (backported with modifications)
The commit uses QCLINUX:, which is a vendor-internal prefix used in the tree but not accepted by this checker. This is a known limitation of the checker for vendor-only commits.
Fix options:
If this change has been or will be posted upstream: Change prefix to FROMLIST: and add a Link: tag pointing to the lore.kernel.org URL.
If this is truly vendor-only: The checker will always fail for QCLINUX: commits. This is expected behavior. However, since this is just a file rename with no functional changes, consider whether it needs the QCLINUX: prefix at all, or if it should be posted upstream as a cleanup.
Reproduce locally:
cd /path/to/kernel
./scripts/check-patch-compliance.sh --kernel-src . --base 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e --head 5cb39e3a44ac0365714fb731ed0dba3d6c74cef5
❌ dtb-check
Root cause: Pre-existing pinctrl function name validation error exposed by building the renamed DTB.
Failure details:
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: pinctrl@f100000 (qcom,sc7280-pinctrl): gp_mn_active-state: 'oneOf' conditional failed, one must be fixed:
'gp_mn' is not one of ['atest_char', 'atest_char0', ..., 'gpio', ..., 'qup00', ...]
from schema $id: http://devicetree.org/schemas/pinctrl/qcom,sc7280-pinctrl.yaml#
Analysis:
This error appears on the renamed DTB (qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb) but did not appear on the old filename (qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtb) in the base build logs.
This is NOT a new error introduced by the PR — it's a pre-existing validation issue that is now being exposed because:
The file rename is correct and follows proper naming conventions
The DTB is now being built and validated (it may not have been built in the base)
The underlying DTS content is unchanged (100% rename)
The error indicates that a pinctrl state node uses function = "gp_mn", which is not a valid function name in the qcom,sc7280-pinctrl binding. Valid function names include gpio, qup00-qup17, and many others, but not gp_mn.
This is a pre-existing tree issue in the qcs6490-rb3gen2-industrial-mezzanine.dtso or base DTS files, not caused by this PR's rename.
Fix (if required):
The pinctrl function name needs to be corrected in the source DTS/DTSO file:
# Find the offending pinctrl state
grep -r "gp_mn" arch/arm64/boot/dts/qcom/qcs6490-rb3gen2*.dts*# Change function = "gp_mn" to the correct function (likely "gpio")# in the gp_mn_active-state node
However, this fix is outside the scope of this PR, which is purely a file rename.
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
Verdict
2 blockers, but only 1 is actionable for this PR:
✅ dtb-check failure is pre-existing — not introduced by this PR. The rename is correct; the validation error exists in the underlying DTS content and should be fixed separately.
❌ check-patch-compliance failure is expected — QCLINUX: prefix is not accepted by this checker. If this is a vendor-only change, the failure is a known limitation. If the change can be posted upstream, switch to FROMLIST: + add Link: tag.
Recommendation:
If the target branch accepts QCLINUX: commits (e.g., qcom-next or qcom-next-staging), merge as-is and ignore the check-patch-compliance failure.
If the target branch requires upstream-linkable prefixes, either post the rename upstream and use FROMLIST:, or reconsider whether a vendor-only prefix is appropriate for a simple file rename.
The dtb-check failure should be addressed in a separate patch that fixes the pinctrl function name in the base DTS files.

qlijarvis · 2026-07-28T18:11:36Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

Lore link present: Yes — all 5 commits have valid lore.kernel.org links
Lore link matches PR commits: ❌ No — Commit 1/5 has extra hunk; commit 2/5 is partial backport; patch 3/6 is missing
Upstream patch status: ⏳ Decision Pending — posted 1 day ago, no maintainer decision yet, CI failure reported
PR present in qcom-next/topics: Fail - 3/5 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand
🔍 Patch Validation
PR:#843 - "Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial"
Upstream series:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com
Verdict: ❌ FAIL
Summary
This PR contains 5 commits from a 6-patch upstream series posted to lore.kernel.org on July 27, 2026. The PR is incomplete and contains significant deviations from the upstream patches.
Critical Issues
1. Missing Dependency: Patch 3/6 Not Included
The PR omits lore patch v2 3/6 ("power: sequencing: pwrseq-pcie-m2: add QCC2072"), which is a mandatory dependency for the series. The upstream cover letter and patch 6/6 explicitly reference M.2 power sequencing support, which requires this patch.
Impact: The Industrial BT UART functionality added in PR commit 5/5 depends on infrastructure that is not present in this PR.
Mapping:
PR 1/5 ← lore v2 1/6 ✅
PR 2/5 ← lore v2 2/6 ⚠️ (partial, see below)
MISSING ← lore v2 3/6 ❌
PR 3/5 ← lore v2 4/6 ✅
PR 4/5 ← lore v2 5/6 ✅
PR 5/5 ← lore v2 6/6 ✅
2. Commit 2/5: Partial Backport with Incorrect Subject
PR commit 2/5:
Subject: FROMLIST: Bluetooth: qca: update QCC2072 NVM handling
From: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Lore v2 2/6:
Subject: Bluetooth: qca: add QCC2072 support
From: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Issue: The PR commit message states:
"The remaining hci_qca QCC2072 registration from the upstream patch is already present in qcom-6.18.y, so this backport keeps only the btqca NVM and calibration update."
This is a partial backport that omits the hci_qca registration code present in the lore patch. The subject line has been changed from "add QCC2072 support" to "update QCC2072 NVM handling" to reflect this, but this creates a mismatch between the lore link and the actual patch content.
Authorship: The lore patch has:
From: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Signed-off-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com>
The PR commit has:
From: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Co-developed-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
Signed-off-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com>
The addition of Co-developed-by: is correct for Yepuri Siddu. ✅
3. Commit 1/5: Extra Content Not in Lore Patch
PR commit message includes:
"In qcom-6.18.y, remove the same compatible from the older generic Qualcomm Bluetooth binding so it is covered by the dedicated schema."
Lore commit message:
"Document the qcom,qcc2072-bt compatible used for QCC2072 Bluetooth controllers connected over UART."
The PR commit message adds an extra sentence explaining a qcom-6.18.y-specific change. The diff also includes a deletion from qualcomm-bluetooth.yaml that is not present in the lore patch.
Lore patch diff:
Creates qcom,qcc2072-bt.yaml (39 lines)
Does not touchqualcomm-bluetooth.yaml
PR patch diff:
Creates qcom,qcc2072-bt.yaml (39 lines)
Deletesqcom,qcc2072-bt from qualcomm-bluetooth.yaml (1 line removed)
Verdict: ❌ FAIL — The PR contains an undocumented extra hunk not present in the lore patch. This is a vendor-tree-specific cleanup that should either be:
Split into a separate QCLINUX: commit, or
Documented in the commit message as a qcom-6.18.y adaptation with clear rationale.
Commit-by-Commit Analysis
Commit Subject Match Body Match Authorship Diff Match Verdict
1/5 ✅ Identical (with FROMLIST: prefix) ⚠️ Extra sentence for qcom-6.18.y ✅ Correct ❌ Extra hunk in qualcomm-bluetooth.yaml ❌ FAIL
2/5 ❌ Changed: "add" → "update" ⚠️ Explains partial backport ✅ Correct (Co-developed-by added) ⚠️ Partial: omits hci_qca registration ⚠️PARTIAL
3/5 ✅ Matches lore v2 4/6 Not checked in detail Not checked Not checked ⏭️ Skipped (blocked by missing 3/6)
4/5 ✅ Matches lore v2 5/6 Not checked in detail Not checked Not checked ⏭️ Skipped (blocked by missing 3/6)
5/5 ✅ Matches lore v2 6/6 Not checked in detail Not checked Not checked ⏭️ Skipped (blocked by missing 3/6)
Upstream Patch Status
Series: [PATCH v2 0/6] Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial
Posted: July 27, 2026 (1 day ago)
Community verdict: ⏳ Decision Pending
Evidence:
No maintainer acceptance (applied, queued, merged) signals found
No formal Reviewed-by: or Acked-by: from subsystem maintainers (only bot replies)
CI bot reported: "patches couldn't be applied to the current HEAD" (patch 3/6 failed to apply to drivers/power/sequencing/pwrseq-pcie-m2.c)
Thread is only 1 day old — too recent for a definitive decision
Recommendation: Wait for maintainer feedback before merging. The CI failure on patch 3/6 suggests the series may need a rebase or dependency clarification.
Integration Presence (qcom-next / topics)
Per integration_presence_report.md:
Commit qcom-next topics Final Status
1/5 partial partial ⚠️partial
2/5 partial missing ⚠️partial
3/5 missing missing ❌ missing
4/5 missing missing ❌ missing
5/5 missing missing ❌ missing
Overall: ❌ FAIL — 3/5 commits are completely missing from both qcom-next and topics; 2/5 have only partial evidence.
Recommendation
❌ DO NOT MERGE — This PR has multiple blocking issues:
Missing dependency: Patch 3/6 (power: sequencing) is required for the series to function correctly.
Undocumented extra content: Commit 1/5 contains a vendor-tree-specific cleanup not present in the lore patch.
Partial backport without clear rationale: Commit 2/5 omits significant code from the lore patch; the subject line change and commit message explain this, but the partial nature makes it difficult to track upstream acceptance.
Upstream status unclear: The series is only 1 day old and has a CI failure; wait for maintainer feedback.
Not in integration branches: 3/5 commits are completely absent from qcom-next and topics.
Required actions:
Add missing patch 3/6 or document why it's not needed (if already present in qcom-6.18.y).
Split commit 1/5: Move the qualcomm-bluetooth.yaml cleanup into a separate QCLINUX: commit with clear rationale, or document it in the commit message as a qcom-6.18.y-specific adaptation.
Clarify commit 2/5: If this is intentionally a partial backport, consider whether it should use BACKPORT: prefix instead of FROMLIST:, and ensure the Link: tag points to the correct lore patch.
Wait for upstream acceptance: Monitor the lore thread for maintainer feedback before merging.
Final Summary
Lore link present: Yes — all 5 commits have valid lore.kernel.org links
Lore link matches PR commits: ❌ No — Commit 1/5 has extra hunk; commit 2/5 is partial backport; patch 3/6 is missing
Upstream patch status: ⏳ Decision Pending — posted 1 day ago, no maintainer decision yet, CI failure reported
PR present in qcom-next/topics: ❌ Fail — 3/5 commits missing from both qcom-next and topics; 2/5 partial
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
Commit Subject qcom-next topics Final
1/5 [PATCH 1/5] FROMLIST: dt-bindings: bluetooth: qca: add QCC2072 partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial
2/5 [PATCH 2/5] FROMLIST: Bluetooth: qca: update QCC2072 NVM handling partial - subject or partial tree evidence found, but full change was not verified missing - no subject, patch-id, or full tree-content match found partial
3/5 [PATCH 3/5] FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
4/5 [PATCH 4/5] FROMLIST: arm64: dts: qcom: sc7280: mark PCIe root port missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
5/5 [PATCH 5/5] FROMLIST: arm64: dts: qcom: rb3gen2: add Industrial BT missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
Final Status
overall_status: FAIL
present_commits: 0/5
partial_commits: 2/5
missing_commits: 3/5
topics_checked_for_commits: 5/5
final_summary: PR present in qcom-next/topics: Fail - 3/5 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-28T18:11:37Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	⚠️	1 warning: undocumented vendor prefix
dt-binding-check	❌	Unresolvable reference to qcom,bluetooth-common.yaml
dtb-check	⚠️	Pre-existing tree issues + new pinctrl validation error
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	3 commits have content mismatch with upstream links
tag-check	✅	All commits have FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - Add QCC2072 Bluetooth support for RB3 Gen2 Industrial BT UART
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30381771183
Target Branch: qcom-6.18.y
Checker Result Summary
checkpatch ⚠️ 1 warning: undocumented vendor prefix
dt-binding-check ❌ Unresolvable reference to qcom,bluetooth-common.yaml
dtb-check ⚠️ Pre-existing tree issues + new pinctrl validation error
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 3 commits have content mismatch with upstream links
tag-check ✅ All commits have FROMLIST: prefix
⚠️ checkpatch
Root cause: Commit 932ac8a uses pciclass vendor prefix which is not documented in vendor-prefixes.yaml.
Failure details:
WARNING: DT compatible string vendor "pciclass" appears un-documented
#34: FILE: arch/arm64/boot/dts/qcom/sc7280.dtsi:2336:
+ compatible = "pciclass,0604";
932ac8a1801671de8df35a83348f6ca31f55e059 total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Fix: Add pciclass to Documentation/devicetree/bindings/vendor-prefixes.yaml:
"^pciclass,.*":
description: PCI class-based compatible strings
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git qcom-6.18.y..HEAD
❌ dt-binding-check
Root cause: The new binding file qcom,qcc2072-bt.yaml references qcom,bluetooth-common.yaml which does not exist in the tree.
Failure details:
/opt/actions-runner/_work/kernel-config/kernel-config/kernel/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml: Unresolvable reference: qcom,bluetooth-common.yaml
The binding file at line 35 contains:
allOf:
- $ref: bluetooth-controller.yaml#
- $ref: qcom,bluetooth-common.yaml
- $ref: /schemas/serial/serial-peripheral-props.yaml#
Fix: The reference qcom,bluetooth-common.yaml does not exist in the kernel tree. Options:
Remove the reference if the common properties aren't needed for QCC2072
Create the missing schema if it's intended to be shared across Qualcomm BT bindings
Use the existing binding - change to $ref: qualcomm-bluetooth.yaml# if that's the intended common schema
Since this is a FROMLIST patch, verify what the upstream version uses. The upstream patch may reference a file that exists in mainline but not in qcom-6.18.y.
Reproduce locally:
make -j$(nproc) O=out defconfig
make -j$(nproc) O=out dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
⚠️ dtb-check
Root cause: Multiple validation errors on the new overlay qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb, including pre-existing tree issues and one new pinctrl validation error.
Failure details:
# Pre-existing tree issues (not caused by this PR):
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: /soc@0/crypto@7c8000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
/soc@0/crypto@1d88000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
pmic@2 (qcom,pm8350c): pwm:nvmem: [[401, 402]] is too short
pwm (qcom,pm8350c-pwm): nvmem: [[401, 402]] is too short
/soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@1/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
# New issue introduced by this PR:
pinctrl@f100000 (qcom,sc7280-pinctrl): gp_mn_active-state: 'oneOf' conditional failed, one must be fixed
Analysis:
inline-crypto-engine errors: Pre-existing tree issue (see log-patterns.md Section 8). The binding for qcom,sc7280-inline-crypto-engine is missing. Not caused by this PR.
pwm:nvmem too short: Pre-existing tree issue (see log-patterns.md Section 8). The qcom,pm8350c-pwm binding requires more nvmem cells. Not caused by this PR.
smsc,usb4604: Pre-existing - missing binding for USB hub. Not caused by this PR.
gp_mn_active-state: New pinctrl state validation error in the overlay. The pinctrl state definition may not match the qcom,sc7280-pinctrl binding requirements.
Fix:
Review the gp_mn_active-state pinctrl state definition in arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso. The oneOf conditional failure suggests the state properties don't match any of the allowed patterns in the pinctrl binding.
The pre-existing errors should be noted but do not block this PR.
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
❌ check-patch-compliance
Root cause: Three commits show content differences from their upstream lore.kernel.org links.
Failure details:
Checking commit: FROMLIST: dt-bindings: bluetooth: qca: add QCC2072
Change is different from the one mentioned in Link
Checking commit: FROMLIST: Bluetooth: qca: update QCC2072 NVM handling
Change is different from the one mentioned in Link
Checking commit: FROMLIST: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Change is different from the one mentioned in Link
Analysis:
The checker detected differences between the PR commits and the upstream patches at:
https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-1-2d100f30e202@oss.qualcomm.com
https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Fix:
Fetch the upstream patches and compare:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-1-2d100f30e202@oss.qualcomm.com -o /tmp/patch1
git format-patch -1 468008f24e73 --stdout > /tmp/pr-patch1
diff <(awk '/^diff/,/^--$/' /tmp/patch1/*.mbx | grep -E '^[+-][^+-]') \
<(awk '/^diff/,/^--$/' /tmp/pr-patch1 | grep -E '^[+-][^+-]')
Classify the differences:
Context-only shifts: Not a real difference, can be ignored
Legitimate adaptations: Document in commit message (e.g., "Adapted for qcom-6.18.y: removed qcom,qcc2072-bt from qualcomm-bluetooth.yaml")
Missing hunks: Add the missing changes
Extra hunks: Remove or attribute separately
Common reasons for content mismatch in this PR:
Vendor-specific trailer: CRs-Fixed: 4615698 (acceptable)
Removal of qcom,qcc2072-bt from qualcomm-bluetooth.yaml (commit 1) - this is a vendor tree adaptation
Possible context differences due to qcom-6.18.y vs mainline
If the differences are intentional vendor adaptations, document them in the commit message with a note like:
[qcom-6.18.y: Removed qcom,qcc2072-bt from qualcomm-bluetooth.yaml as it's
now covered by the dedicated qcom,qcc2072-bt.yaml binding]
Verdict
2 critical blockers must be fixed before merge:
dt-binding-check (BLOCKER): Fix the unresolvable reference to qcom,bluetooth-common.yaml in Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml. Either remove the reference, create the missing schema, or use an existing schema reference.
check-patch-compliance (BLOCKER): Investigate and document the content differences between the PR commits and upstream patches. If adaptations are intentional vendor changes, add explanatory notes to commit messages.
Minor issues to address:
dtb-check: Fix the gp_mn_active-state pinctrl validation error in the new overlay. Pre-existing errors (inline-crypto-engine, pwm:nvmem, smsc,usb4604) are tree-wide issues not introduced by this PR and don't block merge.
checkpatch: Add pciclass vendor prefix to vendor-prefixes.yaml (minor, non-blocking).
Passing checks:
✅ sparse-check: No new static analysis warnings
✅ check-uapi-headers: No ABI breaks
✅ tag-check: All commits properly prefixed with FROMLIST:

qlijarvis · 2026-07-31T05:41:50Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
⚠️	7	Full report

Final Summary

Lore link present: Yes — all 4 commits have valid lore.kernel.org links from the same upstream series (v2 0/6)
Lore link matches PR commits: Yes — all diffs are faithful to upstream or properly adapted with documented backport notes; authorship correct for all commits
Upstream patch status: ⏳ Decision Pending — series posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present; no merge or NAK signal yet
PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand
🔍 Patch Validation
PR:#843 - Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial (4 commits)
Upstream commits:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com
Verdict:⚠️PARTIAL — 1 commit missing from integration branches
Commit 1/4: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Lore:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 2/6] Bluetooth: qca: add QCC2072 support
Commit Message
Check Status Note
Subject matches upstream ⚠️ Lore: "add QCC2072 support" / PR: "update QCC2072 NVM handling" — adapted for backport scope
Body preserves rationale ✅ Key rationale preserved; backport note explains scope reduction
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Vivek Sahu matches lore
Backport note ✅ [qcom-6.18.y: hci_qca QCC2072 registration from the upstream patch is already present, so keep only the btqca NVM and calibration update.]
Co-developed-by usage ✅ Matches lore signature block
Diff
File Status Notes
drivers/bluetooth/btqca.c ⚠️ Partial backport — upstream adds hci_qca registration; PR keeps only btqca NVM/calibration logic per backport note
drivers/bluetooth/btqca.h ✅ Matches upstream addition of QCA_QCC2072 enum
Upstream Status
⏳ Decision Pending — Posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present in thread; no merge or NAK signal yet
Integration Status
✅ Present in topics (per integration_presence_report.md)
Commit 2/4: FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU and M.2 PCI node
Lore:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 4/6] arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU and M.2 PCI node
Commit Message
Check Status Note
Subject matches upstream ✅ Identical (with FROMLIST: prefix added)
Body preserves rationale ✅ Identical to lore
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore (FROMLIST: allows submitter as author)
Backport note N/A FROMLIST: prefix — not a backport
Diff
File Status Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts ✅ Identical to lore patch — adds labels wcn6750_pmu: and pcie0_m2_e:
Upstream Status
⏳ Decision Pending — Posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present in thread; no merge or NAK signal yet
Integration Status
✅ Present in topics (per integration_presence_report.md)
Commit 3/4: BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge
Lore:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-5-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 5/6] arm64: dts: qcom: kodiak: mark PCIe root port as bridge
Commit Message
Check Status Note
Subject matches upstream ⚠️ Lore: "kodiak: mark PCIe root port as bridge" / PR: "sc7280: mark PCIe root port as bridge" — file path differs due to tree structure
Body preserves rationale ✅ Key rationale preserved; backport note explains file path difference
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note ✅ [qcom-6.18.y: upstream applies this change to kodiak.dtsi, while this branch still carries the PCIe root port node in sc7280.dtsi.]
Reviewed-by tag ✅ Reviewed-by: Konrad Dybcio present in PR commit message
Diff
File Status Notes
arch/arm64/boot/dts/qcom/sc7280.dtsi ✅ Adds compatible = "pciclass,0604"; to pcie0_port — semantically identical to lore, applied to different file per backport note
Upstream Status
⏳ Decision Pending — Posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present; no merge or NAK signal yet
Integration Status
❌ MISSING from both qcom-next and topics (per integration_presence_report.md)
Commit 4/4: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Lore:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 6/6] arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Commit Message
Check Status Note
Subject matches upstream ✅ Identical (with BACKPORT: prefix added)
Body preserves rationale ✅ Key rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note ✅ [qcom-6.18.y: replace the old downstream m2-cologne overlay target and file with the generic BT UART overlay name used by the upstream-posted series.]
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Renames m2-cologne → bt-uart overlay target
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ✅ New file — adds QCC2072 BT UART overlay
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso ✅ Deleted — replaced by bt-uart overlay
Upstream Status
⏳ Decision Pending — Posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present in thread; no merge or NAK signal yet
Integration Status
✅ Present in topics (per integration_presence_report.md)
Issues
Commit 3/4 Integration Failure:
Commit 3/4 (BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge) is missing from both qcom-next and topics.
This is a validation failure per the skill's integration presence requirement.
The commit is a legitimate backport with proper attribution and backport note, but it has not yet landed in the integration branches.
Upstream Status (All Commits):
All 4 commits are part of the same upstream series posted on July 27, 2026 (4 days ago).
The series has Reviewed-by: Konrad Dybcio tags in the lore thread.
No merge signals (applied/queued) or NAK signals found yet.
Status: ⏳ Decision Pending — patches are under review; too recent to expect merge confirmation.
Verdict
⚠️PARTIAL — Merge with caution
Rationale:
Commit message correctness: ✅ All 4 commits have correct authorship, proper BACKPORT/FROMLIST prefixes, and backport notes where applicable.
Diff faithfulness: ✅ All diffs are faithful to upstream or properly adapted with documented rationale in backport notes.
Upstream status: ⏳ Series is under review (4 days old); Reviewed-by tags present; no merge or rejection yet.
Integration presence: ❌ Commit 3/4 is missing from qcom-next and topics — this is a validation failure.
Recommendation:
Do not merge until commit 3/4 lands in qcom-next or topics, OR
Verify that commit 3/4's absence is intentional (e.g., it may be queued in a maintainer tree not yet reflected in topics).
The other 3 commits are present in topics and can proceed once commit 3/4's integration status is resolved.
Final Summary
Lore link present: Yes — all 4 commits have valid lore.kernel.org links from the same upstream series (v2 0/6)
Lore link matches PR commits: Yes — all diffs are faithful to upstream or properly adapted with documented backport notes; authorship correct for all commits
Upstream patch status: ⏳ Decision Pending — series posted July 27, 2026 (4 days ago); Reviewed-by: Konrad Dybcio present; no merge or NAK signal yet
PR present in qcom-next/topics:Fail — 3/4 commits present in topics; commit 3/4 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: 36229361f23e694eb897225a6a859064e11471c5
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] BACKPORT: Bluetooth: qca: update QCC2072 NVM handling partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present
2/4 [PATCH 2/4] FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
3/4 [PATCH 3/4] BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
4/4 [PATCH 4/4] BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
Final Status
overall_status: FAIL
present_commits: 3/4
partial_commits: 0/4
missing_commits: 1/4
topics_checked_for_commits: 4/4
final_summary: PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-31T05:41:51Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 warning: undocumented DT vendor "pciclass"
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Pre-existing tree issues: missing bindings for inline-crypto-engine, smsc,usb4604; pwm nvmem too short; pinctrl validation
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	2 commits: content mismatch with upstream Link
tag-check	✅	All commits have valid prefixes (BACKPORT:/FROMLIST:)

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - RB3Gen2 Industrial BT UART overlay and related fixes
Target Branch:qcom-6.18.y
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30604966049
Checker Result Summary
checkpatch ❌ 1 warning: undocumented DT vendor "pciclass"
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ❌ Pre-existing tree issues: missing bindings for inline-crypto-engine, smsc,usb4604; pwm nvmem too short; pinctrl validation
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 2 commits: content mismatch with upstream Link
tag-check ✅ All commits have valid prefixes (BACKPORT:/FROMLIST:)
❌ checkpatch
Root cause: Commit 9f58f50 uses undocumented DT vendor prefix "pciclass" in compatible string.
Failure details:
Commit 9f58f5022088 ("BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge")
WARNING: DT compatible string vendor "pciclass" appears un-documented
#33: FILE: arch/arm64/boot/dts/qcom/sc7280.dtsi:2336:
+ compatible = "pciclass,0604";
9f58f5022088024885051d3ba99bdd4a0551cd8b total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Fix: Add "pciclass" vendor prefix to Documentation/devicetree/bindings/vendor-prefixes.yaml:
git rebase -i <base_sha># mark commit 9f58f5022088 as 'edit'# Edit Documentation/devicetree/bindings/vendor-prefixes.yaml# Add entry: "^pciclass,.*": { description: "PCI class-based compatible strings" }
git add Documentation/devicetree/bindings/vendor-prefixes.yaml
git commit --amend --no-edit
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..9f58f5022088
❌ dtb-check
Root cause: Pre-existing tree issues exposed by building the new overlay DTB — missing bindings for qcom,sc7280-inline-crypto-engine and smsc,usb4604, plus recurring pwm:nvmem and pinctrl validation issues.
Failure details:
Log Summary: Test failed
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: /soc@0/crypto@7c8000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: /soc@0/crypto@1d88000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: /soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@1/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb: /soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@2/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
pmic@2 (qcom,pm8350c): pwm:nvmem: [[401, 402]] is too short
pwm (qcom,pm8350c-pwm): nvmem: [[401, 402]] is too short
pinctrl@f100000 (qcom,sc7280-pinctrl): gp_mn_active-state: 'oneOf' conditional failed
Analysis: These are pre-existing tree issues, not introduced by this PR:
Missing qcom,sc7280-inline-crypto-engine binding — This compatible string is used in sc7280.dtsi (inherited by the overlay) but has no binding YAML. This is a known recurring issue (see log-patterns.md Section 8, Issue 4).
Missing smsc,usb4604 binding — The USB hub device on the rb3gen2 board has no binding YAML. Pre-existing in the base tree.
pwm:nvmem too short — The qcom,pm8350c-pwm binding requires more nvmem cells than [401, 402] provides. This is a known recurring issue (see log-patterns.md Section 8, Issue 3).
gp_mn_active-state pinctrl validation — The pinctrl state definition doesn't match the binding's oneOf schema. Pre-existing in the base tree.
Fix: These issues exist in the base tree and are not caused by this PR. They should be fixed separately:
Add Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml covering qcom,sc7280-inline-crypto-engine
Add Documentation/devicetree/bindings/usb/smsc,usb4604.yaml for the USB hub
Fix the pwm:nvmem cell count in the PMIC device tree or binding
Fix the gp_mn_active-state pinctrl definition to match the binding schema
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
❌ check-patch-compliance
Root cause: Two BACKPORT commits have content differences from their upstream Link references.
Failure details:
Checking commit: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Change is different from the one mentioned in Link
Checking commit: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Change is different from the one mentioned in Link
Analysis: Both commits are marked as BACKPORT:, which indicates they are adapted from upstream. The checker detected differences between the PR patches and the upstream lore.kernel.org patches referenced in the Link: tags.
Commits affected:
Commit 6e6f15d - BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Commit 3e3c491 - BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Fix: This is expected behavior for BACKPORT commits — they are intentionally modified from upstream. The BACKPORT: prefix signals that adaptations were made. However, to satisfy the checker and document the changes:
Option A (Recommended): Add a note in the commit message explaining the backport adaptations:
[ Upstream commit <sha> ]
Changes from upstream:
- <describe adaptation 1>
- <describe adaptation 2>
Option B: Verify the differences are legitimate backport adaptations (not errors):
b4 am --single-message -C -l -3 <link> -o /tmp/upstream
git format-patch -1 <sha> --stdout > /tmp/pr-patch
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch | grep -E '^[+-][^+-]') \
<(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')
Option C: If the differences are unintentional, fetch the upstream patch and reapply:
b4 am --single-message -C -l -3 <link> -o /tmp/out
git am /tmp/out/*.mbx
Reproduce locally:
# For commit 6e6f15d66e39:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com -o /tmp/bt-qca
# For commit 3e3c491e42c5:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com -o /tmp/bt-uart
Verdict
3 blockers to address before merge:
checkpatch (minor): Add "pciclass" vendor prefix to vendor-prefixes.yaml in commit 9f58f50
check-patch-compliance (documentation): Document backport adaptations in commit messages for commits 6e6f15d and 3e3c491, or verify differences are intentional
dtb-check (pre-existing, non-blocking for this PR): The DTB validation failures are pre-existing tree issues not introduced by this PR. They should be fixed in separate patches but do not block this PR.
Recommendation: Fix items 1 and 2 above. Item 3 (dtb-check) can be addressed separately as these are baseline tree issues that affect multiple boards and should be fixed at the tree level, not in this PR.

Shiraz Hashim (shashim-quic)

CRs-Fixed: 4615698

remove this line from all commit log, and confine it to only PR description. That will be sufficient.

qlijarvis · 2026-07-31T15:50:53Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

Lore link present: Yes — all 4 commits have valid lore.kernel.org links to the v2 series posted 2026-07-27
Lore link matches PR commits: Yes — diff content is faithful to lore with documented backport adaptations (partial scope for commit 1/4, file path changes for commits 3/4 and 4/4)
Upstream patch status: ⏳ Decision Pending — series posted 2026-07-27; no maintainer merge/NAK signals found in lore threads; Reviewed-by present on commit 3/4
PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand
🔍 Patch Validation
PR:#843 — Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial (4 commits)
Upstream series:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com
Verdict:⚠️ PARTIAL
Commit 1/4: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 2/6] Bluetooth: qca: add QCC2072 support
Commit Message
Check Status Note
Subject matches upstream ⚠️ PR: "update QCC2072 NVM handling" vs Lore: "add QCC2072 support" — subject rewritten to reflect partial backport scope
Body preserves rationale ✅ Key rationale preserved; backport note explains scope reduction
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Vivek Sahu matches lore author
Backport note ✅ [qcom-6.18.y: hci_qca QCC2072 registration from the upstream patch is already present, so keep only the btqca NVM and calibration update.] — clear scope explanation
Co-developed-by correct ✅ Vivek (author), Yepuri Siddu, Rahul Samana — all present with Signed-off-by
Diff
File Status Notes
drivers/bluetooth/btqca.c ✅ Faithful adaptation — refactors inline QCC2072 calibration code into qca_combine_nvm_calib() helper and adds board ID-based NVM/calibration file selection; hci_qca registration code omitted per backport note
drivers/bluetooth/btqca.h ✅ Adds calib_name[64] field to qca_fw_config struct — matches lore
Upstream patch status: ⏳ Decision Pending — posted 2026-07-27; no maintainer decision signals found in lore thread
qcom-next/topics presence: ✅ Present in topics (per integration_presence_report.md)
Commit 2/4: FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU and M.2 PCI node
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 4/6] arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU and M.2 PCI node
Commit Message
Check Status Note
Subject matches upstream ✅ Identical
Body preserves rationale ✅ Rationale preserved
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note N/A FROMLIST: prefix — no backport note needed
Diff
File Status Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts ✅ Adds labels wcn6750_pmu: and pcie0_m2_e: — matches lore exactly
Upstream patch status: ⏳ Decision Pending — posted 2026-07-27; no maintainer decision signals found
qcom-next/topics presence: ✅ Present in topics
Commit 3/4: BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-5-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 5/6] arm64: dts: qcom: kodiak: mark PCIe root port as bridge
Commit Message
Check Status Note
Subject matches upstream ⚠️ PR: "sc7280" vs Lore: "kodiak" — file path differs due to tree structure
Body preserves rationale ✅ Rationale preserved; backport note explains file path difference
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note ✅ [qcom-6.18.y: upstream applies this change to kodiak.dtsi, while this branch still carries the PCIe root port node in sc7280.dtsi.] — explains file path adaptation
Reviewed-by preserved ✅ Reviewed-by: Konrad Dybcio present in both
Diff
File Status Notes
arch/arm64/boot/dts/qcom/sc7280.dtsi ✅ Adds compatible = "pciclass,0604"; to pcie0_port node — semantic change matches lore (file path adapted per backport note)
Upstream patch status: ⏳ Decision Pending — posted 2026-07-27; Reviewed-by present but no merge signal
qcom-next/topics presence: ❌ Missing from both qcom-next and topics (per integration_presence_report.md)
Commit 4/4: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Lore patch: [PATCH v2 6/6] arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Commit Message
Check Status Note
Subject matches upstream ✅ Identical
Body preserves rationale ✅ Rationale preserved; backport note explains overlay filename change
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note ✅ [qcom-6.18.y: replace the old downstream m2-cologne overlay target and file with the generic BT UART overlay name used by the upstream-posted series.] — explains filename adaptation
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ✅ Renames m2-cologne overlay to bt-uart — matches lore intent (filename adapted per backport note)
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ✅ New overlay file — content matches lore
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso ✅ Deleted (replaced by bt-uart overlay) — matches lore intent
Upstream patch status: ⏳ Decision Pending — posted 2026-07-27; no maintainer decision signals found
qcom-next/topics presence: ✅ Present in topics
Issues Found
Commit 3/4 missing from integration: Commit 3/4 (BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge) is not present in qcom-next or topics branches. This is a dependency for the BT UART overlay (commit 4/4) to function correctly — the PCI bridge compatible property is required for child node matching.
Subject line rewrites: Commits 1/4 and 3/4 have rewritten subject lines to reflect backport scope and file path adaptations. While the backport notes explain these changes, the subject lines no longer match the upstream patches verbatim.
Verdict
Merge with caution. The PR faithfully represents the upstream lore patches with appropriate backport adaptations documented in commit messages. However, commit 3/4 is missing from the integration branches and is a functional dependency for commit 4/4. Recommend:
Verify that commit 3/4 will be included in the next qcom-next integration before merging this PR, or
Merge this PR with the understanding that the BT UART overlay (commit 4/4) will not function correctly until commit 3/4 lands in the integration branch.
Final Summary
Lore link present: Yes — all 4 commits have valid lore.kernel.org links to the v2 series posted 2026-07-27
Lore link matches PR commits: Yes — diff content is faithful to lore with documented backport adaptations (partial scope for commit 1/4, file path changes for commits 3/4 and 4/4)
Upstream patch status: ⏳ Decision Pending — series posted 2026-07-27; no maintainer merge/NAK signals found in lore threads; Reviewed-by present on commit 3/4
PR present in qcom-next/topics: Partial — 3/4 commits present in topics; commit 3/4 missing from both qcom-next and topics (functional dependency issue)
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: 8d5dbc1b17adf8fe86a41adcda686785e73f5414
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] BACKPORT: Bluetooth: qca: update QCC2072 NVM handling partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present
2/4 [PATCH 2/4] FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
3/4 [PATCH 3/4] BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
4/4 [PATCH 4/4] BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
Final Status
overall_status: FAIL
present_commits: 3/4
partial_commits: 0/4
missing_commits: 1/4
topics_checked_for_commits: 4/4
final_summary: PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-31T15:50:55Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 warning: undocumented vendor prefix `pciclass`
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Multiple pre-existing tree issues exposed by new overlay
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	2 commits have content mismatch with upstream
tag-check	✅	All commits have valid prefixes (BACKPORT:/FROMLIST:)

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - Bluetooth and devicetree updates for RB3Gen2 Industrial BT UART
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30640788188
Target branch:qcom-6.18.y
Checker Result Summary
checkpatch ❌ 1 warning: undocumented vendor prefix pciclass
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ❌ Multiple pre-existing tree issues exposed by new overlay
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 2 commits have content mismatch with upstream
tag-check ✅ All commits have valid prefixes (BACKPORT:/FROMLIST:)
❌ checkpatch
Root cause: Commit a7d2be0 uses the undocumented vendor prefix pciclass in a DT compatible string.
Failure details:
WARNING: DT compatible string vendor "pciclass" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml
#32: FILE: arch/arm64/boot/dts/qcom/sc7280.dtsi:2336:
+ compatible = "pciclass,0604";
a7d2be0500f0b61932ca02a35aa977f67941b738 total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Fix: Add the pciclass vendor prefix to Documentation/devicetree/bindings/vendor-prefixes.yaml:
"^pciclass,.*":
description: PCI-SIG defined PCI class code
Alternatively, if pciclass is a standard PCI convention that doesn't require vendor documentation, this may be a false positive. The compatible string pciclass,0604 represents a PCI-to-PCI bridge (class code 0x0604) and is a generic PCI device identifier, not a vendor-specific string.
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1bc9614caed6d787783330f1fbd09003ff6a9741..bd7f67417e722c6e69df086943ae330db36c57e5
❌ dtb-check
Root cause: The new overlay file qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtbo (added in commit dc4a14d) exposes multiple pre-existing tree-wide binding and schema issues.
Failure details:
All errors are for the newly added DTB overlay qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb:
qcom,wcd9370-codec binding issues — Multiple properties not declared in binding:
audio-codec (qcom,wcd9370-codec): qcom,ground-jack-type-normally-closed: 1 is not of type 'boolean'
audio-codec (qcom,wcd9370-codec): Unevaluated properties are not allowed ('qcom,ground-jack-type-normally-closed', 'qcom,hphl-jack-type-normally-closed', 'qcom,micbias1-microvolt', 'qcom,micbias2-microvolt', 'qcom,micbias3-microvolt', 'qcom,micbias4-microvolt', 'qcom,rx-device', 'qcom,tx-device', 'reset-gpios', 'vdd-buck-supply', 'vdd-mic-bias-supply', 'vdd-rxtx-supply' were unexpected)
qcom,sc7280-inline-crypto-engine missing binding (recurring issue from log-patterns.md Section 8):
/soc@0/crypto@7c8000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
/soc@0/crypto@1d88000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
smsc,usb4604 missing binding:
/soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@1/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
/soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@2/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
PCI device unevaluated properties — aspm-no-l1 not declared in PCI device binding:
pcie@0,0 (pci1179,0623): Unevaluated properties are not allowed ('aspm-no-l1' was unexpected)
USB controller binding issue:
usb-controller@0,0 (pci1912,0014): '#address-cells', '#size-cells', 'hub@1', 'hub@2' do not match any of the regexes: '^pinctrl-[0-9]+$'
PWM nvmem array too short (recurring issue from log-patterns.md Section 8):
pmic@2 (qcom,pm8350c): pwm:nvmem: [[401, 402]] is too short
pwm (qcom,pm8350c-pwm): nvmem: [[401, 402]] is too short
GENI UART schema ambiguity — Both interrupts and interrupts-extended present:
serial@990000 (qcom,geni-uart): {...} is valid under each of {'required': ['interrupts-extended']}, {'required': ['interrupts']}
Analysis: These are pre-existing tree issues, not introduced by this PR. The PR adds a new overlay that includes nodes from the base qcs6490-rb3gen2.dtsi, which already has these binding gaps. According to the skill's log-patterns.md Section 8:
qcom,sc7280-inline-crypto-engine missing binding is a known recurring issue
pwm:nvmem too short is a known recurring issue for qcs6490-rb3gen2
qcom,wcd9370-codec unevaluated properties indicate the binding needs updating
Fix: These issues should be fixed in separate patches targeting the base tree:
Add or update Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
Update Documentation/devicetree/bindings/sound/qcom,wcd9370-codec.yaml to declare all used properties
Add Documentation/devicetree/bindings/usb/smsc,usb4604.yaml
Update PCI device binding to allow aspm-no-l1 property
Fix qcom,pm8350c-pwm nvmem cell count in the base DTS
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
❌ check-patch-compliance
Root cause: Two BACKPORT commits have content differences from their upstream lore.kernel.org links.
Failure details:
Commit 1: c5b08e1 — BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Checking commit: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Commit 4: dc4a14d — BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Checking commit: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Analysis: Both commits use the BACKPORT: prefix, which explicitly indicates they are modified from upstream. The BACKPORT: tag means "upstream patch backported with modifications" — content differences are expected and intentional.
The checker's "content mismatch" finding is not a defect for BACKPORT: commits. The checker validates that FROMLIST:/UPSTREAM:/FROMGIT: commits match their upstream source exactly, but BACKPORT: commits are allowed to differ.
Fix: No action required. The BACKPORT: prefix correctly signals that these patches have been adapted from upstream. If the modifications are significant, consider documenting the changes in the commit message body (e.g., "[ Upstream commit abc123 ]" followed by a note about what was changed for the backport).
Reproduce locally:
# Fetch upstream patch
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com -o /tmp/out
# Compare with local commit
git format-patch -1 c5b08e1717b3 --stdout > /tmp/local.patch
diff /tmp/local.patch /tmp/out/*.mbx
Verdict
3 blockers to address before merge:
checkpatch warning — Add pciclass vendor prefix to vendor-prefixes.yaml (or confirm it's a false positive for generic PCI class codes)
dtb-check failures — All are pre-existing tree issues exposed by the new overlay; should be fixed in separate patches, not blocking this PR
check-patch-compliance content mismatch — Not a defect; BACKPORT: commits are expected to differ from upstream
Recommendation: The checkpatch pciclass vendor warning should be investigated. If pciclass,0604 is a standard PCI convention (PCI class code for PCI-to-PCI bridge), this may be acceptable without adding a vendor prefix. The dtb-check failures are pre-existing tree issues and should not block this PR. The check-patch-compliance "failures" are false positives for BACKPORT: commits.

qlijarvis · 2026-08-01T12:21:30Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

Lore link present: Yes — all four commits have valid lore.kernel.org links
Lore link matches PR commits: Partial — Commit 1/4 has authorship chain issues and subject divergence (documented); Commit 3/4 has legitimate file path adaptation (kodiak.dtsi → sc7280.dtsi, documented); Commits 2/4 and 4/4 match upstream
Upstream patch status: ⏳ Decision Pending — all four patches posted 27 Jul 2026; under review; no merge/NAK signals; Reviewed-by tags present for commits 2-4
PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand
🔍 Patch Validation
PR:#843 - Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial
Verdict:⚠️ PARTIAL
Commit 1/4: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Upstream:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ⚠️ Upstream: "Bluetooth: qca: add QCC2072 support"; PR: "update QCC2072 NVM handling" — subject reworded
Body preserves rationale ✅ Key rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ❌ FAIL: Upstream From: Vivek Sahu; PR From: Vivek Sahu but upstream has Co-developed-by: Rahul Samana + Signed-off-by: Rahul Samana as co-authors. PR lists Rahul as final Signed-off-by only, missing Vivek's and Yepuri's Signed-off-by tags from upstream
Backport note present ✅ [qcom-6.18.y: hci_qca QCC2072 registration from the upstream patch is already present, so keep only the btqca NVM and calibration update.]
Diff
File Status Notes
drivers/bluetooth/btqca.c ⚠️ PR omits hci_qca.c changes (QCC2072 registration) — documented in backport note as already present
drivers/bluetooth/btqca.h ✅ Matches upstream
Upstream Patch Status
⏳ Decision Pending — Posted 27 Jul 2026; no maintainer merge/NAK signal found in thread; under review
Integration Presence
✅ Present in topics — integration_presence_report.md: "present - all checked added lines are present"
Issues
Authorship chain incomplete: Upstream patch has three co-authors (Vivek Sahu as primary author, Yepuri Siddu and Rahul Samana as co-developers). PR commit message lists all three but only Rahul's final Signed-off-by is present; Vivek's and Yepuri's Signed-off-by tags are missing.
Subject line divergence: Upstream subject is "add QCC2072 support"; PR subject is "update QCC2072 NVM handling" — reworded to reflect partial backport scope.
Commit 2/4: FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU and M.2 PCI node
Upstream:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Identical
Body preserves rationale ✅ Identical
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches upstream; FROMLIST: prefix correct
Backport note N/A Not a backport
Diff
File Status Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts ✅ Matches upstream exactly
Upstream Patch Status
⏳ Decision Pending — Posted 27 Jul 2026; no maintainer merge/NAK signal; under review
Integration Presence
✅ Present in topics — integration_presence_report.md: "present - all checked added lines are present"
Commit 3/4: BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge
Upstream:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-5-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ⚠️ Upstream: "arm64: dts: qcom: kodiak: mark PCIe root port as bridge"; PR: "sc7280" instead of "kodiak"
Body preserves rationale ✅ Identical
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches upstream
Backport note present ✅ [qcom-6.18.y: upstream applies this change to kodiak.dtsi, while this branch still carries the PCIe root port node in sc7280.dtsi.]
Reviewed-by tag ⚠️ PR includes Reviewed-by: Konrad Dybcio but upstream thread shows this tag was missed in v2 posting
Diff
File Status Notes
arch/arm64/boot/dts/qcom/sc7280.dtsi ⚠️ Legitimate adaptation: Upstream modifies kodiak.dtsi; PR modifies sc7280.dtsi — documented in backport note
Upstream Patch Status
⏳ Decision Pending — Posted 27 Jul 2026; Reviewed-by: Konrad Dybcio present in thread (from v1); no maintainer merge/NAK signal
Integration Presence
❌ Missing — integration_presence_report.md: "missing - no subject, patch-id, or full tree-content match found" in both qcom-next and topics
Commit 4/4: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Upstream:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Identical
Body preserves rationale ✅ Key rationale preserved
Fixes tag present/correct N/A No Fixes tag
Authorship preserved ✅ From: Rahul Samana matches upstream
Backport note present ✅ [qcom-6.18.y: replace the old downstream m2-cologne overlay target and file with the generic BT UART overlay name used by the upstream-posted series.]
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Replaces downstream m2-cologne target with upstream bt-uart target — documented in backport note
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ⚠️ New file; content needs line-by-line comparison (not done here due to size)
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso ⚠️ Deleted (downstream-only file)
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts ⚠️ Modified label reference — needs verification
Upstream Patch Status
⏳ Decision Pending — Posted 27 Jul 2026; Reviewed-by: Konrad Dybcio present in thread (from v1); no maintainer merge/NAK signal
Integration Presence
⚠️Partial — integration_presence_report.md: "partial - subject or partial tree evidence found, but full change was not verified"
Issues
Commit 1/4:
Authorship chain incomplete: Upstream has Signed-off-by: Vivek Sahu, Co-developed-by: Yepuri Siddu + Signed-off-by: Yepuri Siddu, Co-developed-by: Rahul Samana + Signed-off-by: Rahul Samana. PR commit message lists all three in the body but only includes Signed-off-by: Rahul Samana at the end — missing Vivek's and Yepuri's Signed-off-by tags.
Subject divergence: Upstream "add QCC2072 support" vs PR "update QCC2072 NVM handling" — reworded to reflect partial backport scope (documented in backport note).
Commit 3/4:
Missing from integration: Not found in qcom-next or topics — this is a validation failure per the skill requirements.
Commit 4/4:
Partial integration presence: Only partial tree evidence found — full change not verified in qcom-next/topics.
Verdict
⚠️PARTIAL — Merge with corrections required:
Commit 1/4: Add missing Signed-off-by tags for Vivek Sahu and Yepuri Siddu to preserve the full authorship chain from upstream.
Commit 3/4: This commit is missing from both qcom-next and topics — verify whether it should be present or if it's a new addition.
Commit 4/4: Partial integration presence — verify full content matches upstream before merging.
All four commits are still under upstream review (posted 27 Jul 2026); no maintainer merge or NAK signals found. Commits 2/4, 3/4, and 4/4 have Reviewed-by: Konrad Dybcio tags from v1 (though v2 posting missed carrying them forward in some cases).
Final Summary
Lore link present: Yes — all four commits have valid lore.kernel.org links
Lore link matches PR commits: Partial — Commit 1/4 has authorship chain issues and subject divergence (documented); Commit 3/4 has legitimate file path adaptation (kodiak.dtsi → sc7280.dtsi, documented); Commits 2/4 and 4/4 match upstream
Upstream patch status: ⏳ Decision Pending — all four patches posted 27 Jul 2026; under review; no merge/NAK signals; Reviewed-by tags present for commits 2-4
PR present in qcom-next/topics: Fail — Commit 3/4 is missing from both qcom-next and topics; Commit 4/4 has only partial presence; Commits 1/4 and 2/4 are present in 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: 8d5dbc1b17adf8fe86a41adcda686785e73f5414
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] BACKPORT: Bluetooth: qca: update QCC2072 NVM handling partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present
2/4 [PATCH 2/4] FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
3/4 [PATCH 3/4] BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
4/4 [PATCH 4/4] BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial
Final Status
overall_status: FAIL
present_commits: 2/4
partial_commits: 1/4
missing_commits: 1/4
topics_checked_for_commits: 4/4
final_summary: PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-08-01T12:21:31Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 warnings: undocumented vendor prefix, long commit line
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Pre-existing tree issues (wcd9370 codec, inline-crypto-engine, PWM nvmem)
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	2 commits have content mismatch with upstream links
tag-check	✅	All commits have valid prefixes (BACKPORT/FROMLIST)

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - Bluetooth QCC2072 NVM handling and RB3 Gen2 Industrial BT UART overlay
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30697397984
Checker Result Summary
checkpatch ❌ 2 warnings: undocumented vendor prefix, long commit line
dt-binding-check ⏭️ No binding changes
dtb-check ❌ Pre-existing tree issues (wcd9370 codec, inline-crypto-engine, PWM nvmem)
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 2 commits have content mismatch with upstream links
tag-check ✅ All commits have valid prefixes (BACKPORT/FROMLIST)
❌ checkpatch
Root cause: Two style issues across commits 3 and 4.
Failure details:
Commit a7d2be0 ("BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge"):
WARNING: DT compatible string vendor "pciclass" appears un-documented
#32: FILE: arch/arm64/boot/dts/qcom/sc7280.dtsi:2336:
+ compatible = "pciclass,0604";
Commit f62716d ("BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay"):
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: The reworked RB3 Gen 2 Industrial mezzanine keeps the common Industrial mezzanine hardware description but routes QCC2072 Bluetooth over UART4 instead of the default Bluetooth-over-USB path.
Fix:
pciclass vendor prefix: This is a standard PCI class code compatible string used for generic PCI bridge matching. The warning is a false positive — pciclass is a well-known pseudo-vendor for PCI class-based matching and does not require a vendor-prefixes.yaml entry. No action needed.
Long commit line: Wrap the commit body paragraph at 75 characters:
git rebase -i <base_sha># mark commit f62716db4abc as 'edit'
git commit --amend
# Manually wrap the long paragraph in the commit message editor
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1bc9614caed6..fdd4dce6258f
❌ dtb-check
Root cause: Pre-existing tree issues exposed when building the new qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb target.
Failure details:
The new overlay qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso is applied on top of the base qcs6490-rb3gen2.dts, which includes the industrial mezzanine hardware description. The dtb-check failures are not introduced by this PR — they are pre-existing issues in the base tree:
qcom,wcd9370-codec binding issues (audio-codec node):
qcom,ground-jack-type-normally-closed: 1 is not of type 'boolean'
qcom,hphl-jack-type-normally-closed: 1 is not of type 'boolean'
Unevaluated properties: 'qcom,micbias1-microvolt', 'qcom,micbias2-microvolt', 'qcom,micbias3-microvolt', 'qcom,micbias4-microvolt', 'qcom,rx-device', 'qcom,tx-device', 'reset-gpios', 'vdd-buck-supply', 'vdd-mic-bias-supply', 'vdd-rxtx-supply'
→ The wcd9370 codec binding uses integer values 1 for boolean properties and has many vendor-specific properties not declared in the binding schema.
qcom,sc7280-inline-crypto-engine missing binding:
/soc@0/crypto@7c8000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
/soc@0/crypto@1d88000: failed to match any schema with compatible: ['qcom,sc7280-inline-crypto-engine', 'qcom,inline-crypto-engine']
→ No binding YAML exists for the inline crypto engine nodes.
qcom,pm8350c-pwm nvmem array too short:
pmic@2 (qcom,pm8350c): pwm:nvmem: [[401, 402]] is too short
pwm (qcom,pm8350c-pwm): nvmem: [[401, 402]] is too short
→ The PWM nvmem property has fewer cells than the binding requires.
smsc,usb4604 missing binding:
/soc@0/geniqup@9c0000/i2c@984000/i2c-mux@71/i2c@1/usb-hub@2d: failed to match any schema with compatible: ['smsc,usb4604']
aspm-no-l1 unevaluated property on PCIe nodes (pci1179,0623).
serial@990000 (qcom,geni-uart) has both interrupts and interrupts-extended (schema ambiguity).
These are all recurring tree-wide issues documented in references/log-patterns.md Section 8. They appear because the new dtb target builds on top of the existing industrial mezzanine hardware description, which has these pre-existing schema validation failures.
Fix: None required for this PR. These are baseline tree issues that should be fixed separately:
Update the wcd9370 codec binding to accept integer boolean values and declare all vendor properties
Add binding YAML for qcom,sc7280-inline-crypto-engine
Fix the pm8350c PWM nvmem cell count
Add binding for smsc,usb4604
Update PCI bindings to allow aspm-no-l1
Resolve the geni-uart schema ambiguity
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
❌ check-patch-compliance
Root cause: Two BACKPORT commits have content differences from their upstream lore links.
Failure details:
Commit c5b08e1 ("BACKPORT: Bluetooth: qca: update QCC2072 NVM handling"):
Checking commit: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Commit f62716d ("BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay"):
Checking commit: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com
Fix:
Both commits are correctly tagged as BACKPORT: and include adaptation notes in the commit message explaining the differences:
Commit 1: [qcom-6.18.y: hci_qca QCC2072 registration from the upstream patch is already present, so keep only the btqca NVM and calibration update.]
Commit 4: [qcom-6.18.y: replace the old downstream m2-cologne overlay target and file with the generic BT UART overlay name used by the upstream-posted series.]
The BACKPORT: prefix correctly signals that these are adapted versions of upstream patches. The checker's content-mismatch detection is working as intended — it flags that the patches differ from upstream, which is expected for backports.
No action needed. The commits are properly attributed and documented. The check-patch-compliance checker does not distinguish between legitimate backport adaptations and unintended content drift — this is a known limitation when using BACKPORT: prefix.
Reproduce locally:
# Fetch upstream patch
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com -o /tmp/out
# Compare diff hunks
git format-patch -1 c5b08e1717b3 --stdout > /tmp/pr-patch.txt
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch.txt | grep -E '^[+-][^+-]') \
<(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')
Verdict
3 blockers to fix before merge:
checkpatch: Wrap the long commit message line in commit f62716d (commit 4).
dtb-check: Pre-existing tree issues — not blockers for this PR. These should be fixed in separate patches targeting the base tree (wcd9370 binding, inline-crypto-engine binding, pm8350c PWM nvmem, smsc usb4604 binding).
check-patch-compliance: Content mismatch is expected for BACKPORT: commits — not a blocker. The commits are properly documented with adaptation notes.
Recommendation: Fix the single checkpatch warning (long commit line), then merge. The dtb-check failures are pre-existing tree issues that do not block this PR.

QCC2072 uses the ORN firmware and NVM naming scheme. The RB3 Gen 2 Industrial BT-over-UART setup also needs the BCS calibration TLV to be combined with the selected NVM before download. Keep the BCS/NVM combination in a helper so missing calibration data or allocation failures can fall back to downloading the NVM alone without a local skip label. Select the NVM file and BCS calibration file using the controller board ID when available, with fallback to the default files. Initialize the BCS calibration filename independently of the NVM filename source so custom NVM firmware-name paths do not leave it unset. [qcom-6.18.y: hci_qca QCC2072 registration from the upstream patch is already present, so keep only the btqca NVM and calibration update.] Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com> Co-developed-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com> Signed-off-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com> Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com

The reworked RB3 Gen 2 Industrial BT UART overlay needs to disable the on-board WCN6750 PMU. Label the exact WCN6750 PMU node so the overlay can patch it directly. [qcom-6.18.y: keep only the BT PMU label from the upstream-posted label patch; the M.2 PCIe graph endpoint is modelled from the overlay using the nested PCIe port path.] Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com

The PCI core needs to associate the DT node below the QCS6490 PCIe host bridge with the enumerated PCI-to-PCI bridge device before child nodes can be matched against the PCI topology. Add compatible = "pciclass,0604" to pcie0_port so child nodes below the bridge can be matched by the PCI device class. [qcom-6.18.y: upstream applies this change to kodiak.dtsi, while this branch still carries the PCIe root port node in sc7280.dtsi.] Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-5-2d100f30e202@oss.qualcomm.com

The reworked RB3 Gen 2 Industrial mezzanine keeps the common Industrial mezzanine hardware description but routes QCC2072 Bluetooth over UART4 instead of the default Bluetooth-over-USB path. Build this variant by applying the common Industrial mezzanine overlay first, followed by the BT UART overlay. The overlay models the M.2 E-key connector graph endpoints for PCIe and UART, and disables the on-board WCN6750 PMU and UART7 path so the M.2 QCC2072 Bluetooth controller can be used instead. [qcom-6.18.y: replace the old downstream m2-cologne overlay target and file with the generic BT UART overlay name used by the upstream-posted series.] Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com

Rahul Samana (rahul-samana) · 2026-08-01T14:47:29Z

CRs-Fixed: 4615698
remove this line from all commit log, and confine it to only PR description. That will be sufficient.

Done. Removed the CRs-Fixed: 4615698 line from all the commit messages and kept only in PR description.

qlijarvis · 2026-08-01T15:42:27Z

PR #843 — validate-patch

PR:#843

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

Lore link present: Yes — all 4 commits have valid lore.kernel.org links
Lore link matches PR commits: Yes — diff content faithful to lore with documented adaptations (partial backports, tree structure differences, vendor cleanup)
Upstream patch status: ⏳ Decision Pending — 1/4 ACKed (Konrad Dybcio), 3/4 under review; series posted 2026-07-27, no maintainer merge/NAK decisions yet for most patches
PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand
🔍 Patch Validation
PR:#843 - Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial (4 commits)
Upstream commit:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com (v2 series)
Verdict:⚠️ PARTIAL
Commit 1/4: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Adapted: "add QCC2072 support" → "update QCC2072 NVM handling" (reflects partial backport)
Body preserves rationale ✅ Key technical rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Vivek Sahu matches lore
Backport note (if applicable) ✅ Clear note explaining hci_qca changes omitted
Diff
File Status Notes
drivers/bluetooth/btqca.c ✅ Faithful to lore patch for btqca.c changes
drivers/bluetooth/btqca.h ✅ Faithful to lore patch for btqca.h changes
drivers/bluetooth/hci_qca.c ⚠️ Intentionally omitted — backport note explains hci_qca QCC2072 registration already present in target tree
Issues
Missing Co-developed-by: Lore patch includes Co-developed-by: Rahul Samana <rahul.samana@oss.qualcomm.com> but PR commit omits this and only has Rahul's Signed-off-by:. Since Rahul is listed as co-developer in the upstream patch, the PR should preserve this attribution.
Commit 2/4: BACKPORT: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU node
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-4-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Adapted: "label BT PMU and M.2 PCI node" → "label BT PMU node" (reflects partial backport)
Body preserves rationale ✅ Rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note (if applicable) ✅ Clear note explaining M.2 PCIe graph endpoint omitted
Diff
File Status Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts ✅ Faithful to lore patch for BT PMU label; M.2 PCI node label intentionally omitted per backport note
Commit 3/4: BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-5-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Adapted: "kodiak" → "sc7280" (reflects target tree structure)
Body preserves rationale ✅ Technical rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note (if applicable) ✅ Clear note explaining kodiak.dtsi → sc7280.dtsi adaptation
Diff
File Status Notes
arch/arm64/boot/dts/qcom/sc7280.dtsi ✅ Legitimate adaptation — lore applies to kodiak.dtsi, PR applies to sc7280.dtsi (different tree structure); change content identical
Commit 4/4: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Lore link:https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-6-2d100f30e202@oss.qualcomm.com
Commit Message
Check Status Note
Subject matches upstream ✅ Identical
Body preserves rationale ✅ Rationale preserved
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ✅ From: Rahul Samana matches lore
Backport note (if applicable) ✅ Clear note explaining downstream overlay file replacement
Diff
File Status Notes
arch/arm64/boot/dts/qcom/Makefile ⚠️ Vendor-specific adaptation — replaces old downstream m2-cologne overlay with new bt-uart overlay; lore patch only adds new overlay without removing old file
qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtso ✅ New overlay content faithful to lore patch
qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso ⚠️ Deleted — vendor-specific cleanup not present in upstream patch
Upstream Patch Status
Commit Community Verdict
1/4 (lore v2 2/6) ⏳ Decision Pending — posted 2026-07-27; AI review raised concerns about nested Type 4 TLV headers; no maintainer merge/NAK decision yet
2/4 (lore v2 4/6) ⏳ Decision Pending — posted 2026-07-27; no maintainer decision yet
3/4 (lore v2 5/6) ✅ ACKed — Reviewed-by: Konrad Dybcio konrad.dybcio@oss.qualcomm.com
4/4 (lore v2 6/6) ⏳ Decision Pending — posted 2026-07-27; active discussion ongoing; no maintainer merge/NAK decision yet
Note: Lore patch v2 1/6 (dt-bindings) received a NAK from Krzysztof Kozlowski but is not included in this PR.
Integration Presence (from integration_presence_report.md)
Commit Status
1/4 ✅ Present in topics — all checked added lines present
2/4 ✅ Present in topics — all checked added lines present
3/4 ❌ Missing — not found in qcom-next or topics
4/4 ⚠️ Partial — subject or partial tree evidence found in topics, but full change not verified
Overall: FAIL — 1/4 commit missing from both qcom-next and topics; 1/4 commit only partially verified.
Issues
Commit 1/4 — Missing Co-developed-by: Lore patch includes Co-developed-by: Rahul Samana but PR omits this. Rahul should be listed as co-developer since he appears as such in the upstream patch.
Commit 4/4 — Vendor-specific file deletion: PR deletes qcs6490-rb3gen2-industrial-mezzanine-m2-cologne.dtso which is not part of the upstream patch. This is vendor tree cleanup and should be documented or split into a separate QCLINUX: commit.
Integration presence failure: Commit 3/4 is missing from both qcom-next and topics branches. This suggests the patch may not have landed in the integration tree yet, or the tree structure difference (sc7280.dtsi vs kodiak.dtsi) prevented detection.
Verdict
Merge with minor corrections:
Add Co-developed-by: Rahul Samana <rahul.samana@oss.qualcomm.com> to commit 1/4 before his Signed-off-by line.
Document the vendor-specific file deletion in commit 4/4's backport note, or split it into a separate QCLINUX: commit.
Investigate why commit 3/4 is not detected in qcom-next/topics — verify the sc7280.dtsi vs kodiak.dtsi tree structure difference is intentional for this branch.
The backports are technically faithful to their lore sources with documented adaptations. The upstream patches are under active review (3/4 already ACKed by Konrad Dybcio). The missing Co-developed-by attribution and undocumented vendor cleanup are minor hygiene issues that should be corrected before merge.
Final Summary
Lore link present: Yes — all 4 commits have valid lore.kernel.org links
Lore link matches PR commits: Yes — diff content faithful to lore with documented adaptations (partial backports, tree structure differences, vendor cleanup)
Upstream patch status: ⏳ Decision Pending — 1/4 ACKed (Konrad Dybcio), 3/4 under review; series posted 2026-07-27, no maintainer merge/NAK decisions yet for most patches
PR present in qcom-next/topics: Fail — 1/4 commit missing from both qcom-next and topics; 1/4 commit only partially verified; 2/4 commits present in 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: 8d5dbc1b17adf8fe86a41adcda686785e73f5414
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched
Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] BACKPORT: Bluetooth: qca: update QCC2072 NVM handling partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present
2/4 [PATCH 2/4] BACKPORT: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
3/4 [PATCH 3/4] BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
4/4 [PATCH 4/4] BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT missing - no subject, patch-id, or full tree-content match found partial - subject or partial tree evidence found, but full change was not verified partial
Final Status
overall_status: FAIL
present_commits: 2/4
partial_commits: 1/4
missing_commits: 1/4
topics_checked_for_commits: 4/4
final_summary: PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-08-01T15:42:29Z

PR #843 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	3 commits with style warnings
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Pre-existing tree issues only
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	3 commits with content mismatch
tag-check	✅	All commits have BACKPORT: prefix

Detailed report: Full report

Checker analysis — click to expand
🤖 CI Checker Analysis (checker-log-analyzer)
PR:#843 - Add Industrial BT UART overlay for RB3 Gen2
Source:https://github.com/qualcomm-linux/kernel-config/actions/runs/30704437278
Target branch:qcom-6.18.y
Checker Result Summary
checkpatch ❌ 3 commits with style warnings
dt-binding-check ⏭️ No binding changes
dtb-check ❌ Pre-existing tree issues only
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 3 commits with content mismatch
tag-check ✅ All commits have BACKPORT: prefix
❌ checkpatch
Root cause: Three commits have commit message formatting warnings (long lines in commit body).
Failure details:
Commit d04e4fd ("BACKPORT: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU node"):
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: The reworked RB3 Gen 2 Industrial BT UART overlay needs to disable the on-board WCN6750 PMU.
Commit 9fe0677 ("BACKPORT: arm64: dts: qcom: sc7280: mark PCIe root port as bridge"):
WARNING: DT compatible string vendor "pciclass" appears un-documented
#32: FILE: arch/arm64/boot/dts/qcom/sc7280.dtsi:2336:
+ compatible = "pciclass,0604";
Commit a235b6a ("BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay"):
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: The reworked RB3 Gen 2 Industrial mezzanine keeps the common Industrial mezzanine hardware description but routes QCC2072 Bluetooth over UART4 instead of the default Bluetooth-over-USB path.
Fix:
For the long-line warnings (commits d04e4fd and a235b6a):
git rebase -i 1bc9614caed6d787783330f1fbd09003ff6a9741
# Mark each commit as 'edit'# Wrap the commit body lines at 75 characters
git commit --amend
git rebase --continue
For the pciclass vendor warning (commit 9fe0677):
This is a false positive. pciclass is a special PCI-defined vendor prefix for generic PCI class-based matching and does not need to be documented in vendor-prefixes.yaml. This is standard PCI devicetree practice.
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1bc9614caed6..71c9e3f4bcc5
❌ dtb-check
Root cause: All reported errors are pre-existing tree issues, not introduced by this PR.
Failure details:
The dtb-check log shows errors only for the new DTB file qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb. These errors fall into known recurring categories documented in the skill's log-patterns reference:
qcom,sc7280-inline-crypto-engine missing binding — recurring tree-wide issue (Section 8, Issue 4 of log-patterns.md)
qcom,pm8350c-pwm nvmem too short — recurring tree-wide issue (Section 8, Issue 3)
qcom,wcd9370-codec unevaluated properties — pre-existing binding incompleteness
pci1179,0623 aspm-no-l1 unevaluated — pre-existing PCI binding issue
smsc,usb4604 missing binding — pre-existing tree issue
qcom,geni-uart interrupts/interrupts-extended ambiguity — pre-existing schema issue
Analysis: The PR adds a new overlay DTB that inherits the base qcs6490-rb3gen2.dts tree. The errors reported are not new — they exist in the base tree and are exposed when the new DTB is built. The checker's baseline subtraction should have filtered these out, but since this is a new DTB file (not present at base_sha), the checker cannot diff against a baseline.
Verdict: These are not blockers for this PR. The errors are pre-existing tree issues that should be fixed separately.
Reproduce locally:
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-bt-uart.dtb
❌ check-patch-compliance
Root cause: Three commits report "Change is different from the one mentioned in Link" — the PR patches have been adapted from upstream and differ from the lore.kernel.org versions.
Failure details:
Checking commit: BACKPORT: Bluetooth: qca: update QCC2072 NVM handling
Change is different from the one mentioned in Link
Checking commit: BACKPORT: arm64: dts: qcom: qcs6490-rb3gen2: label BT PMU node
Change is different from the one mentioned in Link
Checking commit: BACKPORT: arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Change is different from the one mentioned in Link
Analysis: All three commits use the BACKPORT: prefix, which explicitly signals that the patches have been modified from their upstream versions. The content differences are expected and legitimate for backports. The checker's content-match logic does not account for the BACKPORT: semantic — it treats BACKPORT: the same as FROMLIST: and expects byte-for-byte match.
Verdict: This is a known checker limitation for BACKPORT: commits. The failures are not blockers — the BACKPORT: prefix correctly documents that these patches differ from upstream.
Reproduce locally:
# Fetch upstream patch
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260727-rb3-industrial-bt-uart-v2-2-2d100f30e202@oss.qualcomm.com -o /tmp/out
# Compare with PR commit
git format-patch -1 e71e4432642e --stdout > /tmp/pr.patch
diff /tmp/pr.patch /tmp/out/*.mbx
Recommendation
2 non-blocking issues to fix before merge:
checkpatch long-line warnings (commits d04e4fd, a235b6a) — wrap commit body lines at 75 characters.
(Optional) Document the nature of the backport adaptations in the commit messages for clarity.
Non-blockers (no action needed):
checkpatchpciclass vendor warning → false positive (standard PCI practice)
dtb-check errors → pre-existing tree issues, not introduced by this PR
check-patch-compliance content mismatch → expected for BACKPORT: commits; checker limitation
Overall verdict: Fix the 2 commit message formatting issues, then ready to merge.

qcomlnxci · 2026-08-06T07:26:27Z

Test jobs on a235b6a

qcomlnxci · 2026-08-06T07:26:29Z

Test Matrix

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

qcomlnxci · 2026-08-18T10:48:20Z

Test jobs on a235b6a

qcomlnxci · 2026-08-18T10:48:22Z

Test Matrix

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

quic-mohamull · 2026-08-19T11:01:11Z

Change is approved since long time, please merge changes

qcomlnxci · 2026-08-19T15:55:10Z

Test Matrix

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

qcomlnxci · 2026-08-19T15:55:10Z

Test jobs on a235b6a

qlijarvis · 2026-08-21T14:54:37Z

LAVA Failed Case Triage Summary

PR: #843

Job 207555 | SoC qcs9100-ride

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

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

Case 1: Kernel Crash — Synchronous External Abort during SMMU Probe
Failed case: Kernel Crash — Synchronous External Abort during SMMU Probe
Root cause: Hardware bus error (synchronous external abort) when writing to SMMU S2CR register at 15000000.iommu during device probe. The SMMU hardware at address 0x15000000 returned a bus error when the kernel attempted to write Stream-to-Context Register (S2CR) via qcom_smmu_write_s2cr+0x84/0x140, indicating the SMMU register space is not accessible — likely due to missing power/clock configuration, incorrect device tree mapping, or hardware/firmware issue on qcs9100-ride platform.
Possible fix: This is a pre-existing qcs9100-ride platform issue unrelated to the PR (which only modifies qcs6490/sc7280 device trees and Bluetooth driver). Verify SMMU power domain and clock configuration in qcs9100-ride device tree; check that SMMU GDSC is enabled and clocks are configured before SMMU probe; if issue persists, collect SMMU register dump via JTAG/SDI to confirm hardware state and escalate to platform/firmware team for qcs9100 SMMU initialization sequence review.
Detail analysis attachment: failed_case_job207555_1_detailed.md

Case 2: Kernel Crash — Synchronous External Abort during SMMU S2CR Register Write
Failed case: Kernel Crash — Synchronous External Abort during SMMU S2CR Register Write
Root cause: Hardware bus fault (synchronous external abort 0x0000000096000010) occurred when the SMMU driver attempted to write to the S2CR (Stream-to-Context Register) at offset 0xc28 during device probe on qcs9100-ride. The fault happened while setting up IOMMU group 15 for the remoteproc device at 30000000. This indicates the SMMU register space at address 0x15000c28 (base 0x15000000 + offset 0xc28) is either not accessible, not powered, or the hardware is in an unexpected state.
Possible fix: This is a pre-existing platform/hardware issue unrelated to the PR (which only modifies Bluetooth drivers and device trees for different SoCs). Immediate action: Check SMMU power domain and clock configuration in the qcs9100-ride device tree — verify that the SMMU at 0x15000000 has all required power domains enabled and clocks running before register access. Verify bootloader/firmware has correctly initialized the SMMU hardware. If the issue is reproducible, enable CONFIG_IOMMU_TLBSYNC_DEBUG and CONFIG_ARM_SMMU_TESTBUS_DUMP to capture detailed SMMU register state, then collect SMMU_TBU_PWR_STATUS and SMMU_SAFE_SEC_CFG registers via crash dump to determine if the SMMU is powered off or in a safe/locked state.
Detail analysis attachment: failed_case_job207555_2_detailed.md

Case 3: Kernel Crash — Synchronous External Abort during SMMU Initialization
Failed case: Kernel Crash — Synchronous External Abort during SMMU Initialization
Root cause: Synchronous external abort (bus error) at qcom_smmu_write_s2cr+0x84/0x140 during SMMU device probe while writing Stream-to-Context Register for remoteproc device (iommu group 15); indicates SMMU register address is inaccessible, likely due to SMMU hardware not being properly powered/clocked or device tree misconfiguration on qcs9100-ride platform.
Possible fix: Verify qcs9100-ride device tree SMMU node configuration (register base address, clocks, power domains); ensure SMMU hardware is properly initialized before device probe; check if SMMU driver probe order or dependencies are correct; this is a platform-specific issue unrelated to the PR changes (which target qcs6490-rb3gen2 Bluetooth/PCIe).
Detail analysis attachment: failed_case_job207555_3_detailed.md

Case 4: Kernel Crash — SMMU synchronous external abort during probe
Failed case: Kernel Crash — SMMU synchronous external abort during probe
Root cause: SMMU hardware access fault during qcom_smmu_write_s2cr() register write at boot time on qcs9100-ride; synchronous external abort (0x96000010) indicates the SMMU register at offset 0xc28 is not accessible, likely due to SMMU power domain not enabled, clock not running, or hardware not responding.
Possible fix: Verify SMMU power domain and clock dependencies in qcs9100-ride device tree; ensure SMMU GDSC and clocks are enabled before driver probe; if issue persists, check for hardware errata or board-specific SMMU configuration requirements for qcs9100 SoC.
Detail analysis attachment: failed_case_job207555_4_detailed.md

Job 207556 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check
Failed case: Probe_Failure_Check
Root cause: The test detected 6 probe/firmware-related errors during boot on monaco-evk (iq-8275-evk): (1) cpufreq-dt probe failed with -EEXIST (-17), indicating duplicate registration; (2) Bluetooth firmware files qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv missing (-ENOENT); (3) regulatory.db firmware missing; (4) WiFi firmware ath11k/WCN6855/hw2.1/nfa765/amss.bin missing; (5) ath11k_pci probe failed with -ETIMEDOUT (-110), likely due to missing firmware preventing device initialization. The PR introduces Bluetooth QCC2072 NVM handling changes and device tree modifications for RB3 Gen2 Industrial, but the test ran on monaco-evk (SC8275 platform) where these changes do not apply and the failures are pre-existing platform/firmware packaging issues unrelated to the PR.
Possible fix: Mark Probe_Failure_Check as a known benign failure for monaco-evk until firmware packaging is corrected. The cpufreq-dt -EEXIST error is harmless (fallback mechanism working as designed). The Bluetooth firmware fallback paths in the PR (qca/wcnhpbtfw21.tlv → qca/hpbtfw21.tlv) are correctly implemented but the files are absent from the rootfs. The WiFi failure (ath11k_pci -110) is a consequence of missing firmware and is unrelated to the PR's Bluetooth changes. To resolve: (1) add missing firmware files to the monaco-evk rootfs image, or (2) suppress these specific probe failures in the Probe_Failure_Check test for monaco-evk, as they do not indicate a kernel regression introduced by this PR.
Detail analysis attachment: failed_case_job207556_1_detailed.md

Case 2: WiFi_Firmware_Driver
Failed case: WiFi_Firmware_Driver
Root cause: Could not be determined confidently from available logs.
Possible fix: Add the missing WCN6855 hw2.1 board-specific firmware variant (nfa765/amss.bin and associated files) to the linux-firmware package or rootfs overlay used by the monaco-evk LAVA job; verify the firmware path matches the driver's board ID detection logic; re-run the LAVA job to confirm WiFi probe succeeds.
Detail analysis attachment: failed_case_job207556_2_detailed.md

Case 3: WiFi_OnOff
Failed case: WiFi_OnOff
Root cause: Could not be determined confidently from available logs.
Possible fix: Add the linux-firmware-ath11k package (or equivalent) to the Monaco EVK Yocto image recipe to include WCN6855 hw2.1 firmware files. Alternatively, if WiFi is not required on Monaco EVK, suppress this test case for this platform or mark it as expected-fail until firmware is added.
Detail analysis attachment: failed_case_job207556_3_detailed.md

Case 4: 0_qcom-next-ci-premerge-tests
Failed case: 0_qcom-next-ci-premerge-tests
Root cause: LAVA test suite completed but was marked as failed because the test runner detected "unfinished" state. The underlying genuine failures are: (1) ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) during device initialization, preventing WiFi functionality; (2) missing firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv, regulatory.db, ath11k/WCN6855/hw2.1/nfa765/amss.bin) reported as -ENOENT errors; (3) cpufreq-dt probe failed with -EEXIST (benign, driver already registered). The WiFi probe timeout is the critical failure affecting Monaco EVK's WCN6855 PCIe WiFi module.
Possible fix: The ath11k_pci probe timeout (-110) indicates the WiFi device failed to respond during MHI initialization. This is likely a pre-existing platform/firmware issue unrelated to the PR's Bluetooth NVM changes. Verify: (1) WCN6855 PCIe device is properly powered and enumerated (lspci); (2) MHI firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin) is present in the rootfs; (3) check for PCIe link training failures or power sequencing issues in dmesg. The PR changes only affect Bluetooth QCC2072 NVM handling and should not impact ath11k_pci WiFi driver. Re-trigger the CI job to confirm if this is a transient hardware/lab issue.
Detail analysis attachment: failed_case_job207556_4_detailed.md

Job 207557 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check
Failed case: Probe_Failure_Check
Root cause: Could not be determined confidently from available logs.
Possible fix: Add the regulatory.db firmware file to the rootfs image at /lib/firmware/regulatory.db to eliminate the warning. Alternatively, update the Probe_Failure_Check test to suppress this specific false positive, as it does not indicate a functional regression. The PR itself requires no changes.
Detail analysis attachment: failed_case_job207557_1_detailed.md

Case 2: smmu
Failed case: smmu
Root cause: Test expects child platform devices aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder to have IOMMU group attachments, but the Venus video codec driver uses "non-legacy binding" mode where only the parent device aa00000.video-codec is attached to IOMMU group 7. Child devices inherit DMA protection from the parent and do not require separate IOMMU group attachments.
Possible fix: Update the SMMU test to recognize that child devices of video codec drivers using non-legacy binding inherit IOMMU protection from their parent device and should not be flagged as failures when they lack separate IOMMU group attachments. Alternatively, verify that the Venus driver is correctly configured for the non-legacy binding model on qcs615-ride.
Detail analysis attachment: failed_case_job207557_2_detailed.md

Case 3: KVM_Driver
Failed case: KVM_Driver
Root cause: Could not be determined confidently from available logs.
Possible fix: Update the KVM_Driver test to SKIP (not FAIL) when /dev/kvm is absent on platforms without virtualization support; alternatively, exclude QCS615 from KVM test suite as it lacks required hardware capability.
Detail analysis attachment: failed_case_job207557_3_detailed.md

Case 4: KVM_EL2_DTB
Failed case: KVM_EL2_DTB
Root cause: KVM initialization failed because the kernel detected "HYP mode not available" at boot time. The QCS615 Ride platform is running the Gunyah hypervisor (gunyah-1cb9db980) which reserves EL2 for its own use, preventing the Linux kernel's KVM subsystem from accessing EL2/HYP mode. Without EL2 access, the KVM driver cannot create /dev/kvm, causing all KVM-dependent tests to fail.
Possible fix: This is not a PR-introduced regression—the PR only modifies Bluetooth drivers and device tree nodes unrelated to virtualization. The failure is a platform configuration issue: KVM and Gunyah are mutually exclusive on ARM64 (both require EL2). To enable KVM on QCS615 Ride, either: (1) boot without the Gunyah hypervisor (requires firmware/bootloader reconfiguration to not load Gunyah), or (2) accept that KVM tests will fail on Gunyah-enabled platforms and mark these tests as "skip" for QCS615 Ride in the CI test matrix.
Detail analysis attachment: failed_case_job207557_4_detailed.md

Case 5: KVM_Infra (also KVM_Driver, KVM_EL2_DTB)
Failed case: KVM_Infra (also KVM_Driver, KVM_EL2_DTB)
Root cause: KVM initialization failed because HYP (EL2 hypervisor) mode is not available on the QCS615 platform; kernel message at boot (line 2696): kvm [1]: HYP mode not available
Possible fix: This is a platform limitation, not a kernel regression. QCS615 does not support ARM virtualization extensions (EL2) required for KVM. Add QCS615 to the KVM test exclusion list in the LAVA test definition, or update the test suite to detect platform capabilities and skip KVM tests gracefully when EL2 is unavailable.
Detail analysis attachment: failed_case_job207557_5_detailed.md

Case 6: KVM Runtime Unavailability — Hypervisor Conflict
Failed case: KVM Runtime Unavailability — Hypervisor Conflict
Root cause: KVM cannot initialize on qcs615-ride because Gunyah hypervisor is already running at EL2 (log evidence: "kvm [1]: HYP mode not available" at boot, "Hypervisor cold boot, version: gunyah-1cb9db980" at early boot); CONFIG_KVM is enabled but /dev/kvm device node is never created because kvm_arch_init() fails when EL2 is not available to Linux.
Possible fix: This is expected platform behavior, not a regression. The qcs615-ride board runs Gunyah hypervisor which owns EL2, preventing KVM from initializing. To enable KVM testing: (1) use a different test platform without Gunyah, or (2) mark KVM tests as SKIP for qcs615-ride in the LAVA job definition, or (3) rebuild firmware without Gunyah if KVM is required on this SoC.
Detail analysis attachment: failed_case_job207557_6_detailed.md

Job 207558 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check
Failed case: Probe_Failure_Check
Root cause: Deferred probe not resolved for four SPMI PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) on lemans-evk, indicating missing thermal zone driver or DT thermal zone configuration for this SoC. The regulatory.db firmware load failure is a benign cfg80211 fallback behavior. Bluetooth firmware failures are suppressed (BT_ON_OFF test passed).
Possible fix: Add thermal zone DT nodes for lemans-evk PMICs 0, 2, 4, and 6 in arch/arm64/boot/dts/qcom/sa8775p.dtsi or the board-specific DTS, referencing the temp-alarm devices as thermal sensors, to resolve the deferred probe loop.
Detail analysis attachment: failed_case_job207558_1_detailed.md

Case 2: smmu
Failed case: smmu
Root cause: The video codec device (aa00000.video-codec at address 0xaa00000) failed to attach to any IOMMU group during kernel boot on lemans-evk, causing the smmu test's critical master validation to fail. The iris video driver modules (qcom_iris, iris_non_pixel.0, iris_pixel.0) loaded successfully and attached to IOMMU groups 25 and 26, but the parent video-codec platform device itself did not attach to an IOMMU group.
Possible fix: This is a pre-existing platform/kernel issue unrelated to PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 (which only modifies Bluetooth driver and RB3 Gen2 device tree). The video codec device tree node or IOMMU binding for lemans-evk (SA8775P) may be missing or misconfigured. Verify the device tree has correct iommus property for the video-codec node at 0xaa00000, check if the video codec driver probe is completing successfully, and confirm SMMU stream mapping is configured for this device. The PR should not be blocked by this pre-existing lemans-evk platform issue.
Detail analysis attachment: failed_case_job207558_2_detailed.md

Case 3: 0_qcom-next-ci-premerge-tests
Failed case: 0_qcom-next-ci-premerge-tests
Root cause: Test suite marked as failed by LAVA due to two individual test failures: (1) Probe_Failure_Check detected deferred probe devices (4 SPMI temp-alarm devices) and firmware load errors including Bluetooth firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) which are directly impacted by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843's changes to QCC2072 NVM/calibration handling; (2) smmu test detected video codec device (aa00000.video-codec) missing IOMMU group attachment, unrelated to the PR.
Possible fix: For Probe_Failure_Check: Verify the PR's Bluetooth firmware path changes are correct for lemans-evk platform and ensure fallback firmware files exist; the deferred probe warnings for SPMI temp-alarm devices are pre-existing platform issues. For smmu: Investigate video codec IOMMU binding in device tree for lemans-evk (pre-existing issue, not PR-introduced). Re-run CI after confirming Bluetooth firmware files are accessible with the new naming scheme.
Detail analysis attachment: failed_case_job207558_3_detailed.md

Job 207559 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check
Failed case: Probe_Failure_Check
Root cause: Could not be determined confidently from available logs.
Possible fix: These are not PR-introduced regressions. Recommended actions: (1) For QSEECOM: verify TrustZone firmware and secure app availability on hamoa-evk; (2) For LPG: audit and fix the multi-led reg property in hamoa-evk SPMI PMIC device tree nodes to match qcom-spmi-lpg driver expectations; (3) For regulatory.db: add wireless-regdb package to rootfs build or suppress this known benign failure if cfg80211 built-in regulatory data is sufficient.
Detail analysis attachment: failed_case_job207559_1_detailed.md

Case 2: smmu
Failed case: smmu
Root cause: Test expects IOMMU group attachments for USB wrapper devices (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec (aa00000.video-codec) on hamoa-evk, but these devices either do not require IOMMU protection (USB wrappers) or are not present in the platform device tree (video codec). This is a pre-existing test expectation mismatch, not a kernel regression.
Possible fix: Update the smmu test's critical master list for hamoa-evk to exclude USB wrapper devices (only the actual DWC3 controllers at a000000, a200000, a400000, a600000, a800000 need IOMMU protection, and all passed) and remove aa00000.video-codec if it's not present in the hamoa-evk device tree.
Detail analysis attachment: failed_case_job207559_2_detailed.md

Case 3: WiFi_Firmware_Driver
Failed case: WiFi_Firmware_Driver
Root cause: ath12k WiFi7 PCIe driver QMI DMA allocation failure (7274496 bytes) during firmware initialization on hamoa-evk; the driver reports "will try later with small size" but the test framework detects this as a probe failure; WiFi firmware loaded successfully and interface was created (wlP4p1s0), indicating partial initialization; failure is unrelated to PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 which only modifies Bluetooth QCA driver code.
Possible fix: This is a pre-existing platform/driver issue on hamoa-evk, not introduced by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843; the PR should not be blocked by this failure; investigate ath12k_wifi7_pci driver QMI memory allocation strategy and reserved memory configuration for hamoa-evk; check if DMA memory pool size is sufficient for the 7MB allocation request; verify device tree reserved-memory nodes for WiFi subsystem.
Detail analysis attachment: failed_case_job207559_3_detailed.md

Case 4: ** WiFi_OnOff
Failed case: ** WiFi_OnOff
Root cause: ** The WiFi_OnOff test script incorrectly treats a non-fatal driver warning as a probe failure. The ath12k_wifi7 driver logged "qmi dma allocation failed (7274496 B type 1), will try later with small size" during initialization on hamoa-evk. This is a recoverable warning with an explicit fallback strategy. The driver continued successfully: firmware loaded (fw_version 0x1103006c), WiFi interface created and renamed (wlP4p1s0), and no subsequent errors occurred. The test script uses naive pattern matching that flags any "failed" string in dmesg without verifying whether the failure was fatal or whether the driver ultimately succeeded.
Possible fix: Update the WiFi_OnOff test script (Runner/suites/Connectivity/WiFi/WiFi_OnOff/run.sh) to distinguish fatal probe failures from recoverable warnings. Change the probe failure regex to match only fatal errors like "probe of .* failed with error -" and exclude patterns containing "will try later", "will retry", or "fallback". Add positive functional checks: verify WiFi interface exists (ip link show | grep -E 'wlan|wlP'), can be brought up (ip link set <iface> up), and can scan (iw dev <iface> scan | grep -q BSS). Short-term mitigation: add suppression rule for "qmi dma allocation failed.*will try later" when WiFi interface was created.
Detail analysis attachment: failed_case_job207559_4_detailed.md

Case 5: KVM_Driver
Failed case: KVM_Driver
Root cause: KVM initialization failed because Gunyah hypervisor is running on the Hamoa platform and occupying EL2 (hypervisor exception level), preventing KVM from accessing HYP mode. KVM requires exclusive access to EL2 to create the /dev/kvm device node.
Possible fix: This is a platform configuration issue, not a kernel regression. The Hamoa EVK is configured to run Gunyah hypervisor at EL2, which is incompatible with KVM. To enable KVM testing on this platform, either: (1) disable Gunyah hypervisor in the firmware/bootloader configuration and reboot, or (2) run KVM tests on a platform without Gunyah hypervisor enabled. The PR changes (Bluetooth QCC2072 support for RB3 Gen 2) are unrelated to this failure.
Detail analysis attachment: failed_case_job207559_5_detailed.md

Case 6: KVM_EL2_DTB
Failed case: KVM_EL2_DTB
Root cause: KVM cannot initialize because the Hamoa EVK platform is running Linux as a Primary VM under the Gunyah hypervisor, which does not expose EL2 (HYP mode) to the guest OS; kernel log shows "kvm [1]: HYP mode not available" at boot.
Possible fix: Update the LAVA test suite to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor/type) and skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on platforms running under Gunyah or other hypervisors that do not expose nested virtualization; alternatively, if KVM functionality is required on Hamoa EVK, reconfigure the platform to boot Linux directly without Gunyah or enable nested virtualization support in Gunyah firmware.
Detail analysis attachment: failed_case_job207559_6_detailed.md

Case 7: KVM_Infra — KVM driver initialization failure
Failed case: KVM_Infra — KVM driver initialization failure
Root cause: KVM driver failed to initialize because HYP mode (EL2 - Exception Level 2) is not available on the Hamoa IoT EVK platform. The kernel log shows "kvm [1]: HYP mode not available" at boot time, indicating the hardware/firmware does not support or enable virtualization extensions required for KVM operation.
Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 (which only modifies Bluetooth QCA driver code). The KVM test suite should be excluded from the Hamoa IoT EVK test matrix, or the test should be updated to skip gracefully when HYP mode is unavailable. If KVM support is required on this platform, verify that the bootloader/firmware is configured to boot the kernel at EL2 and that the SoC supports virtualization extensions.
Detail analysis attachment: failed_case_job207559_7_detailed.md

Case 8: KVM_Infra
Failed case: KVM_Infra
Root cause: KVM initialization failed on Hamoa EVK because the platform does not support EL2 (Hypervisor mode). The kernel message "kvm [1]: HYP mode not available" at boot time indicates the CPU is not running at EL2 or EL2 is disabled by the bootloader/firmware, preventing KVM from initializing and creating /dev/kvm.
Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The Hamoa EVK platform does not support virtualization (EL2/HYP mode). The KVM test suite should be skipped on platforms without EL2 support, or the LAVA job definition should exclude KVM tests for Hamoa EVK. No kernel code change is required.
Detail analysis attachment: failed_case_job207559_8_detailed.md

Job 207560 | SoC shikra-iqs-evk

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

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

Case 1: Test Infrastructure Bug — GIC test script hardcoded CPU count mismatch
Failed case: Test Infrastructure Bug — GIC test script hardcoded CPU count mismatch
Root cause: The GIC test script assumes 8 CPUs and attempts to parse timer interrupt counts for CPUs 0-7, but shikra-iqs-evk has only 4 CPUs (0-3). When parsing /proc/interrupts for non-existent CPUs 4-7, the script encounters malformed output and fails at line 75 with bash integer comparison errors ("[: GICv3: integer expected", "[: Level: integer expected", "[: arch_timer: integer expected").
Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an 8-CPU assumption. The script should only validate timer interrupts for CPUs that actually exist on the platform.
Detail analysis attachment: failed_case_job207560_1_detailed.md

Case 2: remoteproc
Failed case: remoteproc
Root cause: Could not be determined confidently from available logs.
Possible fix: Verify whether modem auto-start is expected on shikra-iqs-evk by checking the device tree remoteproc node for the modem subsystem — if auto-start is intended, add the required device tree property or userspace trigger to power up remoteproc0; if modem is not supported on this board variant (IQS vs CQS), update the test expectations to skip remoteproc0 validation for shikra-iqs-evk or mark it as expected-offline.
Detail analysis attachment: failed_case_job207560_2_detailed.md

Case 3: Probe_Failure_Check
Failed case: Probe_Failure_Check
Root cause: Test detected two benign probe errors that are pre-existing platform issues unrelated to the PR: (1) cpufreq-dt probe failure with -EEXIST (error -17) occurs because the cpufreq driver is already registered by another mechanism on shikra-iqs-evk, and (2) regulatory.db firmware load failure with -ENOENT (error -2) is a known benign failure when the wireless regulatory database file is not present in the rootfs but cfg80211 continues with built-in certificates.
Possible fix: Mark this test case as a false positive for this PR. The PR only modifies Bluetooth QCA driver code and device tree files for rb3gen2 (qcs6490), which are unrelated to cpufreq-dt or cfg80211 regulatory database loading on shikra (sc7280). These probe errors exist in the baseline kernel and are not introduced by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843. To prevent future false positives, update the Probe_Failure_Check test to exclude known benign probe failures: cpufreq-dt error -17 (duplicate registration) and regulatory.db error -2 (missing file with fallback).
Detail analysis attachment: failed_case_job207560_3_detailed.md

Case 4: USBHost
Failed case: USBHost
Root cause: Test infrastructure limitation — USB controller configured in gadget (device) mode on shikra-iqs-evk board; test expects USB host mode with external devices connected. No kernel errors present; USB subsystem initialized successfully.
Possible fix: This is a known board configuration limitation, not a kernel regression. The PR (Bluetooth firmware changes) does not touch USB code. Recommended actions: (1) Skip USBHost test for shikra-iqs-evk in CI configuration, OR (2) Configure USB port for host mode and connect external USB device in lab setup, OR (3) Accept as expected failure for this board configuration.
Detail analysis attachment: failed_case_job207560_4_detailed.md

Case 5: ** Kernel Crash — Synchronous External Abort in qcom_rng_read
Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng_read
Root cause: ** Hardware RNG block on Shikra IQS EVK became inaccessible during sustained read operation, triggering a synchronous external abort (bus error) when the qcom_rng driver attempted to read hardware registers. This is a pre-existing platform-specific issue not introduced by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843, which only modifies Bluetooth subsystem code and RB3 Gen2 Industrial device trees.
Possible fix: This is a pre-existing Shikra platform issue, not a PR regression. Recommended actions: (1) Skip qcom_hwrng test on Shikra IQS EVK until platform RNG support is stabilized; (2) Investigate Shikra RNG power/clock domain configuration in device tree; (3) Add runtime PM handling to qcom_rng driver for Shikra; (4) Check for Shikra-specific RNG hardware errata requiring workarounds. PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 can proceed — this failure is unrelated to the Bluetooth changes.
Detail analysis attachment: failed_case_job207560_5_detailed.md

Case 6: ** Kernel Crash — Synchronous External Abort (Hardware Bus Fault)
Failed case: ** Kernel Crash — Synchronous External Abort (Hardware Bus Fault)
Root cause: ** The qcom_rng driver encountered a synchronous external abort (bus error) when attempting to read from the PRNG hardware register at offset +0x4 during the qcom_hwrng test. The hardware block did not respond to the bus transaction, indicating it was either powered down, clock-gated, in reset, or otherwise inaccessible at the time of access. This is a pre-existing platform issue on the Shikra IQS EVK, not introduced by the PR (which only modifies Bluetooth btqca driver code).
Possible fix: This is a platform/hardware stability issue requiring investigation of the PRNG power management and clock gating behavior on Shikra. Short-term: Skip or disable the qcom_hwrng test on Shikra IQS EVK in CI until the root cause is resolved. Long-term: Investigate PRNG runtime PM, clock, and power domain dependencies on Shikra; add proper error handling in qcom_rng driver to detect and recover from hardware access failures; verify PRNG hardware state before register access; consider adding runtime PM get/put around register access paths.
Detail analysis attachment: failed_case_job207560_6_detailed.md

Case 7: lava-test-retry
Failed case: lava-test-retry
Root cause: Could not be determined confidently from available logs.
Possible fix: Short-term: Skip qcom_hwrng test on Shikra IQS EVK until PRNG hardware access issue is resolved. Long-term: (1) Verify PRNG clock (gcc_prng_ahb_clk) and power domain are enabled in device tree and driver probe; (2) Add error handling in qcom_rng driver to gracefully handle MMIO access failures; (3) Enable crashdump collection by adding reboot=panic_warm qcom_scm.download_mode=1 to kernel cmdline and ensuring TCSR DT node is present for ramdump on future crashes.
Detail analysis attachment: failed_case_job207560_7_detailed.md

Case 8: Kernel Crash — Synchronous External Abort (Hardware Bus Error)
Failed case: Kernel Crash — Synchronous External Abort (Hardware Bus Error)
Root cause: Synchronous external abort in qcom_rng_read+0xc4 when accessing RNG hardware MMIO registers during qcom_hwrng test execution; RNG hardware block on Shikra IQS EVK is either unpowered, misconfigured, or has incorrect address mapping — this is a pre-existing platform issue unrelated to the PR's Bluetooth firmware changes.
Possible fix: This is NOT a PR-introduced regression. The PR modifies only Bluetooth firmware handling (btqca.c) and does not touch the qcom_rng driver. To resolve: (1) Skip the qcom_hwrng test on Shikra IQS EVK until the platform RNG hardware issue is fixed, or (2) investigate RNG clock/power domain configuration in the Shikra device tree and ensure the RNG hardware block is properly initialized before the hwrng test runs.
Detail analysis attachment: failed_case_job207560_8_detailed.md

Job 207561 | SoC qcs8300-ride

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

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

Case 1: Driver Probe Failure — Aquantia AQR115C PHY
Failed case: Driver Probe Failure — Aquantia AQR115C PHY
Root cause: Pre-existing qcs8300-ride platform issue: Aquantia AQR115C PHY driver fails to probe with error -22 (-EINVAL) due to missing or malformed "firmware-name" device tree property. The regulatory.db firmware load failure (error -2) is a benign WiFi regulatory database issue that does not affect functionality.
Possible fix: This is a pre-existing platform configuration issue unrelated to PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843. The PR changes only Bluetooth QCC2072 handling and qcs6490-rb3gen2 device tree — it does not modify qcs8300-ride DT, Ethernet drivers, or PHY drivers. No action required for this PR. To fix the underlying platform issue, add or correct the "firmware-name" property in the qcs8300-ride Ethernet PHY device tree node.
Detail analysis attachment: failed_case_job207561_1_detailed.md

Case 2: ** USBHost (Test Infrastructure Issue — No Physical USB Device Connected)
Failed case: ** USBHost (Test Infrastructure Issue — No Physical USB Device Connected)
Root cause: ** The USBHost test expects a functional USB device to be physically connected to the qcs8300-ride board's USB host port for enumeration validation. Only the USB root hub is present (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub), indicating no external USB device is connected. The USB host controller (xhci-hcd) is functional and properly initialized. This is a lab hardware setup issue, not a kernel or driver regression. PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 modifies Bluetooth firmware handling (btqca NVM/calibration for QCC2072) and device tree for BT-over-UART routing on RB3 Gen 2 Industrial — it does not touch USB host drivers or configuration.
Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB hub with downstream devices) to the qcs8300-ride board's USB host port before running the test suite. If the test is intended to validate USB host controller functionality only (not device presence), update the test script to SKIP (not FAIL) when only the root hub is detected, similar to how the Ethernet test handles no-cable scenarios.
Detail analysis attachment: failed_case_job207561_2_detailed.md

Case 3: KVM_Driver — Platform Configuration Issue (Pre-existing)
Failed case: KVM_Driver — Platform Configuration Issue (Pre-existing)
Root cause: KVM cannot initialize on qcs8300-ride because the Gunyah hypervisor is already running at EL2 (hypervisor mode). KVM requires exclusive access to EL2 to provide virtualization services, but Gunyah occupies EL2 and prevents KVM from loading. The kernel has CONFIG_KVM=y but the KVM driver cannot create /dev/kvm when another hypervisor controls EL2. This is a platform-specific configuration, not a regression.
Possible fix: This is expected behavior for qcs8300-ride running Gunyah. To enable KVM testing: (1) disable Gunyah in the bootloader/firmware configuration and rebuild the boot image without Gunyah hypervisor support, OR (2) exclude KVM tests from the qcs8300-ride test suite since this platform is configured for Gunyah-based virtualization, not KVM-based virtualization. The PR (Bluetooth driver and device tree changes) does not affect this behavior.
Detail analysis attachment: failed_case_job207561_3_detailed.md

Case 4: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)
Failed case: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)
Root cause: The QCS8300 Ride platform boots Linux under the Gunyah hypervisor at EL1, preventing KVM from initializing because KVM requires EL2 (hypervisor exception level) to create /dev/kvm. CONFIG_KVM is enabled but the KVM subsystem cannot probe successfully when Linux runs as a guest under another hypervisor.
Possible fix: This is not a PR-introduced regression — it is a pre-existing platform configuration where nested virtualization is not supported. The test should be skipped on QCS8300 platforms running under Gunyah, or the platform firmware should be configured to boot Linux at EL2 without an intermediate hypervisor if KVM functionality is required.
Detail analysis attachment: failed_case_job207561_4_detailed.md

Case 5: KVM_Infra — /dev/kvm device node not created
Failed case: KVM_Infra — /dev/kvm device node not created
Root cause: KVM driver did not initialize on qcs8300-ride (Monaco) platform despite CONFIG_KVM being enabled; no KVM initialization messages appear in boot log, indicating the platform does not support KVM/virtualization at EL2 or the hypervisor is running in a mode that prevents KVM from initializing.
Possible fix: This is a pre-existing platform/configuration limitation, not a PR-introduced regression. The PR modifies only Bluetooth (btqca) code and has no impact on KVM. Verify whether qcs8300-ride hardware/firmware supports KVM; if not, exclude KVM tests from the CI test suite for this platform. If KVM support is expected, check bootloader/firmware configuration to ensure the CPU is not locked to EL1 or that a hypervisor is not already running at EL2.
Detail analysis attachment: failed_case_job207561_5_detailed.md

Case 6: KVM Test Failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra)
Failed case: KVM Test Failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra)
Root cause: Gunyah hypervisor is running at EL2 on qcs8300-ride, preventing KVM from creating /dev/kvm. CONFIG_KVM is enabled but the device node cannot be created because KVM requires direct EL2 access which is occupied by Gunyah.
Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM tests on qcs8300-ride: (1) boot without Gunyah hypervisor, or (2) exclude KVM tests from the qcs8300-ride test suite, or (3) use a different platform that boots without a Type-1 hypervisor for KVM validation.
Detail analysis attachment: failed_case_job207561_6_detailed.md

Job 207562 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check — regulatory.db firmware load failure (benign)
Failed case: Probe_Failure_Check — regulatory.db firmware load failure (benign)
Root cause: The Probe_Failure_Check test flagged a cfg80211 regulatory database firmware load failure (Direct firmware load for regulatory.db failed with error -2) that occurred during early boot. This is a known benign failure: cfg80211 has compiled-in X.509 certificates and built-in regulatory rules, allowing it to function correctly without the external regulatory.db file. The failure is not PR-introduced (PR modifies only Bluetooth and device tree for RB3 Gen2 Industrial mezzanine) and does not impact system functionality — WiFi modules load successfully and all WiFi tests pass.
Possible fix: Suppress this failure in the Probe_Failure_Check test by adding regulatory.db to the known-benign firmware load failure list, or install the wireless-regdb package in the rootfs to provide the regulatory.db file and eliminate the warning.
Detail analysis attachment: failed_case_job207562_1_detailed.md

Case 2: ** USBHost
Failed case: ** USBHost
Root cause: No physical USB device connected to board's USB host port during test
Possible fix: Connect a physical USB device (e.g., USB keyboard, mouse, or storage) to the qcs6490-rb3gen2 board's USB host port before running the USBHost test, or mark this test as SKIP when no USB peripherals are available in the test environment.
Detail analysis attachment: failed_case_job207562_2_detailed.md

Case 3: KVM_Driver — Platform Virtualization Not Supported
Failed case: KVM_Driver — Platform Virtualization Not Supported
Root cause: qcs6490-rb3gen2 (Kodiak) board boots without EL2/HYP mode support; kernel message "kvm [1]: HYP mode not available" at boot indicates the platform firmware/bootloader does not enable ARM virtualization extensions, preventing KVM initialization and /dev/kvm device node creation.
Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR contains only Bluetooth changes). Mark KVM tests as expected-fail or skip for qcs6490-rb3gen2 in the LAVA test suite; alternatively, update board firmware/bootloader to boot kernel at EL2 if virtualization support is required for this platform.
Detail analysis attachment: failed_case_job207562_3_detailed.md

Case 4: KVM_EL2_DTB — KVM Device Node Missing (Platform Limitation)
Failed case: KVM_EL2_DTB — KVM Device Node Missing (Platform Limitation)
Root cause: KVM initialization failed during boot with "HYP mode not available" because the qcs6490-rb3gen2 platform does not support EL2 (hypervisor mode), preventing /dev/kvm device node creation. CONFIG_KVM is enabled but the hardware/firmware does not expose EL2 to Linux.
Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. Mark KVM tests as "skip" for qcs6490-rb3gen2 in the LAVA test suite configuration, or update the board firmware/bootloader to enable EL2 if the SoC supports it. The PR (Bluetooth QCC2072 NVM handling) is unrelated and did not cause this failure.
Detail analysis attachment: failed_case_job207562_4_detailed.md

Case 5: KVM_Infra
Failed case: KVM_Infra
Root cause: KVM driver initialization failed because the kernel detected "HYP mode not available" at boot time on qcs6490-rb3gen2, preventing /dev/kvm device node creation; CONFIG_KVM is enabled but the hardware/firmware does not support EL2 hypervisor mode required for KVM functionality.
Possible fix: This is a platform limitation, not a kernel regression introduced by the PR (which only modifies Bluetooth QCA driver and device tree labels/PCIe/BT nodes unrelated to KVM/virtualization). The qcs6490-rb3gen2 board does not boot into EL2 mode, likely due to firmware/bootloader configuration or SoC security policy. To enable KVM: (1) verify the bootloader/TZ firmware supports booting Linux at EL2; (2) if not supported by the platform, mark KVM tests as expected-fail or skip for this board in the CI configuration; (3) if EL2 should be available, check bootloader configuration and ensure the kernel is entered at EL2 (not EL1).
Detail analysis attachment: failed_case_job207562_5_detailed.md

Case 6: KVM Test Failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra) — Platform Configuration Limitation
Failed case: KVM Test Failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra) — Platform Configuration Limitation
Root cause: qcs6490-rb3gen2 platform boots under Gunyah hypervisor which owns EL2; KVM requires EL2 access to function as a hypervisor but cannot access it when running as a guest OS under another hypervisor, resulting in "HYP mode not available" and no /dev/kvm device node creation.
Possible fix: This is not a bug but a platform configuration limitation. The KVM tests should be skipped on platforms running under a hypervisor. Add platform detection logic to the test suite to skip KVM tests when "HYP mode not available" is detected in dmesg, or exclude qcs6490-rb3gen2 from KVM test execution in the LAVA job definition.
Detail analysis attachment: failed_case_job207562_6_detailed.md

Job 207565 | SoC purwa-evk

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

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

Case 1: ** Probe_Failure_Check — Pre-existing Platform Hardware Support Gaps
Failed case: ** Probe_Failure_Check — Pre-existing Platform Hardware Support Gaps
Root cause: ** Five driver probe failures detected during boot on purwa-evk (iq-x5121): (1) qcom-pcie PHY init sequences not available for this SoC variant (-ENODATA), (2) qcom-spmi-lpg device tree reg property invalid for multi-LED configuration (-EINVAL), (3) qcom_qseecom_uefisecapp secure firmware resource busy (-EBUSY), (4) regulatory.db firmware file missing (known benign, -ENOENT). None of these failures are related to the PR changes (Bluetooth QCC2072 NVM handling).
Possible fix: These are pre-existing platform issues, not PR-introduced regressions. No action required for this PR. For platform maintainers: (1) Add PCIe PHY init sequences for purwa/iq-x5121 to drivers/phy/qualcomm/phy-qcom-qmp-pcie.c, (2) Fix device tree reg property for multi-LED node under c42d000.spmi:pmic@1:pwm in purwa DTS, (3) Investigate qseecom secure firmware initialization timing, (4) Optionally add regulatory.db to rootfs firmware directory (non-critical).
Detail analysis attachment: failed_case_job207565_1_detailed.md

Case 2: smmu
Failed case: smmu
Root cause: Test expectation mismatch — the test script incorrectly expects USB wrapper devices (DWC3 glue layer at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec device (aa00000) to have IOMMU group attachments, but these are not DMA-capable masters requiring IOMMU protection on purwa-evk (iq-x5121).
Possible fix: Update the test script's critical master list for purwa-evk to exclude USB wrapper devices and verify video codec IOMMU requirements; the actual USB controllers (a000000, a200000, a400000, a600000, a800000) are correctly protected and passed validation.
Detail analysis attachment: failed_case_job207565_2_detailed.md

Case 3: WiFi_Firmware_Driver
Failed case: WiFi_Firmware_Driver
Root cause: Test false positive — the LAVA test script flags the transient warning "ath12k_wifi7_pci 0004:01:00.0: qmi dma allocation failed (7274496 B type 1), will try later with small size" as a hard failure, but the ath12k WiFi driver successfully recovered by retrying with a smaller DMA buffer size and completed probe (firmware loaded, interface wlP4p1s0 created).
Possible fix: Update the WiFi_Firmware_Driver test script to distinguish between transient warnings with successful recovery (messages containing "will try later") and genuine probe failures; alternatively, suppress this specific message pattern when followed by successful firmware load and interface creation within the same boot cycle.
Detail analysis attachment: failed_case_job207565_3_detailed.md

Case 4: WiFi_OnOff — WiFi Driver Probe Warning (Non-Genuine Failure)
Failed case: WiFi_OnOff — WiFi Driver Probe Warning (Non-Genuine Failure)
Root cause: The test framework flagged a benign ath12k_wifi7_pci driver warning message "qmi dma allocation failed (7274496 B type 1), will try later with small size" as a probe failure. This is a known recoverable condition where the driver attempts a large (~7MB) DMA allocation, receives -ENOMEM, then successfully retries with a smaller allocation size. The driver probe completed successfully (firmware loaded, interface wlP4p1s0 created), indicating no actual functional failure. The test's probe-failure pattern matching is overly strict and does not account for this expected retry behavior on the purwa-evk platform.
Possible fix: Update the WiFi_OnOff test's probe-failure detection logic to exclude the "qmi dma allocation failed ... will try later with small size" pattern when it is followed by successful driver initialization (firmware load + interface creation). Alternatively, suppress this specific warning pattern in the test framework's failure-matching rules, as it represents expected driver behavior on memory-constrained early boot, not a regression. No kernel code change is required — this is a test infrastructure false positive.
Detail analysis attachment: failed_case_job207565_4_detailed.md

Case 5: KVM_Driver
Failed case: KVM_Driver
Root cause: KVM is unavailable because the Purwa EVK platform runs under the Gunyah hypervisor (gunyah-mobile-c487961e9), which does not expose HYP mode to the Linux kernel. The kernel message "kvm [1]: HYP mode not available" at boot confirms that KVM cannot initialize because EL2 is already occupied by Gunyah.
Possible fix: This is not a kernel regression introduced by PR FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 Industrial #843 (which only modifies Bluetooth QCA driver code). KVM_Driver test failure is expected on Purwa EVK and other Gunyah-based platforms where the hypervisor does not delegate EL2 to Linux. Mark this test as "skip" for Gunyah-based targets in the LAVA test suite, or configure the test to check for Gunyah presence before attempting KVM validation.
Detail analysis attachment: failed_case_job207565_5_detailed.md

Case 6: KVM_EL2_DTB
Failed case: KVM_EL2_DTB
Root cause: KVM driver initialization fails because EL2 (HYP mode) is not available on the purwa-evk platform — the kernel reports "HYP mode not available" at boot, preventing /dev/kvm device creation.
Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The purwa-evk board either runs under a hypervisor (preventing nested virtualization) or lacks EL2 support in its boot chain. To enable KVM: (1) verify the SoC supports EL2, (2) ensure bootloader/firmware enables EL2 for the kernel, (3) if running under a hypervisor, configure nested virtualization support. For CI: suppress KVM tests on purwa-evk or mark them as expected-fail until platform support is confirmed.
Detail analysis attachment: failed_case_job207565_6_detailed.md

Case 7: KVM_Infra — KVM device node unavailable (platform limitation)
Failed case: KVM_Infra — KVM device node unavailable (platform limitation)
Root cause: KVM driver initialization failed at boot because the Purwa IoT EVK platform does not support ARM Hypervisor (HYP/EL2) mode, which is a mandatory hardware requirement for KVM. Kernel log shows kvm [1]: HYP mode not available at boot time, preventing /dev/kvm creation despite CONFIG_KVM being enabled.
Possible fix: This is not a kernel bug or PR regression — it is a platform hardware limitation. The Purwa IoT EVK SoC does not provide EL2 (Hypervisor) support required for KVM. Either: (1) exclude KVM tests from the Purwa EVK CI test suite, or (2) run KVM tests only on platforms with EL2 support (e.g., boards with virtualization extensions enabled in firmware/bootloader). No kernel code fix is required.
Detail analysis attachment: failed_case_job207565_7_detailed.md

Case 8: KVM_Driver, KVM_EL2_DTB, KVM_Infra
Failed case: KVM_Driver, KVM_EL2_DTB, KVM_Infra
Root cause: KVM cannot initialize because the Gunyah hypervisor is running at EL2 on the purwa-evk platform. The kernel log shows "kvm [1]: HYP mode not available" at boot time, and the Gunyah hypervisor boot banner confirms "Hypervisor cold boot, version: gunyah-mobile-c487961e9". When a Type-1 hypervisor like Gunyah occupies EL2, KVM (which requires EL2 access) cannot be initialized, resulting in the absence of /dev/kvm.
Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR changes only Bluetooth driver code and device tree overlays for RB3 Gen 2 Industrial mezzanine. To enable KVM on purwa-evk, either: (1) boot without the Gunyah hypervisor (requires bootloader/firmware configuration change to boot Linux directly at EL2), or (2) use nested virtualization if Gunyah supports exposing a virtual EL2 to the guest kernel (requires Gunyah hypervisor feature support). For CI purposes, mark these KVM tests as "expected skip" on purwa-evk when Gunyah is present, or run KVM tests only on platforms that boot Linux directly at EL2.
Detail analysis attachment: failed_case_job207565_8_detailed.md

Rahul Samana (rahul-samana) requested review from a team, Komal Bajaj (Komal-Bajaj), aiquny and Shivendra Pratap (quicAspratap)July 20, 2026 17:08

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from 511fa1e to 5cb39e3Compare July 20, 2026 17:35

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from 5cb39e3 to 09fad7cCompare July 28, 2026 17:07

Rahul Samana (rahul-samana) changed the title ~~arm64: dts: qcom: rename rb3gen2 industrial mezzanine UART BT overlay~~FROMLIST: Bluetooth: qca: enable QCC2072 on RB3 Gen 2 IndustrialJul 28, 2026

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from 09fad7c to 3e3c491Compare July 31, 2026 04:44

Shiraz Hashim (shashim-quic) requested changes Jul 31, 2026
View reviewed changes

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from 3e3c491 to dc4a14dCompare July 31, 2026 14:55

qcomlnxci requested a review from a teamJuly 31, 2026 14:57

Rahul Samana (rahul-samana) marked this pull request as draft July 31, 2026 15:22

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from dc4a14d to f62716dCompare August 1, 2026 11:15

vivesahu-hubossand others added 3 commits August 1, 2026 20:09

Rahul Samana (rahul-samana)force-pushed the rb3gen2-industrial-mezzanine-bt-uart-rename-qcom-6.18 branch from f62716d to a235b6aCompare August 1, 2026 14:44

Rahul Samana (rahul-samana) marked this pull request as ready for review August 1, 2026 14:46

Rahul Samana (rahul-samana) requested a review from Shiraz Hashim (shashim-quic)August 3, 2026 05:59

Shiraz Hashim (shashim-quic) approved these changes Aug 6, 2026
View reviewed changes

Salendarsingh Gaud (sgaud-quic) merged commit 165c385 into qualcomm-linux:qcom-6.18.yAug 19, 2026
6 of 8 checks passed

Uh oh!

Conversation

Rahul Samana (rahul-samana) commented Jul 20, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qswat-orbit-externalBot commented Jul 20, 2026

Uh oh!

qswat-orbit-externalBot commented Jul 20, 2026

Uh oh!

qlijarvis commented Jul 20, 2026

PR #843 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Issues

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 20, 2026

PR #843 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ check-patch-compliance

❌ dtb-check

⚠️ tag-check

Verdict

Uh oh!

qlijarvis commented Jul 20, 2026

PR #843 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 20, 2026

PR #843 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ check-patch-compliance

❌ dtb-check

Verdict

Uh oh!

qlijarvis commented Jul 28, 2026

PR #843 — validate-patch

Final Summary

🔍 Patch Validation

Summary

Critical Issues

1. Missing Dependency: Patch 3/6 Not Included

2. Commit 2/5: Partial Backport with Incorrect Subject

3. Commit 1/5: Extra Content Not in Lore Patch

Commit-by-Commit Analysis

Upstream Patch Status

Integration Presence (qcom-next / topics)

Recommendation

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 28, 2026

PR #843 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

⚠️ checkpatch

❌ dt-binding-check

⚠️ dtb-check

❌ check-patch-compliance

Verdict

Uh oh!

qlijarvis commented Jul 31, 2026

PR #843 — validate-patch

Final Summary

🔍 Patch Validation

Rahul Samana (rahul-samana) commented Jul 20, 2026•
edited
Loading