Merge Check Failed: CR Not Eligible for Merge

CR 4243195 is not eligible for merge.

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

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

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

PR #815 — validate-patch

PR: #815

Final Summary

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

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #815 — QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Upstream commit: N/A (vendor-only commit)
Verdict: ✅ PASS (vendor-only)

Commit Message

Check	Status	Note
Subject matches upstream	N/A	Vendor-only commit; no upstream source
Body preserves rationale	✅	Clear description of CAM1 IMX577 sensor support
Fixes tag present/correct	N/A	New feature addition; no Fixes tag required
Authorship preserved	✅	Author and Signed-off-by match
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi	✅	Adds eeprom_cam1 and qcom,cam-sensor12 nodes for IMX577 (78 lines)

Issues

• Minor: Missing space after period in commit body: "OV9282.This" should be "OV9282. This"

Verdict

Merge as-is. This is a vendor-specific device tree addition for IMX577 camera sensor support on QCM6490 RB3 Gen2. The commit message clearly describes the change, authorship is correct, and the diff adds the expected EEPROM and sensor configuration nodes. The minor spacing issue in the commit message does not affect functionality.

Final Summary

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

PR #815 — checker-log-analyzer

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

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #815 - QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/29011270950

Checker	Result	Summary
checkpatch	❌	2 warnings: undocumented DT compatible strings
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	New schema validation failures for qcom,eeprom and qcom,cam-sensor
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no C/H changes)
check-patch-compliance	❌	QCLINUX: prefix not in allowed list
tag-check	✅	Subject has valid prefix (branch is qcom-6.18.y, not qcom-next)

---

❌ checkpatch

Root cause: Two undocumented DT compatible strings used in the new DTSI file.

Failure details:

WARNING: DT compatible string "qcom,eeprom" appears un-documented
#26: FILE: arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi:180:
+		compatible = "qcom,eeprom";

WARNING: DT compatible string "qcom,cam-sensor" appears un-documented
#64: FILE: arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi:218:
+		compatible = "qcom,cam-sensor";

318e29e1bb29 total: 0 errors, 2 warnings, 0 checks, 84 lines checked

Fix: Add DT binding YAML files for these compatible strings:

1. Create Documentation/devicetree/bindings/media/qcom,eeprom.yaml
2. Create Documentation/devicetree/bindings/media/qcom,cam-sensor.yaml

Or, if these are vendor-specific camera subsystem nodes not intended for upstream, document them in a vendor-specific binding file.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git cf2725e2d166..318e29e1bb29

---

❌ dtb-check

Root cause: The new DTS nodes use qcom,eeprom and qcom,cam-sensor compatible strings that have no schema bindings, causing validation failures.

Failure details:

arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtb:
  /soc@0/qcom,cci0/qcom,eeprom1: failed to match any schema with compatible: ['qcom,eeprom']

arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtb:
  /soc@0/qcom,cci0/qcom,cam-sensor12: failed to match any schema with compatible: ['qcom,cam-sensor']

qcom,eeprom1 (qcom,eeprom): gpio-req-tbl-label: b'CAMIF_MCLK1 CAM_RESET1 CAM_CUSTOM1 '
  is not of type 'object', 'integer', 'array', 'boolean', 'null'

qcom,cam-sensor12 (qcom,cam-sensor): gpio-req-tbl-label: b'CAMIF_MCLK1 CAM_RESET1 CAM_CUSTOM1 '
  is not of type 'object', 'integer', 'array', 'boolean', 'null'

qcom,cci0 (qcom,cci): qcom,eeprom1: 'ranges' is a required property
qcom,cci0 (qcom,cci): qcom,cam-sensor12: 'ranges' is a required property

Fix:

1. Add DT binding schema files for qcom,eeprom and qcom,cam-sensor compatible strings
2. Define the gpio-req-tbl-label property type correctly in the binding (should be an array of strings, not a space-separated string)
3. Add ranges property to the parent qcom,cci0 node if required by the CCI binding

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtb

---

❌ check-patch-compliance

Root cause: The commit uses QCLINUX: prefix, which is not in the checker's allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Commit summary does not start with a required prefix

Fix: This is a known limitation of the check-patch-compliance checker. The QCLINUX: prefix is a valid vendor-internal prefix used in the Qualcomm Linux tree for vendor-only changes that have no upstream equivalent. However, the checker only accepts upstream-linkable prefixes.

Options:

1. If this change is vendor-only (not intended for upstream): Accept that this checker will always fail. This is expected behavior for QCLINUX: commits.
2. If this change could be posted upstream: Change the prefix to FROMLIST: and add a Link: tag pointing to the lore.kernel.org mailing list thread.

For vendor-only DTS changes like camera sensor configurations specific to Qualcomm development boards, option 1 is appropriate — the checker failure is expected and can be ignored.

---

Verdict

3 blockers to fix before merge:

1. checkpatch warnings — Add DT binding YAML files for qcom,eeprom and qcom,cam-sensor, or document why these vendor-specific compatibles don't need upstream bindings.

2. dtb-check failures — The new nodes fail schema validation because:

   • No binding exists for qcom,eeprom and qcom,cam-sensor
   • Property types are incorrect (gpio-req-tbl-label should be an array, not a string)
   • Missing ranges property in parent CCI node

3. check-patch-compliance failure — This is a known limitation for QCLINUX: prefixed commits. If this is genuinely a vendor-only change, this failure can be accepted as-is. If the change should be upstreamed, change the prefix to FROMLIST: and add a Link: tag.

Recommendation: Fix items 1 and 2 (add bindings and fix property types). Item 3 can be accepted if this is vendor-only work.

Test Matrix

Test jobs on 318e29e

• Job 184926 on hamoa-iot-evk
• Job 184923 on lemans-evk
• Job 184929 on monaco-evk
• Job 184925 on qcs615-ride
• Job 184927 on qcs6490-rb3gen2
• Job 184924 on qcs8300-ride
• Job 184928 on qcs9100-ride-r3
• Job on qrb2210-rb1

PR #815 — validate-patch

PR: #815

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #815 - QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Upstream commit: N/A (vendor-only commit)
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	QCLINUX: vendor-only commit; no upstream source
Body preserves rationale	✅	Clear description of CAM1 IMX577 sensor support
Fixes tag present/correct	N/A	Not a fix; new feature addition
Authorship preserved	✅	Author: Vadlamani Manjusha; Signed-off-by present
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi	✅	Adds 78 lines: eeprom_cam1 and qcom,cam-sensor12 nodes for IMX577

Issues

• Integration presence: Commit shows only partial evidence in qcom-next/topics. The integration_presence_report indicates "partial - subject or partial tree evidence found, but full change was not verified". This suggests the commit may exist in a similar form but the exact diff was not confirmed in the integration branch.

Verdict

This is a vendor-only (QCLINUX:) commit adding IMX577 camera sensor support to QCS6490 RB3Gen2. The commit message is clear, authorship is correct, and the diff adds appropriate device tree nodes. However, the integration presence check shows only partial evidence in qcom-next/topics, which warrants verification that the change is properly integrated or that this is an intentional new addition not yet in the integration branch.

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Partial — 1/1 commit(s) only have partial integration evidence (subject or partial tree match found, but full change not verified)

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/1	[PATCH] QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support	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

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

PR #815 — checker-log-analyzer

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

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #815 - QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/30996020572
Target Branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	2 warnings: undocumented DT compatible strings
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Missing bindings for qcom,eeprom and qcom,cam-sensor
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX prefix not accepted (known limitation)
tag-check	✅	Valid QCLINUX prefix present

---

❌ checkpatch

Root cause: Two vendor-specific DT compatible strings lack documentation in vendor-prefixes.yaml.

Failure details:

WARNING: DT compatible string "qcom,eeprom" appears un-documented
#26: FILE: arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi:180:
+		compatible = "qcom,eeprom";

WARNING: DT compatible string "qcom,cam-sensor" appears un-documented
#64: FILE: arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi:218:
+		compatible = "qcom,cam-sensor";

Fix: Add DT binding YAML files for these compatible strings:

1. Create Documentation/devicetree/bindings/media/qcom,eeprom.yaml
2. Create Documentation/devicetree/bindings/media/qcom,cam-sensor.yaml

Alternatively, if these are vendor-internal camera subsystem nodes not intended for upstream, document them in a vendor-specific binding or suppress the warning by adding them to an existing Qualcomm camera binding.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 8635749eab9a..2b8ed92c18b5

---

❌ dtb-check

Root cause: The newly added DTS nodes reference compatible strings (qcom,eeprom, qcom,cam-sensor) that have no corresponding DT binding schema, causing validation failures.

Failure details:

arch/arm64/boot/dts/qcom/qcs5430-fps-camx.dtb: /soc@0/qcom,cci0/qcom,cam-sensor12: 
  failed to match any schema with compatible: ['qcom,cam-sensor']

arch/arm64/boot/dts/qcom/qcs5430-fps-camx.dtb: /soc@0/qcom,cci0/qcom,eeprom1: 
  failed to match any schema with compatible: ['qcom,eeprom']

/opt/.../qcs5430-fps-camx.dtb: qcom,cci0 (qcom,cci): qcom,cam-sensor12: 
  'ranges' is a required property

/opt/.../qcs5430-fps-camx.dtb: qcom,cci0 (qcom,cci): qcom,eeprom1: 
  'ranges' is a required property

qcom,cam-sensor12 (qcom,cam-sensor): gpio-req-tbl-label: 
  b'CAMIF_MCLK1^@CAM_RESET1^@CAM_CUSTOM1^@' is not of type 'object', 'integer', 'array', 'boolean', 'null'

The errors appear in multiple DTB files (qcs5430-fps-camx.dtb, qcs6490-rb3gen2-vision-mezzanine-camx.dtb) that include the modified qcs6490-rb3gen2-camera-sensor.dtsi.

Fix:

1. Primary fix: Add DT binding YAML schemas for qcom,eeprom and qcom,cam-sensor that declare:

   • All properties used in the DTS nodes (gpio-, regulator-, power-domains, etc.)
   • Whether ranges is required (likely not for leaf camera sensor nodes)
   • Proper type definitions for gpio-req-tbl-label (likely a string array)

2. Alternative: If these are vendor-internal camera subsystem nodes not intended for upstream, the dtb-check failures are expected. Consider adding these compatible strings to a vendor-specific binding or documenting them in an internal schema.

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs5430-fps-camx.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtb

---

❌ check-patch-compliance

Root cause: The commit uses the QCLINUX: prefix, which is not in the checker's allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Commit summary does not start with a required prefix

Fix: This is a known limitation of the check-patch-compliance checker. The checker enforces upstream-linkable prefixes only and does not accept vendor-internal prefixes like QCLINUX: or PENDING:.

Options:

1. If this change is vendor-only with no upstream equivalent: Accept that check-patch-compliance will always fail for this commit. The QCLINUX: prefix is correct for vendor-internal changes.
2. If this change has been or will be posted upstream: Change the prefix to FROMLIST: and add a Link: trailer pointing to the lore.kernel.org URL.

For vendor-only camera subsystem changes like this one, option 1 is appropriate — the checker failure is expected and does not indicate a patch defect.

---

Verdict

3 blockers to address before merge:

1. checkpatch warnings — Add DT binding documentation for qcom,eeprom and qcom,cam-sensor, or document why these vendor-internal compatible strings are acceptable without upstream bindings.

2. dtb-check failures — Add proper DT binding YAML schemas that declare all properties used by the camera sensor nodes, or accept that vendor-internal camera nodes will fail validation until bindings are added.

3. check-patch-compliance failure — This is a known limitation for QCLINUX:-prefixed commits. If this is a vendor-only change, the failure is expected and can be accepted. If the change will be upstreamed, change the prefix to FROMLIST: and add a Link: trailer.

Recommendation: If this is a vendor-internal camera subsystem change not intended for upstream, the check-patch-compliance failure is acceptable. The checkpatch and dtb-check failures should be addressed by adding vendor-specific DT binding documentation for the camera subsystem nodes.

Test Matrix

Test jobs on 2b8ed92

• multimedia Job 194089 on hamoa-iot-evk
• multimedia Job 194094 on lemans-evk
• multimedia Job 194093 on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job 194090 on qcs615-ride
• multimedia Job 194092 on qcs6490-rb3gen2
• multimedia Job 194095 on qcs8300-ride
• multimedia Job 194088 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 194091 on shikra-iqs-evk

Test jobs on b32484e

• multimedia Job 210633 on hamoa-iot-evk
• multimedia Job 210629 on lemans-evk
• multimedia Job 210632 on monaco-evk
• multimedia Job 210626 on purwa-iot-evk
• multimedia Job 210627 on qcs615-ride
• multimedia Job 210625 on qcs6490-rb3gen2
• multimedia Job 210630 on qcs8300-ride
• multimedia Job 210628 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 210631 on shikra-iqs-evk

Test Matrix

Test jobs on 346232a

• multimedia Job 212459 on hamoa-iot-evk
• multimedia Job 212456 on lemans-evk
• multimedia Job 212462 on monaco-evk
• multimedia Job 212455 on purwa-iot-evk
• multimedia Job 212457 on qcs615-ride
• multimedia Job 212454 on qcs6490-rb3gen2
• multimedia Job 212458 on qcs8300-ride
• multimedia Job 212460 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212461 on shikra-iqs-evk

Test Matrix

PR #815 — validate-patch

PR: #815

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #815 - QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Upstream commit: N/A (vendor-only commit)
Verdict: ✅ PASS

Commit Message

Check	Status	Note
Subject matches upstream	N/A	QCLINUX: prefix — vendor-only commit
Body preserves rationale	✅	Clear description of CAM1 IMX577 sensor enablement
Fixes tag present/correct	N/A	New feature, not a fix
Authorship preserved	✅	Vadlamani Manjusha mvadlama@qti.qualcomm.com
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-camera-sensor.dtsi	✅	Adds eeprom_cam1 and qcom,cam-sensor12 nodes for IMX577 sensor

Verdict

Merge as-is. This is a vendor-specific device tree change for QCM6490 hardware platform. The commit message clearly describes the purpose (enabling IMX577 sensor on CAM1 port), and the diff adds appropriate device tree nodes following the existing pattern in the file.

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Partial — integration_presence_report.md shows "partial - subject or partial tree evidence found, but full change was not verified" in qcom-next; missing from topics

Deterministic Integration Presence

Integration Presence Report

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

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

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support	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

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

PR #815 — checker-log-analyzer

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

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #815 - QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32696104533

Checker	Result	Summary
checkpatch	❌	2 warnings: undocumented DT compatible strings
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Missing bindings for qcom,eeprom and qcom,cam-sensor; missing ranges property
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No C/H file changes
check-patch-compliance	❌	QCLINUX: prefix not in allowed list
tag-check	⚠️	Cannot determine target branch (network unavailable); if not qcom-next/qcom-next-staging, QCLINUX: is valid

---

❌ checkpatch

Root cause: Two undocumented DT compatible strings used in the new camera sensor nodes.

Failure details:

WARNING: DT compatible string "qcom,eeprom" appears un-documented -- check ./Documentation/devicetree/bindings/
WARNING: DT compatible string "qcom,cam-sensor" appears un-documented -- check ./Documentation/devicetree/bindings/
b32484ecbf4f3ad9e2e7fbb3c548f0188b16b877 total: 0 errors, 2 warnings, 0 checks, 84 lines checked

Fix: Add DT binding YAML files for these Qualcomm camera subsystem compatible strings:

1. Create Documentation/devicetree/bindings/media/qcom,eeprom.yaml
2. Create Documentation/devicetree/bindings/media/qcom,cam-sensor.yaml

Alternatively, if these are vendor-specific downstream bindings not intended for upstream, these warnings can be noted but may not require immediate action for internal trees.

Reproduce locally:

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

---

❌ dtb-check

Root cause: The new qcom,eeprom1 and qcom,cam-sensor12 nodes fail schema validation because no binding YAML exists for qcom,eeprom and qcom,cam-sensor, and the parent qcom,cci binding requires child nodes to have a ranges property.

Failure details:

qcs6490-rb3gen2-vision-mezzanine-camx.dtb: qcom,cci0 (qcom,cci): qcom,eeprom1: 'ranges' is a required property
qcs6490-rb3gen2-vision-mezzanine-camx.dtb: qcom,cci0 (qcom,cci): qcom,cam-sensor12: 'ranges' is a required property
qcs6490-rb3gen2-vision-mezzanine-camx.dtb: /soc@0/qcom,cci0/qcom,cam-sensor12: failed to match any schema with compatible: ['qcom,cam-sensor']
qcs6490-rb3gen2-vision-mezzanine-camx.dtb: /soc@0/qcom,cci0/qcom,eeprom1: failed to match any schema with compatible: ['qcom,eeprom']
qcom,cam-sensor12 (qcom,cam-sensor): gpio-req-tbl-label: b'CAMIF_MCLK1\x00CAM_RESET1\x00CAM_CUSTOM1\x00' is not of type 'object', 'integer', 'array', 'boolean', 'null'
qcom,eeprom1 (qcom,eeprom): gpio-req-tbl-label: b'CAMIF_MCLK1\x00CAM_RESET1\x00CAM_CUSTOM1\x00' is not of type 'object', 'integer', 'array', 'boolean', 'null'

Fix:

1. Add binding YAML files for qcom,eeprom and qcom,cam-sensor in Documentation/devicetree/bindings/media/:

   • Define all properties used: cell-index, compatible, cam_vio-supply, regulator-names, power-domains, rgltr-*, gpio-*, pinctrl-*, sensor-*, cci-master, clocks, clock-names, clock-cntl-level, clock-rates, eeprom-src, csiphy-sd-index
   • Declare gpio-req-tbl-label as a string array type

2. Add ranges property to the parent qcom,cci node if required by the binding, or update the qcom,cci binding to make ranges optional for these child node types.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/qcs5430-fps-camx.dtb

---

❌ check-patch-compliance

Root cause: The commit subject uses the QCLINUX: prefix, which is not in the checker's allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1
Commit summary does not start with a required prefix

Fix: This is a known limitation of the check-patch-compliance checker. The QCLINUX: prefix is used for vendor-only changes with no upstream equivalent, but the checker only accepts upstream-linkable prefixes.

Options:

1. If this change has been or will be posted upstream: Change the prefix to FROMLIST: and add a Link: trailer pointing to the lore.kernel.org URL.
2. If this is truly vendor-only: Accept that this checker will always fail for QCLINUX: commits. This is expected behavior for internal-only changes.

Note: According to the skill documentation, QCLINUX: and PENDING: prefixes always fail check-patch-compliance — this is a known checker limitation for vendor-only commits.

Reproduce locally:

# The checker script is part of kernel-checkers repo
bash kernel-checkers/check-patch-compliance.sh --kernel-src <path>

---

⚠️ tag-check (Manual Check)

Status: Cannot determine target branch due to network restrictions.

Analysis: The commit uses the QCLINUX: prefix. According to the skill workflow:

• If the target branch is qcom-next or qcom-next-staging: tag-check does not apply (N/A).
• If the target branch is any other branch: every commit must start with a valid prefix (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, WORKAROUND:).

Since the commit uses QCLINUX:, which is a valid prefix, this check would PASS if the target branch is not qcom-next/qcom-next-staging.

Verdict: ✅ PASS (assuming target branch requires prefix tags) — QCLINUX: is a valid prefix.

---

Verdict

3 blockers to fix before merge:

1. checkpatch warnings — Add DT binding YAML files for qcom,eeprom and qcom,cam-sensor, or document why these vendor-specific bindings are acceptable without upstream documentation.

2. dtb-check failures — Add proper DT binding schema files to resolve validation errors. The new camera sensor nodes fail schema validation because:

   • No binding exists for qcom,eeprom and qcom,cam-sensor
   • Missing ranges property required by parent qcom,cci binding
   • gpio-req-tbl-label property type mismatch

3. check-patch-compliance failure — This is a known limitation for QCLINUX: prefixed commits. If this is truly vendor-only code with no upstream equivalent, this failure is expected and can be accepted. If the change will be upstreamed, change the prefix to FROMLIST: and add a Link: trailer.

Recommendation: The most critical issue is the missing DT bindings. Without proper schema files, the dtb-check will continue to fail. If these are vendor-specific camera subsystem bindings not intended for upstream, consider adding them to a vendor-specific binding directory or documenting the exception policy for internal trees.

LAVA Failed Case Triage Summary

PR: #815

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

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

  Case 1: GIC Test Script Bug — Test Infrastructure Issue

1. Failed case: GIC Test Script Bug — Test Infrastructure Issue
2. Root cause: The GIC test script has a parsing bug at line 75 that fails when the system has fewer online CPUs than expected (6 online vs 8 expected). The script incorrectly parses the "GICv3" string from /proc/interrupts as an integer when checking timer counts for offline CPUs 6-7. The underlying platform issue is that CPUs 6-7 failed to boot during kernel initialization with PSCI error -22 (-EINVAL), which is a pre-existing firmware/device-tree configuration issue unrelated to this PR's camera sensor changes.
3. Possible fix: This is a test infrastructure false positive, not a kernel regression. The PR should NOT be blocked by this failure. Recommended actions: (1) Fix the GIC test script to handle systems with fewer than 8 CPUs by checking /sys/devices/system/cpu/online before testing each CPU; (2) Investigate the pre-existing PSCI CPU6/CPU7 boot failure on qcs6490-rb3gen2 (error -22 indicates invalid PSCI configuration in device tree or firmware) as a separate platform enablement task.
4. Detail analysis attachment: failed_case_job210625_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two probe failures during boot: (1) cfg80211 regulatory.db firmware load failure (error -2, ENOENT) — benign as WiFi functional tests passed; (2) xhci-pci-renesas USB host controller probe failure (error -2, missing renesas_usb_fw.mem firmware) — pre-existing hardware/firmware issue unrelated to PR815 camera sensor DT changes.
3. Possible fix: Suppress the regulatory.db failure as known benign (WiFi_OnOff passed). For xhci-pci-renesas: install the missing Renesas USB firmware package (renesas_usb_fw.mem) in the rootfs, or blacklist the xhci-pci-renesas driver if the PCIe USB controller is not required for CI testing on qcs6490-rb3gen2.
4. Detail analysis attachment: failed_case_job210625_2_detailed.md

  Case 3: Freq_Scaling

1. Failed case: Freq_Scaling
2. Root cause: Test infrastructure issue — the Freq_Scaling test expects all 8 CPUs (cpu0-cpu7) to be online and have cpufreq interfaces, but CPU6 and CPU7 failed to boot during kernel initialization due to PSCI firmware error -22 (EINVAL: "psci: failed to boot CPU6 (-22)" and "psci: failed to boot CPU7 (-22)"). Only 6 CPUs (cpu0-cpu5) successfully booted. The test checked cpu0-cpu6 cpufreq interfaces (all passed), but failed when checking cpu7, which is offline.
3. Possible fix: This is a pre-existing platform/firmware issue on qcs6490-rb3gen2, not a regression introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds camera sensor DT nodes). The test should be updated to check only online CPUs (/sys/devices/system/cpu/online) rather than assuming all configured CPUs are online. Alternatively, investigate and fix the PSCI firmware issue preventing CPU6 and CPU7 from booting on this platform.
4. Detail analysis attachment: failed_case_job210625_3_detailed.md

  Case 4: ** USBHost — Hardware/Infrastructure Dependency Failure

1. Failed case: ** USBHost — Hardware/Infrastructure Dependency Failure
2. Root cause: ** The qcs6490-rb3gen2 board has a Renesas USB3 PCIe host controller (PCI device 0001:04:00.0) that requires firmware file renesas_usb_fw.mem to initialize. The xhci-pci-renesas driver probe failed with error -2 (ENOENT — file not found), preventing USB host controller initialization. Without a functional USB host controller, no USB devices can be enumerated, causing the USBHost test to fail. This is a pre-existing hardware/firmware dependency issue on this specific board, not introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds IMX577 camera sensor DT changes).
3. Possible fix: Add the missing Renesas USB firmware file renesas_usb_fw.mem to the rootfs /lib/firmware/ directory in the LAVA test image for qcs6490-rb3gen2. The firmware can be obtained from the linux-firmware repository or Renesas vendor package. Alternatively, if USB host functionality is not required for this board's CI validation, mark the USBHost test as SKIP for qcs6490-rb3gen2 in the LAVA job definition.
4. Detail analysis attachment: failed_case_job210625_4_detailed.md

  Case 5: KVM_Driver — /dev/kvm device node unavailable

1. Failed case: KVM_Driver — /dev/kvm device node unavailable
2. Root cause: KVM initialization failed because Gunyah hypervisor is already running at EL2 (HYP mode). On ARM64, only one entity can control EL2 at a time. The kernel message "kvm [1]: HYP mode not available" indicates KVM detected the hypervisor and aborted initialization, preventing /dev/kvm creation. This is a platform configuration issue specific to qcs6490-rb3gen2 running with Gunyah enabled, not a kernel regression.
3. Possible fix: This is expected behavior when Gunyah hypervisor is enabled. To run KVM on this platform: (1) disable Gunyah hypervisor in the bootloader/firmware configuration, OR (2) use nested virtualization if supported by the platform, OR (3) accept that KVM tests will fail on Gunyah-enabled builds and mark them as expected failures in the CI test suite for this platform configuration. The PR (camera sensor DTS changes) is unrelated and did not cause this failure.
4. Detail analysis attachment: failed_case_job210625_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM test failure due to platform limitation — ARM KVM requires EL2 (Hypervisor mode) which is not available on qcs6490-rb3gen2; kernel boot log shows "kvm [1]: HYP mode not available" at line 2849, causing /dev/kvm device node creation to fail, which the test correctly detects and reports.
3. Possible fix: Mark KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) as "skip" or "expected-fail" for qcs6490-rb3gen2 in the LAVA test definition, as this is a known platform limitation unrelated to the PR (which only adds camera sensor DT nodes); long-term fix requires firmware/bootloader update to enable EL2 access.
4. Detail analysis attachment: failed_case_job210625_6_detailed.md

  Case 7: KVM Infrastructure Test — /dev/kvm unavailable (driver probe failure)

1. Failed case: KVM Infrastructure Test — /dev/kvm unavailable (driver probe failure)
2. Root cause: KVM driver probe failed with "HYP mode not available" because the qcs6490-rb3gen2 (Kodiak) platform does not support ARM Virtualization Extensions (EL2/HYP mode) or the bootloader/firmware does not enable EL2 before Linux boot. This is a platform hardware/firmware limitation, not a kernel regression. The PR changes (camera sensor DTSI) are unrelated to KVM functionality.
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the CI test suite for qcs6490-rb3gen2 (Kodiak) platform, as this platform does not support virtualization. If virtualization support is required, verify that the bootloader/firmware enables EL2 mode and that the SoC hardware includes ARM Virtualization Extensions.
4. Detail analysis attachment: failed_case_job210625_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present. The kernel reports "kvm [1]: HYP mode not available" during boot, indicating the platform is not running with EL2 hypervisor support enabled, which is a prerequisite for KVM functionality on ARM64.
3. Possible fix: This is a pre-existing platform/firmware configuration issue, not introduced by the PR (which only adds camera sensor DTS changes). The qcs6490-rb3gen2 board firmware/bootloader is not configured to boot Linux in EL2 mode. To enable KVM: (1) configure the bootloader/firmware to enter the kernel at EL2 instead of EL1, or (2) if the platform does not support EL2 in this configuration, mark KVM tests as expected-fail for this board in the CI test suite.
4. Detail analysis attachment: failed_case_job210625_8_detailed.md

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Configuration Issues

1. Failed case: Probe_Failure_Check — Pre-existing Platform Configuration Issues
2. Root cause: Five driver probe failures detected on purwa-evk (iq-x5121-evk) platform: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to secure world resource conflict, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED DT configuration, (3) two qcom-pcie instances fail with -ENODATA due to missing PCIe PHY/endpoint configuration, and (4) regulatory.db firmware missing from rootfs. These are pre-existing platform/DT/firmware issues unrelated to the PR (which only modifies qcs6490-rb3gen2 camera sensor DT).
3. Possible fix: These probe failures are pre-existing platform issues on purwa-evk and not introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which targets qcs6490-rb3gen2 camera sensors). To resolve: (1) Fix qcom-spmi-lpg DT node "reg" property for multi-LED configuration per driver binding requirements, (2) Add missing PCIe PHY/endpoint DT nodes or mark unused PCIe controllers as "status = disabled", (3) Include regulatory.db firmware file in rootfs image, (4) Investigate qcom_qseecom_uefisecapp secure world resource allocation. Recommend updating the Probe_Failure_Check test to exclude known platform-specific probe failures that do not affect core functionality.
4. Detail analysis attachment: failed_case_job210626_1_detailed.md

  Case 2: smmu (IOMMU Device Attachment Validation Failure)

1. Failed case: smmu (IOMMU Device Attachment Validation Failure)
2. Root cause: Five USB wrapper nodes (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec node (aa00000.video-codec) are missing iommus property in the purwa-evk device tree, preventing IOMMU group attachment during driver probe, while their child DWC3 controller nodes successfully attached to IOMMU groups 9-13.
3. Possible fix: Add iommus property to the six missing device tree nodes in arch/arm64/boot/dts/qcom/purwa-evk.dts (or the appropriate SoC DTSI), referencing the correct SMMU instance and stream IDs for each wrapper node, following the pattern used by successfully attached USB controllers.
4. Detail analysis attachment: failed_case_job210626_2_detailed.md

  Case 3: ** KVM Driver Initialization Failure — HYP mode not available

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** The Purwa IoT EVK platform does not support ARM64 EL2/hypervisor mode, which is required for KVM virtualization. The KVM driver detects this during initialization and fails with "HYP mode not available", preventing /dev/kvm device creation. This is a platform hardware/firmware/bootloader configuration limitation, not a kernel bug.
3. Possible fix: This is not a bug to fix — it is expected behavior on platforms without EL2 support. The KVM_Driver test should be excluded from the Purwa EVK test suite, or the test should be updated to skip gracefully when CONFIG_KVM is enabled but HYP mode is unavailable. If EL2 support is required, the bootloader/firmware must be reconfigured to boot the kernel at EL2 and enable virtualization extensions.
4. Detail analysis attachment: failed_case_job210626_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization detected HYP mode (EL2) is not available on purwa-evk platform — bootloader/firmware does not expose EL2 to Linux, preventing KVM from creating /dev/kvm. This is a platform hardware/firmware limitation, not a kernel regression.
3. Possible fix: Mark KVM tests as "skip" for purwa-evk in CI configuration (platform does not support virtualization in current firmware). If virtualization is required: update bootloader/UEFI to boot Linux at EL2, or configure hypvm.mbn hypervisor to expose EL2 to Linux, then verify /dev/kvm is created.
4. Detail analysis attachment: failed_case_job210626_4_detailed.md

  Case 5: KVM Infrastructure Failure — KVM driver initialization failed (HYP mode not available)

1. Failed case: KVM Infrastructure Failure — KVM driver initialization failed (HYP mode not available)
2. Root cause: KVM driver probe failed during early boot with "HYP mode not available" error on Purwa IoT EVK (purwa-evk). The ARM64 KVM subsystem requires EL2 (Hypervisor Exception Level) support, but the platform either: (1) boots at EL1 without EL2 available, (2) has EL2 disabled in firmware/bootloader, or (3) has a hypervisor already running that prevents KVM from initializing. This is a platform/firmware configuration issue, not a kernel regression introduced by the PR (which only adds camera sensor DT nodes).
3. Possible fix: Verify the Purwa IoT EVK firmware/bootloader configuration enables EL2 and boots the kernel at EL2 or allows EL2 access. Check ABL/XBL boot chain settings for virtualization support. If the platform does not support EL2/virtualization, mark KVM tests as expected-to-skip for this SoC in the CI test matrix rather than treating them as failures.
4. Detail analysis attachment: failed_case_job210626_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM virtualization is not available on the Purwa EVK platform because HYP (Hypervisor) mode is not supported by the hardware/firmware configuration. The kernel log shows "kvm [1]: HYP mode not available" during boot, which prevents the /dev/kvm device node from being created. CONFIG_KVM is enabled in the kernel, but the ARM CPU is not running in EL2 (hypervisor exception level), making KVM functionality unavailable.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression. The PR modifies only camera sensor DTS configuration (IMX577) and does not affect KVM. To enable KVM on Purwa EVK: (1) verify the bootloader/firmware boots the kernel in EL2 mode, (2) ensure the SoC and board support virtualization extensions, (3) if the platform fundamentally lacks HYP support, mark KVM tests as "not applicable" for this board in the CI test matrix.
4. Detail analysis attachment: failed_case_job210626_6_detailed.md

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

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

  Case 1: Probe_Failure_Check — False Positive (Benign Firmware Load Failure)

1. Failed case: Probe_Failure_Check — False Positive (Benign Firmware Load Failure)
2. Root cause: The Probe_Failure_Check test flagged a "regulatory.db" firmware load failure from the cfg80211 wireless regulatory subsystem. However, this is a known benign false positive: (1) the error originates from "faux_driver" (test infrastructure artifact, not a real driver), (2) WiFi functional tests (WiFi_Firmware_Driver and WiFi_OnOff) both passed, confirming wireless subsystem is operational, and (3) regulatory.db is an optional database for wireless regulatory domain enforcement that gracefully falls back to built-in defaults when absent. This failure is not PR-introduced (PR only modifies camera sensor DTS for QCM6490, unrelated to wireless or qcs615-ride platform).
3. Possible fix: Suppress this failure in the Probe_Failure_Check test logic by adding "faux_driver regulatory" and "regulatory.db" to the known-benign firmware load failure exclusion list. The test should not flag regulatory.db failures when WiFi functional tests pass. No kernel or driver fix is required.
4. Detail analysis attachment: failed_case_job210627_1_detailed.md

  Case 2: smmu (Test Validation False Positive)

1. Failed case: smmu (Test Validation False Positive)
2. Root cause: The SMMU test expects video-decoder and video-encoder child devices (aa00000.video-codec:video-decoder, aa00000.video-codec:video-encoder) to have separate IOMMU group attachments, but the Venus video codec driver on qcs615-ride uses the "non legacy binding" where child video devices are created by the driver and share the parent device's (aa00000.video-codec) IOMMU group 7 attachment. The kernel log confirms "qcom-venus aa00000.video-codec: non legacy binding" and shows the parent device correctly attached to IOMMU group 7 with no SMMU/IOMMU errors.
3. Possible fix: Update the SMMU test script to recognize the Venus "non legacy binding" pattern and skip IOMMU group validation for video-decoder/video-encoder child devices when the parent video-codec device is correctly attached to an IOMMU group. The test should check for "non legacy binding" in dmesg and adjust validation logic accordingly.
4. Detail analysis attachment: failed_case_job210627_2_detailed.md

  Case 3: ** KVM_Driver — Platform Architecture Limitation (Gunyah Hypervisor Present)

1. Failed case: ** KVM_Driver — Platform Architecture Limitation (Gunyah Hypervisor Present)
2. Root cause: ** The QCS615 platform boots under the Gunyah hypervisor (version gunyah-1cb9db980 perf), which occupies EL2 (HYP mode). KVM requires exclusive access to EL2 to function, but when Gunyah is already running at EL2, the kernel correctly detects "HYP mode not available" and KVM initialization fails. This is expected behavior on Gunyah-enabled platforms. The test failure is not caused by the PR (which only adds camera sensor DTS changes for QCM6490) but reflects a pre-existing platform configuration where KVM and Gunyah are mutually exclusive.
3. Possible fix: Update the LAVA test definition to detect Gunyah presence (check for "Hypervisor cold boot" or kvm [1]: HYP mode not available in dmesg) and automatically skip KVM tests with message: "SKIP: KVM not available on Gunyah-enabled platforms." Implementation: Add to KVM test run.sh: if dmesg | grep -q "Hypervisor cold boot.*gunyah"; then echo "[SKIP] KVM not applicable on Gunyah platforms"; exit 0; fi. This prevents false failures on platforms where KVM cannot work by design.
4. Detail analysis attachment: failed_case_job210627_3_detailed.md

  Case 4: ** KVM_EL2_DTB — Platform Hardware Limitation (EL2/HYP mode not available)

1. Failed case: ** KVM_EL2_DTB — Platform Hardware Limitation (EL2/HYP mode not available)
2. Root cause: ** The qcs615-ride platform does not support ARM EL2 (Hypervisor mode), as evidenced by the kernel message kvm [1]: HYP mode not available at boot time (timestamp 2026-08-24T07:24:23.009391). Without EL2 support, the KVM driver cannot initialize, and /dev/kvm is never created, causing all KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail at their availability gate.
3. Possible fix: This is not a regression introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds camera sensor DT changes for QCM6490). The KVM tests should be skipped or marked as expected-fail for qcs615-ride in the LAVA test plan, as this platform does not have the hardware capability to run KVM. If KVM support is required, use a different platform that boots with EL2 enabled (e.g., rb3gen2, rb5).
4. Detail analysis attachment: failed_case_job210627_4_detailed.md

  Case 5: ** KVM_Infra (Platform Limitation — Not PR-Introduced)

1. Failed case: ** KVM_Infra (Platform Limitation — Not PR-Introduced)
2. Root cause: ** KVM cannot initialize on QCS615 Ride because the Gunyah hypervisor is already running at EL2 (HYP mode), and ARM architecture allows only one entity at EL2. The kernel correctly detects this and reports "HYP mode not available", preventing /dev/kvm creation.
3. Possible fix: Suppress KVM tests on Gunyah-enabled platforms by adding platform detection in the LAVA test suite. Check for Gunyah presence (dmesg: "Hypervisor cold boot, version: gunyah") and mark KVM tests as SKIP instead of FAIL. For actual KVM testing, use a board configuration where Gunyah is disabled and Linux boots directly at EL2.
4. Detail analysis attachment: failed_case_job210627_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present; kernel reports "HYP mode not available" during boot, indicating the QCS615 Ride platform does not support ARM virtualization extensions (EL2 hypervisor mode is unavailable on this SoC/firmware configuration).
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The test should be skipped on platforms without virtualization support. Add a platform-specific test skip rule for qcs615-ride in the CI test suite, or update the test to gracefully skip when HYP mode is unavailable rather than reporting FAIL.
4. Detail analysis attachment: failed_case_job210627_6_detailed.md

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform issues on qcs9100-ride: (1) Four PMIC temp-alarm devices stuck in deferred probe due to missing thermal zone dependency, (2) regulatory.db firmware file missing (benign - cfg80211 regulatory database is optional), (3) Aquantia AQR115C Ethernet PHY probe failure due to missing/invalid firmware-name property in device tree (error -22 / -EINVAL).
3. Possible fix: These are pre-existing qcs9100-ride platform issues unrelated to the PR (which only modifies qcs6490-rb3gen2 camera sensor DTS). For temp-alarm: verify thermal zone driver is enabled and probing; for Aquantia PHY: add valid firmware-name property to stmmac-0:08 PHY node in qcs9100-ride DTS or mark firmware loading as optional in the driver.
4. Detail analysis attachment: failed_case_job210628_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on qcs9100-ride (sa8775p) platform exists in device tree but is not attached to any IOMMU group, causing the SMMU validation test to fail. This is a pre-existing platform configuration issue unrelated to the PR, which only modifies camera sensor DT for qcs6490-rb3gen2 (a different SoC/board).
3. Possible fix: This is not a PR-introduced regression. The video codec IOMMU attachment issue is specific to the qcs9100-ride test platform. Either: (1) add the missing iommus property to the video-codec DT node in arch/arm64/boot/dts/qcom/sa8775p.dtsi, or (2) update the SMMU test to exclude video codec from critical master checks on sa8775p if video codec IOMMU attachment is not yet supported on this platform.
4. Detail analysis attachment: failed_case_job210628_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no USB devices physically connected to qcs9100-ride board; only USB root hubs enumerated (Bus 001/002/003 all show "Linux Foundation root hub" with no downstream devices).
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard) to one of the board's USB host ports before running the USBHost test; if devices are connected, verify USB VBUS power is enabled and cables are functional.
4. Detail analysis attachment: failed_case_job210628_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed because three individual test cases within the suite failed: (1) Probe_Failure_Check detected deferred probe devices and an Aquantia AQR115C ethernet PHY probe failure (error -22), (2) smmu test detected video codec device aa00000.video-codec missing IOMMU group attachment, and (3) USBHost test detected no functional USB devices connected (only root hubs present). These are pre-existing platform/infrastructure issues unrelated to the PR changes (PR adds IMX577 camera sensor DT for QCS6490-rb3gen2, but test runs on QCS9100-ride).
3. Possible fix: Re-trigger the CI job. If failures persist: (1) For Probe_Failure_Check: investigate Aquantia AQR115C PHY driver compatibility with QCS9100 hardware revision and check for missing device tree properties or firmware; investigate deferred probe timeout for PMIC temp-alarm devices. (2) For smmu: verify video codec driver probe sequence and IOMMU domain attachment in kernel logs; check if video codec DT node has correct iommus property. (3) For USBHost: this is a hardware/lab setup issue—ensure USB test devices are physically connected to the QCS9100-ride board's USB ports before running the test.
4. Detail analysis attachment: failed_case_job210628_4_detailed.md

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected deferred probe entries for four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and three firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv); however, the firmware failures are false positives as both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming firmware loaded correctly at runtime. The deferred probe warnings for temp-alarm devices are benign — these devices are non-critical thermal monitoring sensors on lemans-evk that commonly remain in deferred state when their thermal zone dependencies are not fully configured, and do not impact system functionality.
3. Possible fix: Suppress the BT and WiFi firmware load failures per lava-known-benign-failures.md Rules 2 and 3 (functional tests passed). For the temp-alarm deferred probes: these are expected on lemans-evk when thermal zones are not fully configured in the device tree; if thermal monitoring is required, add the missing thermal zone bindings for these PMICs in the lemans device tree, otherwise these warnings can be ignored as they do not affect boot or runtime stability.
4. Detail analysis attachment: failed_case_job210629_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec on lemans-evk (SA8775P) is not attached to any IOMMU group, failing the SMMU test's critical master protection check; however, no SMMU/IOMMU errors appear in dmesg and the device tree node exists, indicating the video codec driver either did not probe or probed without IOMMU attachment on this platform.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which adds camera sensor support for QCS6490/rb3gen2, not lemans-evk). Verify whether the video codec driver is expected to probe on lemans-evk; if yes, check the device tree for missing iommus property in the aa00000.video-codec node or investigate why the driver probe did not attach to IOMMU; if the video codec is not supported on this platform, update the SMMU test to exclude aa00000.video-codec from critical master checks on lemans-evk.
4. Detail analysis attachment: failed_case_job210629_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner marked the test suite as failed due to two sub-test failures (Probe_Failure_Check and smmu) that are pre-existing platform issues unrelated to the PR changes. The PR modifies QCS6490 (RB3Gen2) camera sensor device tree, but the test ran on lemans-evk (SA8775P) platform. The Probe_Failure_Check failure is caused by deferred probe of temp-alarm devices and missing firmware files (regulatory.db, Bluetooth firmware) which are known benign issues. The smmu failure is due to missing iommu_group attachment for video codec (aa00000.video-codec) on lemans-evk, a pre-existing platform configuration issue.
3. Possible fix: These failures are not introduced by the PR. The PR changes are scoped to QCS6490 camera sensor configuration and do not affect lemans-evk platform. The test failures should be suppressed as pre-existing platform issues: (1) Probe_Failure_Check: deferred probe warnings and firmware load failures are benign and do not indicate functional regression; (2) smmu: video codec iommu_group attachment issue is a known lemans-evk platform limitation. Re-run the test on QCS6490 (RB3Gen2) hardware to validate the actual PR changes, or mark these lemans-evk failures as expected/suppressed for this PR.
4. Detail analysis attachment: failed_case_job210629_3_detailed.md

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Two pre-existing platform issues on qcs8300-ride: (1) Aquantia AQR115C Ethernet PHY probe fails with -EINVAL due to missing firmware-name property in device tree node; (2) regulatory.db firmware file missing from rootfs causing cfg80211 to fall back to built-in regulatory rules. Neither failure is introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815, which only modifies qcs6490 camera sensor device tree.
3. Possible fix: (1) Add firmware-name property to Aquantia PHY node in qcs8300-ride device tree, or update Aquantia driver to treat property as truly optional with sensible default; (2) Include wireless-regdb package in rootfs build to provide regulatory.db firmware. Both are platform-specific fixes orthogonal to this PR. Recommended action for PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815: Approve and merge — these probe failures are pre-existing qcs8300-ride platform issues unrelated to the qcs6490 camera sensor changes in this PR.
4. Detail analysis attachment: failed_case_job210630_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB device physically connected to the qcs8300-ride test board; only the USB 2.0 root hub (Bus 001 Device 001: ID 1d6b:0002) is enumerated, indicating the USB host controller is functional but no peripheral devices are attached.
3. Possible fix: This is not a kernel regression introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds IMX577 camera sensor DT changes for QCM6490). The USBHost test requires a physical USB device to be connected to the board's USB port. Verify the LAVA lab setup for qcs8300-ride includes a USB peripheral device (e.g., USB storage, keyboard, or hub with downstream devices) connected to the board before running this test. If the test is optional for boards without USB peripherals, mark it as skipped rather than failed, or update the test to distinguish between "USB host controller not working" vs "no device connected."
4. Detail analysis attachment: failed_case_job210630_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm device node not available

1. Failed case: KVM_Driver — /dev/kvm device node not available
2. Root cause: KVM driver initialization fails because the QCS8300-Ride platform runs Linux as a guest under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-1cb9db980"). KVM requires EL2 (hypervisor mode) access to create virtual machines, but when Linux runs at EL1 under Gunyah, it cannot access EL2, causing KVM to silently skip device node creation. This is a platform design constraint, not a kernel bug.
3. Possible fix: This is not a bug to fix but a platform configuration reality. If KVM functionality is required on QCS8300-Ride, the platform must be reconfigured to boot Linux directly at EL2 without the Gunyah hypervisor, or Gunyah must be configured to support nested virtualization (if supported by the hardware and hypervisor version). For CI purposes, mark KVM tests as "not applicable" or "skip" for QCS8300-Ride targets running under Gunyah. The PR under test (camera sensor DTSI changes) is unrelated to this failure and should not be blocked by it.
4. Detail analysis attachment: failed_case_job210630_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM device node /dev/kvm is not available because the kernel is running as a guest VM under the Gunyah hypervisor (EL1), not as a host with EL2 access required for KVM functionality. The test failure is not caused by the PR (camera sensor DTS changes for QCM6490) but is a pre-existing platform configuration issue where KVM tests are executed on qcs8300-ride which runs under Gunyah hypervisor.
3. Possible fix: Exclude KVM tests from the qcs8300-ride LAVA test suite, as this platform runs under Gunyah hypervisor and cannot support KVM (nested virtualization is not enabled). Alternatively, run KVM tests only on bare-metal platforms or platforms with nested virtualization support enabled.
4. Detail analysis attachment: failed_case_job210630_4_detailed.md

  Case 5: KVM_Infra — KVM device node not created

1. Failed case: KVM_Infra — KVM device node not created
2. Root cause: KVM ARM driver failed to initialize on qcs8300-ride platform running under Gunyah hypervisor; CONFIG_KVM is enabled but /dev/kvm device node was never created, indicating KVM driver probe/init failed silently without error messages in dmesg.
3. Possible fix: This is a pre-existing platform/hypervisor compatibility issue, not introduced by the PR (PR only modifies qcs6490-rb3gen2 camera sensor DT). The qcs8300-ride platform with Gunyah hypervisor does not support nested virtualization (KVM requires EL2 access, but Gunyah hypervisor is already running at EL2). Either: (1) disable KVM tests for qcs8300-ride in CI, or (2) investigate whether Gunyah can expose a paravirtualized KVM interface, or (3) run KVM tests only on platforms without a hypervisor.
4. Detail analysis attachment: failed_case_job210630_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS8300 Ride platform runs Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-1cb9db980"), not KVM. CONFIG_KVM is enabled in kernel config but /dev/kvm device node is never created because the platform does not support KVM virtualization at EL2 — Gunyah occupies EL2 instead.
3. Possible fix: Mark KVM tests as "not applicable" for QCS8300 Ride in the LAVA test suite configuration, or add a platform-specific skip condition that checks for Gunyah hypervisor presence before running KVM tests. This is a platform architecture limitation, not a regression introduced by the PR (which only modifies camera sensor DTS for QCM6490).
4. Detail analysis attachment: failed_case_job210630_6_detailed.md

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

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

  Case 1: GIC (Test Script Bug — Not a Kernel Issue)

1. Failed case: GIC (Test Script Bug — Not a Kernel Issue)
2. Root cause: The GIC test script hardcodes an assumption of 8 CPUs and attempts to parse /proc/interrupts timer counts for CPUs 4-7, but the shikra-iqs-evk platform has only 4 CPUs (0-3). The script's integer comparison at line 75 fails when it encounters non-numeric fields ("GICv3", "Level", "arch_timer") from the interrupt line format, causing false failures for non-existent CPUs 4-7. CPUs 0-3 all passed the timer increment test, confirming GIC and arch_timer interrupts are functioning correctly.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding CPU count assumptions. The script should only validate timer interrupts for CPUs that actually exist on the platform.
4. Detail analysis attachment: failed_case_job210631_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected pre-existing platform-specific probe failures on shikra-iqs-evk (coresight-etm4x -EINVAL, cpufreq-dt -EEXIST, regulatory.db -ENOENT) that are unrelated to the PR's camera sensor DTS changes for qcs6490-rb3gen2.
3. Possible fix: Mark as false positive for this PR. The PR modifies qcs6490-rb3gen2-camera-sensor.dtsi but test runs on shikra-iqs-evk (SC8380XP). These probe failures are pre-existing platform issues: (1) coresight-etm4x requires DT/firmware fixes for SC8380XP ETM configuration, (2) cpufreq-dt -EEXIST is a known benign duplicate registration, (3) regulatory.db is optional firmware. None are regressions from this camera DTS change.
4. Detail analysis attachment: failed_case_job210631_2_detailed.md

  Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** No USB devices enumerated on shikra-iqs-evk during test execution. USB core subsystem initialized correctly (usbcore, usbhid, usb-storage drivers loaded), USB PHYs (phy_qcom_qusb2, phy_qcom_qmp_usbc) loaded, and USB controller (4e00000.usb) added to IOMMU group 5, but no USB host controller (DWC3/XHCI) probe messages appear in kernel log, and USB subsystem is in gadget/peripheral mode ("Hardware activated USB gadget" at boot). This indicates either: (1) USB controller configured in device/peripheral mode in device tree (dr_mode = "peripheral" or "otg" defaulting to peripheral), (2) no physical USB host port on the board, or (3) no USB device physically connected to the test fixture.
3. Possible fix: This is a test infrastructure / board configuration issue, not a kernel bug introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only modifies camera sensor device tree for QCS6490 rb3gen2, unrelated to USB). Recommended actions: (1) Verify shikra-iqs-evk hardware has a USB host port and that a USB device (e.g., USB flash drive, keyboard) is physically connected during the test. (2) Check the device tree for the USB controller node (usb@4e00000) and confirm dr_mode property — if set to "peripheral" or "otg", change to "host" to enable USB host mode. (3) If the board does not support USB host mode, mark this test as SKIP for shikra-iqs-evk in the LAVA test definition.
4. Detail analysis attachment: failed_case_job210631_3_detailed.md

  Case 4: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)

1. Failed case: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)
2. Root cause: ** The qcom_rng driver on Shikra IQS EVK triggered a synchronous external abort when attempting to read RNG hardware MMIO registers during the qcom_hwrng test. This hardware bus error indicates the RNG block is not accessible (power/clock/reset misconfiguration or board-specific DT issue). This is a pre-existing platform bug completely unrelated to the PR, which only adds camera sensor DT nodes.
3. Possible fix: Investigate RNG hardware block power/clock/reset configuration in the Shikra IQS EVK device tree. Verify qcom,prng DT node has correct reg, clocks, and power-domains properties. Check if RNG block requires explicit power domain enablement or clock gating workaround on this platform. As a short-term mitigation, disable the qcom_hwrng test for Shikra IQS EVK until the platform issue is resolved.
4. Detail analysis attachment: failed_case_job210631_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel bug or PR-introduced regression. To resolve: (1) Enable EL2 in the platform firmware/bootloader configuration for Shikra IQS EVK, OR (2) Update the LAVA test suite to skip KVM tests on platforms without EL2 support by checking for /dev/kvm availability or CONFIG_KVM + HYP mode capability before running virtualization tests.
4. Detail analysis attachment: failed_case_job210631_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm is not present on the target despite CONFIG_KVM being enabled in the kernel configuration, indicating the KVM kernel module failed to load or create the device node during boot on Shikra IQS EVK.
3. Possible fix: Verify that CONFIG_KVM_ARM_HOST=y (not =m) is set in the kernel configuration to ensure KVM is built-in rather than as a module, or if built as a module, ensure the kvm.ko and kvm-arm.ko modules are present in the rootfs and loaded during boot via modprobe or initramfs.
4. Detail analysis attachment: failed_case_job210631_6_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xc4 while attempting to read from a hardware register during the qcom_hwrng test. The fault indicates the hardware RNG block was either not powered/clocked correctly, not mapped correctly, or the register address is invalid for the shikra-iqs-evk platform. After the crash, the system entered a warm reset loop and did not reach crashdump/EDL mode, causing LAVA to timeout waiting for test completion.
3. Possible fix: Verify that the qcom,prng-ee device tree node for shikra (SM8450 derivative) has the correct register base address and that the RNG hardware block is properly enabled in the device tree. If the RNG block is not present or not functional on shikra-iqs-evk, disable the qcom_rng driver for this platform or mark the DT node as status = "disabled". Additionally, ensure crashdump kernel cmdline arguments (reboot=panic_warm, qcom_scm.download_mode=1) and TCSR DT nodes are present to enable ramdump collection on future crashes.
4. Detail analysis attachment: failed_case_job210631_7_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware random number generator (qcom_rng) driver triggered a synchronous external abort (ESR 0x96000010) at qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The abort indicates the driver attempted to access an unmapped or inaccessible MMIO register, causing the CPU to receive an external abort from the memory subsystem. This is a pre-existing platform/driver issue on shikra-iqs-evk, not introduced by the PR (which only modifies camera sensor DTS for qcs6490-rb3gen2).
3. Possible fix: This is a pre-existing kernel/driver bug on shikra-iqs-evk unrelated to the PR under test. The PR modifies only camera sensor device tree for qcs6490-rb3gen2 and does not touch qcom_rng driver or shikra platform files. Recommended action: (1) Mark this LAVA job as infrastructure failure / pre-existing bug; (2) File a separate bug for qcom_rng driver on shikra-iqs-evk with full crash log; (3) Investigate whether the RNG hardware block is properly clocked/powered and whether the MMIO base address in the device tree matches the hardware specification for this SoC; (4) Re-run the PR validation on a different board or with qcom_hwrng test disabled until the driver issue is resolved.
4. Detail analysis attachment: failed_case_job210631_8_detailed.md

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

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: The kernel crashed with a synchronous external abort (hardware bus error) at address 0x96000010 while reading from the Qualcomm hardware RNG device (qcom_rng_read+0xc4), triggered by a dd process reading from /dev/hwrng. The crash occurred during the KVM_Driver test execution (~735 seconds after boot), followed by cascading EFI runtime service paging faults during panic handling, and then a warm reboot. The LAVA test timed out (2400s limit) because the board never completed the reboot and test resumption within the allowed window.
3. Possible fix: This is a hardware-level bus fault in the RNG hardware block, not introduced by the PR (which only adds camera sensor DT nodes for a different SoC). The crash is SoC/board-specific to shikra-iqs-evk and indicates either: (1) RNG hardware block not properly powered/clocked when accessed, (2) incorrect RNG MMIO mapping in the shikra DT, or (3) transient hardware fault. Recommended actions: (1) verify qcom,prng-ee DT node in arch/arm64/boot/dts/qcom/sm8450.dtsi and shikra board DTS has correct reg property and power-domain/clock bindings; (2) add error handling in qcom_rng_read to detect and recover from bus faults gracefully instead of crashing; (3) re-trigger the CI job to confirm if the issue is reproducible or transient; (4) if reproducible, collect a ramdump to inspect RNG hardware register state and power/clock status at crash time.
4. Detail analysis attachment: failed_case_job210631_9_detailed.md

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

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: Hardware random number generator (qcom_rng) driver triggered a synchronous external abort at qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read entropy from /dev/hwrng on shikra-iqs-evk; the fault indicates an invalid MMIO register access, likely due to missing or incorrect clock/power domain configuration for the RNG hardware block on this SoC.
3. Possible fix: This is a pre-existing platform/driver issue unrelated to PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds camera sensor DTS for QCS6490/rb3gen2). The RNG driver or shikra-iqs-evk device tree needs investigation: verify that the RNG device node has correct clock, power-domain, and register base properties for shikra (SM8450-based); consider disabling the qcom_hwrng test on shikra-iqs-evk until the RNG hardware configuration is fixed, or add a platform-specific quirk to skip RNG on boards where it's not properly configured.
4. Detail analysis attachment: failed_case_job210631_10_detailed.md

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

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

  Case 1: ** Probe_Failure_Check — Firmware Load Failure + WiFi Probe Failure

1. Failed case: ** Probe_Failure_Check — Firmware Load Failure + WiFi Probe Failure
2. Root cause: ** The monaco-evk rootfs image is missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin, causing ath11k_pci driver probe to fail with error -110 (ETIMEDOUT). This is a pre-existing platform/infra issue, not introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds camera sensor DT nodes for a different SoC).
3. Possible fix: Install the linux-firmware package (or Qualcomm-specific firmware package) containing ath11k/WCN6855/hw2.1/nfa765/amss.bin into the monaco-evk rootfs. Alternatively, if WiFi is not required for this test platform, suppress ath11k probe failures in the Probe_Failure_Check test script for monaco-evk.
4. Detail analysis attachment: failed_case_job210632_1_detailed.md

  Case 2: ** WiFi_Firmware_Driver — Driver Probe Failure (Firmware Dependency)

1. Failed case: ** WiFi_Firmware_Driver — Driver Probe Failure (Firmware Dependency)
2. Root cause: ** ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ directory. The MHI bus cannot power up the WCN6855 WiFi chip without this firmware, causing the probe to timeout.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk rootfs image under /lib/firmware/. The firmware should be sourced from the linux-firmware repository or Qualcomm's firmware package for WCN6855 hw2.1 variant. Rebuild the rootfs image and re-flash to monaco-evk.
4. Detail analysis attachment: failed_case_job210632_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci

1. Failed case: WiFi Driver Probe Failure — ath11k_pci
2. Root cause: WiFi driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs on monaco-evk. MHI subsystem returned -2 (ENOENT) when attempting to load the firmware, causing the MHI power-up sequence to time out. This is a pre-existing platform-specific firmware packaging issue unrelated to PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815, which only modifies camera sensor DT for qcs6490-rb3gen2.
3. Possible fix: Add the missing WCN6855 WiFi firmware files to the monaco-evk rootfs image. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are included in /lib/firmware/ during image build. Verify firmware package version matches the kernel driver expectations for WCN6855 hw2.1 on monaco platform.
4. Detail analysis attachment: failed_case_job210632_3_detailed.md

  Case 4: Driver Probe Failure — ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT)

1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT)
2. Root cause: The ath11k_pci WiFi driver failed to probe on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -2 = -ENOENT). The MHI bus failed to load the firmware, causing the driver initialization to timeout (-110 = -ETIMEDOUT). This is a pre-existing infrastructure/firmware packaging issue on monaco-evk, not introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 which only adds camera sensor DT nodes for QCS6490 (a different SoC).
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk rootfs image under /lib/firmware/. The firmware should be packaged in the linux-firmware repository or the board-specific firmware package. This is a build/packaging issue, not a kernel code issue. The PR changes are unrelated and safe to merge.
4. Detail analysis attachment: failed_case_job210632_4_detailed.md

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Three pre-existing platform driver probe failures unrelated to PR changes: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource conflict, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED DT "reg" property on hamoa-evk, (3) regulatory.db firmware missing from rootfs causing -ENOENT.
3. Possible fix: These are known platform issues on hamoa-evk, not PR-introduced regressions. The PR modifies camera sensor DT for rb3gen2 and does not affect these drivers. Recommended action: suppress these known failures in the Probe_Failure_Check test for hamoa-evk, or fix the underlying platform issues: (1) resolve qseecom TZ resource allocation, (2) correct the SPMI LPG multi-LED DT binding in hamoa DTS, (3) add regulatory.db to the rootfs image.
4. Detail analysis attachment: failed_case_job210633_1_detailed.md

  Case 2: ** smmu (IOMMU group attachment validation)

1. Failed case: ** smmu (IOMMU group attachment validation)
2. Root cause: ** Six critical platform devices on hamoa-evk (QCM6490) are missing IOMMU group attachments in the device tree: five USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec device (aa00000.video-codec). The SMMU/IOMMU subsystem is functional (35 groups created, no kernel errors), but these devices lack the required iommus property in their DT nodes, leaving them unprotected by the IOMMU. This is a pre-existing platform DT configuration gap, not introduced by PR QCLINUX: arm64: dts: qcom: Add IMX577 DTSI changes to Support CAM1 #815 (which only adds camera sensor nodes for a different board variant).
3. Possible fix: Add iommus properties to the six missing device nodes in the hamoa-evk (QCM6490) device tree. For USB controllers, reference the appropriate SMMU instance and stream ID based on the platform's SMMU topology (likely <&apps_smmu 0x<stream_id> 0>). For the video codec at aa00000, reference the video SMMU context. Verify the correct stream IDs from the SoC integration manual or by inspecting similar working USB/video nodes in related QCM6490 DTs. This is a platform-specific DT fix, not a kernel driver issue.
4. Detail analysis attachment: failed_case_job210633_2_detailed.md

  Case 3: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** KVM driver initialization failed because Gunyah hypervisor already owns EL2 (Hypervisor mode) on the Hamoa IoT EVK platform. KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present. This is a platform architecture constraint, not a kernel bug.
3. Possible fix: This is a pre-existing platform characteristic, not a regression. The KVM_Driver test should be skipped on Gunyah-enabled platforms (hamoa-evk) where KVM cannot function. Add platform-specific test exclusion rules to the LAVA test suite to skip KVM tests when Gunyah hypervisor is detected in boot logs.
4. Detail analysis attachment: failed_case_job210633_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform Capability Limitation (EL2/HYP Mode Not Available)

1. Failed case: KVM_EL2_DTB — Platform Capability Limitation (EL2/HYP Mode Not Available)
2. Root cause: The hamoa-evk platform does not support ARM EL2 (Hypervisor) mode, which is a mandatory hardware/firmware prerequisite for KVM virtualization. Kernel correctly detects this limitation at boot time with message "kvm [1]: HYP mode not available" and does not create /dev/kvm device node.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The test expectation is incorrect for this platform. Recommended actions: (1) Disable KVM tests in the LAVA job definition for hamoa-evk, or (2) Update the test to skip gracefully when /dev/kvm is not present on platforms without EL2 support, or (3) If EL2 support is expected, work with the firmware team to enable EL2 mode in the bootloader/UEFI configuration for hamoa-evk.
4. Detail analysis attachment: failed_case_job210633_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the LAVA job definition or test suite configuration to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on hamoa-evk platform, since this platform does not support the required hardware capability. Add a platform capability check in the test runner to automatically skip KVM tests on platforms without EL2 support. This is NOT a PR-introduced issue — the PR only modifies camera sensor DTS for a different platform (QCS6490 rb3gen2).
4. Detail analysis attachment: failed_case_job210633_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Test infrastructure issue — KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) fail on hamoa-evk platform because the SoC does not support hardware virtualization (HYP mode not available). The kernel correctly reports kvm [1]: HYP mode not available and does not create /dev/kvm. This is expected behavior for platforms without EL2/HYP support, not a kernel bug.
3. Possible fix: Update the LAVA test suite to skip KVM tests on platforms without HYP mode support (check for CONFIG_KVM=y AND verify HYP mode availability via /sys/hypervisor/type or kernel log before running KVM tests), OR add hamoa-evk to the KVM test exclusion list in the test plan configuration.
4. Detail analysis attachment: failed_case_job210633_6_detailed.md

Test jobs on dc394eb

• multimedia Job 215956 on hamoa-iot-evk
• multimedia Job 215951 on lemans-evk
• multimedia Job 215953 on monaco-evk
• multimedia Job 215957 on purwa-iot-evk
• multimedia Job 215955 on qcs615-ride
• multimedia Job 215952 on qcs6490-rb3gen2
• multimedia Job 215949 on qcs8300-ride
• multimedia Job 215950 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 215954 on shikra-iqs-evk

Test Matrix

Test jobs on dc394eb

• multimedia Job 215956 on hamoa-iot-evk
• multimedia Job 218058 on lemans-evk
• multimedia Job 215953 on monaco-evk
• multimedia Job 215957 on purwa-iot-evk
• multimedia Job 215955 on qcs615-ride
• multimedia Job 215952 on qcs6490-rb3gen2
• multimedia Job 215949 on qcs8300-ride
• multimedia Job 215950 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 215954 on shikra-iqs-evk

Test Matrix