FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp

[JeevanPallapothu999]

Commit bb21ee3 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") fixed the
iio_read_channel_processed_scale to return 0 on success instead of IIO_VAL_INT (1). The existing check in adc_tm5_get_temp() treated a successful return as an error because it expected IIO_VAL_INT. Drop the redundant ret != IIO_VAL_INT condition and rely solely on the negative error check.

Fixes: bb21ee3 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale")

Reviewed-by: Jonathan Cameron jonathan.cameron@oss.qualcomm.com
Acked-by: Jonathan Cameron jonathan.cameron@oss.qualcomm.com #from IIO
Link: https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/
CRs-Fixed: 4636200

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4636200 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4636200

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[kotarake]

change got merged on linux-next , so change tag to FROMGIT

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4636200 is not eligible for merge.

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

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

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

[qcomlnxci]

Test jobs on 6073a13

• multimedia Job 207975 on hamoa-iot-evk
• multimedia Job 207972 on lemans-evk
• multimedia Job 207974 on monaco-evk
• multimedia Job 207978 on purwa-iot-evk
• multimedia Job 207973 on qcs615-ride
• multimedia Job 207977 on qcs6490-rb3gen2
• multimedia Job 207976 on qcs8300-ride
• multimedia Job 207970 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 207971 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qlijarvis]

PR #984 — validate-patch

PR: #984

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/

2. Lore link matches PR commits: Yes — commit message body, Fixes tag, and diff content are identical; FROMGIT: prefix correctly added

3. Upstream patch status: ✅ ACKed — Applied by Daniel Lezcano (thermal maintainer) on 27 Jul 2026; also received Reviewed-by: from Jonathan Cameron (IIO maintainer) on 25 Jul 2026

4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Note on integration presence: The FROMGIT: prefix indicates this patch has been accepted into a maintainer's git tree (thermal subsystem) but not yet merged into mainline. It is normal and expected that such commits are not yet present in qcom-next or topic branches. Once the thermal maintainer's tree is merged into mainline during the next merge window, and qcom-next rebases on the new mainline, this commit will naturally appear in qcom-next. The absence from qcom-next/topics is not a validation failure for FROMGIT: commits.

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #984 - "FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp"
Upstream commit: https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check	Status	Note
Subject matches upstream	✅	Subject identical except for FROMGIT: prefix (correct)
Body preserves rationale	✅	Body text identical to lore patch
Fixes tag present/correct	✅	Fixes: bb21ee31f575 present and correct
Authorship preserved	✅	From: matches lore author (Rakesh Kota)
Backport note (if applicable)	N/A	Not a backport - patch applied to maintainer tree but not yet in mainline

Diff

File	Status	Notes
drivers/thermal/qcom/qcom-spmi-adc-tm5.c	✅	Diff identical to lore patch (removes 3 lines checking ret != IIO_VAL_INT)

Diff comparison: The code changes are byte-for-byte identical between the PR and lore patch. Both remove the same 3-line block checking for IIO_VAL_INT return value. The only difference is the git index hash (context difference in the target tree), which is expected and acceptable.

Issues

None. The PR commit faithfully represents the upstream lore patch with appropriate FROMGIT: prefix and correct authorship/tags.

Verdict

✅ Merge as-is. This is a faithful representation of the upstream patch with correct prefix, authorship, commit message, and diff content.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/

2. Lore link matches PR commits: Yes — commit message body, Fixes tag, and diff content are identical; FROMGIT: prefix correctly added

3. Upstream patch status: ✅ ACKed — Applied by Daniel Lezcano (thermal maintainer) on 27 Jul 2026; also received Reviewed-by: from Jonathan Cameron (IIO maintainer) on 25 Jul 2026

4. PR present in qcom-next/topics: No — per integration_presence_report.md, commit is missing from both qcom-next (3c1e80ceb9fb) and all topic branches. This is expected and correct for a FROMGIT: commit that was just applied to the upstream maintainer tree (thermal) on 27 Jul 2026 and has not yet been merged into Linus's tree or pulled into qcom-next.

Note on integration presence: The FROMGIT: prefix indicates this patch has been accepted into a maintainer's git tree (thermal subsystem) but not yet merged into mainline. It is normal and expected that such commits are not yet present in qcom-next or topic branches. Once the thermal maintainer's tree is merged into mainline during the next merge window, and qcom-next rebases on the new mainline, this commit will naturally appear in qcom-next. The absence from qcom-next/topics is not a validation failure for FROMGIT: commits.

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] FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check	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]

PR #984 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 warnings: unknown commit ID referenced in commit message and Fixes tag
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMGIT: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #984 - FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32335411749
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	2 warnings: unknown commit ID referenced in commit message and Fixes tag
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMGIT: prefix

---

❌ checkpatch

Root cause: The commit references bb21ee31f575 in both the commit message body and the Fixes: tag, but this commit SHA does not exist in the target branch (qcom-6.18.y).

Failure details:

WARNING: Unknown commit id 'bb21ee31f575', maybe rebased or not pulled?
#7: 
Commit bb21ee31f575 ("iio: Fix iio_multiply_value use in

WARNING: Unknown commit id 'bb21ee31f575', maybe rebased or not pulled?
#15: 
Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale")

5efafe3b9b62596f0c166e3be0f5d4a870c2edac total: 0 errors, 2 warnings, 0 checks, 9 lines checked

Analysis:

The patch uses FROMGIT: prefix, indicating it was taken from a maintainer git tree. The commit bb21ee31f575 referenced in the Fixes: tag is the upstream commit that introduced the issue this patch fixes. However, this upstream commit does not exist in the qcom-6.18.y branch yet.

This is a false positive — the warning is expected when backporting a fix for an upstream commit that hasn't been merged into the target stable branch. The Fixes: tag correctly identifies the upstream commit that introduced the regression, which is standard practice for backports.

Recommendation: This warning can be safely ignored. The Fixes: tag is correct and follows kernel conventions for identifying the commit that introduced the issue being fixed.

Reproduce locally:

./scripts/checkpatch.pl --strict --summary-file --ignore FILE_PATH_CHANGES --git d1996e72bb5d27f7f7a4920f5cc7b0ca0dba463c..5efafe3b9b62596f0c166e3be0f5d4a870c2edac

---

Verdict

Ready to merge. The only failure is a checkpatch warning about an unknown commit ID, which is expected and acceptable when backporting a fix that references an upstream commit not yet present in the target stable branch. All other checkers passed cleanly.

The patch:

• Has a valid FROMGIT: subject prefix
• Includes proper upstream link (Link: tag)
• Has appropriate sign-offs and reviews
• Makes no DT, binding, or UAPI changes
• Passes sparse static analysis
• Passes patch compliance checks

[qlijarvis]

PR #984 — validate-patch

PR: #984

Verdict	Issues	Detailed Report
⚠️	5	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/

2. Lore link matches PR commits: Yes — commit message body, Fixes tag, and diff content are identical; PR correctly adds review tags from lore thread and Link tag

3. Upstream patch status: ✅ ACKed — Applied by thermal maintainer Daniel Lezcano on 2026-07-27; Reviewed-by and Acked-by from IIO maintainer Jonathan Cameron on 2026-07-25

4. 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: #984 - FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp
Upstream commit: https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	✅	Subject identical except for FROMGIT: prefix (expected)
Body preserves rationale	✅	Commit message body is identical to lore patch
Fixes tag present/correct	✅	Fixes tag matches lore patch exactly
Authorship preserved	✅	Author matches lore patch (Rakesh Kota)
Backport note (if applicable)	N/A	Not a backport - patch is FROMGIT (queued in maintainer tree)
Review tags added	✅	Added Reviewed-by and Acked-by from Jonathan Cameron (present in lore thread)
Link tag added	✅	Link to lore.kernel.org correctly added

Diff

File	Status	Notes
drivers/thermal/qcom/qcom-spmi-adc-tm5.c	✅	Diff content identical to lore patch (only index hash differs due to tree state)

Upstream Patch Status

Commit	Community Verdict
thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check	✅ ACKed — Applied by Daniel Lezcano (thermal maintainer) on 2026-07-27

Evidence from lore thread:

• Jonathan Cameron (IIO maintainer) provided Reviewed-by on 2026-07-25
• Daniel Lezcano (thermal maintainer) replied "Applied, thanks" on 2026-07-27
• Patch has been accepted into the thermal subsystem tree

Integration Presence (qcom-next/topics)

Commit	Status
FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check	❌ Not in qcom-next or topics

From integration_presence_report.md:

• Status: FAIL - commit missing from both qcom-next and topics
• This is expected for a FROMGIT: commit that was just applied to the upstream maintainer tree (2026-07-27) but hasn't yet propagated to qcom-next

Issues

Minor prefix inconsistency:

• The PR uses FROMGIT: prefix, which is appropriate for patches queued in a maintainer's git tree
• However, since Daniel Lezcano (thermal maintainer) has explicitly applied this patch ("Applied, thanks" on 2026-07-27), the patch is now in the thermal maintainer tree
• The FROMGIT: prefix is correct for this stage - the patch will eventually reach mainline and could be updated to UPSTREAM: at that point

Integration presence:

• The commit is not yet in qcom-next or topics, which is expected given the recent acceptance (2026-07-27)
• This is not a validation failure for a FROMGIT: commit - it indicates the patch is newer than the current qcom-next snapshot

Verdict

Merge as-is. The patch faithfully represents the upstream lore submission, has been accepted by the thermal maintainer (Daniel Lezcano), includes proper review tags from the IIO maintainer (Jonathan Cameron), and uses the correct FROMGIT: prefix for a patch queued in a maintainer tree. The absence from qcom-next/topics is expected for a recently-accepted upstream patch.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/

2. Lore link matches PR commits: Yes — commit message body, Fixes tag, and diff content are identical; PR correctly adds review tags from lore thread and Link tag

3. Upstream patch status: ✅ ACKed — Applied by thermal maintainer Daniel Lezcano on 2026-07-27; Reviewed-by and Acked-by from IIO maintainer Jonathan Cameron on 2026-07-25

4. PR present in qcom-next/topics: No — commit missing from both qcom-next (ref 3c1e80ceb9fb) and topics; this is expected for a FROMGIT: patch recently accepted upstream (2026-07-27) that hasn't yet propagated to the Qualcomm integration branches

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] FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check	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]

PR #984 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 warnings: Unknown commit id 'bb21ee31f575'
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMGIT: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #984 - FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32337871997

Checker	Result	Summary
checkpatch	❌	2 warnings: Unknown commit id 'bb21ee31f575'
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	✅	Passed
tag-check	✅	Subject has valid FROMGIT: prefix

❌ checkpatch

Root cause: The commit references bb21ee31f575 in both the commit message body and the Fixes: tag, but this commit SHA is not present in the current kernel tree at the time of the check.

Failure details:

WARNING: Unknown commit id 'bb21ee31f575', maybe rebased or not pulled?
#7: 
Commit bb21ee31f575 ("iio: Fix iio_multiply_value use in

WARNING: Unknown commit id 'bb21ee31f575', maybe rebased or not pulled?
#15: 
Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale")

6073a130ac183f81ac58d2411029aa9b00425049 total: 0 errors, 2 warnings, 0 checks, 9 lines checked

Analysis: This is a false positive warning. The commit bb21ee31f575 is a valid upstream commit that exists in mainline Linux but may not yet be present in the qcom-6.18.y branch at the time of the CI run. Checkpatch warns about "unknown commit id" when it cannot find the referenced commit in the local git history, but this does not indicate a problem with the patch itself.

The Fixes: tag correctly references the upstream commit that introduced the issue being fixed. This is proper kernel commit message style.

Fix: No action required. This is a known checkpatch limitation when referencing commits that exist upstream but are not yet in the target branch. The warning can be safely ignored.

Reproduce locally:

./scripts/checkpatch.pl --strict --summary-file --ignore FILE_PATH_CHANGES --git d1996e72bb5d27f7f7a4920f5cc7b0ca0dba463c..6073a130ac183f81ac58d2411029aa9b00425049

Verdict

Ready to merge. The only failure is a false-positive checkpatch warning about an unknown commit SHA. The referenced commit bb21ee31f575 is a valid upstream commit; checkpatch simply cannot find it in the current branch's git history. All other checkers passed, the commit has a proper FROMGIT: prefix, includes a valid Link: tag, and the patch content is clean.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #984

Job 207970 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Revert the PR or modify adc_tm5_get_temp() to validate that iio_read_channel_processed_scale() returns exactly 0 on success (per the upstream fix bb21ee3), and return -EINVAL only for actual error conditions; the current implementation incorrectly treats success (0) as valid without ensuring the IIO channel read completed successfully.
4. Detail analysis attachment: failed_case_job207970_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on qcs9100-ride platform — device tree node lacks iommus property, preventing SMMU protection for video DMA transactions.
3. Possible fix: Add iommus = <&apps_smmu 0x... 0x0>; property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/sa8775p.dtsi (or qcs9100-ride overlay), using the appropriate stream ID from the platform SMMU configuration, then verify the device appears in /sys/kernel/iommu_groups/ after reboot.
4. Detail analysis attachment: failed_case_job207970_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no physical USB devices connected to the qcs9100-ride board's USB ports; kernel USB subsystem initialized correctly (3 USB root hubs enumerated: Bus 001/002/003), but test expects at least one non-hub USB device to be physically connected.
3. Possible fix: Connect a physical USB device (e.g., USB flash drive, keyboard, mouse) to one of the board's USB ports before running the USBHost test; alternatively, update the test to skip or pass when only root hubs are present if external USB device connectivity is not a validation requirement for this platform.
4. Detail analysis attachment: failed_case_job207970_3_detailed.md

  Case 4: ** 0_qcom-next-ci-premerge-tests (LAVA Infrastructure Issue — Test Runner Completion Signal Missing)

1. Failed case: ** 0_qcom-next-ci-premerge-tests (LAVA Infrastructure Issue — Test Runner Completion Signal Missing)
2. Root cause: ** LAVA dispatcher marked the test run as "unfinished" despite all individual test cases completing successfully (pass/skip). The test runner sent <LAVA_TEST_RUNNER EXIT> signal, but LAVA expected an additional completion signal that was not sent, triggering the error "Marking unfinished test run as failed" at line 6517.
3. Possible fix: Re-trigger the LAVA job. If the issue recurs, investigate the LAVA test definition for the 0_qcom-next-ci-premerge-tests suite to ensure it sends the expected completion signal after result_parse.sh completes. This is a LAVA job definition or test harness issue, not a kernel regression introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984.
4. Detail analysis attachment: failed_case_job207970_4_detailed.md

Job 207971 | SoC shikra-iqs-evk

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

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

  Case 1: ** GIC (Test Infrastructure Bug)

1. Failed case: ** GIC (Test Infrastructure Bug)
2. Root cause: ** The GIC test script (run.sh line 75) contains a parsing bug that attempts to extract timer interrupt counts for CPUs 4-7, which do not exist on shikra-iqs-evk (4-CPU platform with only CPUs 0-3). The script's bash integer comparison fails when parsing non-numeric fields from /proc/interrupts, causing false failures for non-existent CPUs while all 4 real CPUs (0-3) pass correctly.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online before attempting to parse timer counts, or configure the test to expect only 4 CPUs for shikra-iqs-evk platform.
4. Detail analysis attachment: failed_case_job207971_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test infrastructure false positive - the Probe_Failure_Check test flagged benign and pre-existing probe failures (coresight-etm4x -EINVAL on shikra, regulatory.db missing firmware, cpufreq-dt -EEXIST duplicate registration, and normal deferred probes for audio/WiFi) as test failures. None of these are related to the PR changes (thermal/IIO subsystem) and none affect system functionality.
3. Possible fix: Update the Probe_Failure_Check test to suppress known benign probe failures: (1) coresight-etm4x -EINVAL on shikra (known platform limitation), (2) regulatory.db -ENOENT (benign missing firmware), (3) cpufreq-dt -EEXIST (benign duplicate registration), and (4) deferred probes that eventually resolve. Alternatively, add a baseline comparison to only flag new probe failures introduced by the PR.
4. Detail analysis attachment: failed_case_job207971_2_detailed.md

  Case 3: ** USBHost (Case ID: 3)

1. Failed case: ** USBHost (Case ID: 3)
2. Root cause: ** USB host controller driver (dwc3-qcom / xhci-hcd) not loaded or not present in the kernel/rootfs. The USB device node exists in the device tree and is successfully added to IOMMU group 5, but no host controller driver probes, resulting in zero USB devices enumerated. This is a pre-existing test environment issue, not introduced by PR 984 (which only modifies thermal/ADC code).
3. Possible fix: Enable and load USB host controller drivers: ensure CONFIG_USB_DWC3_QCOM=m and CONFIG_USB_XHCI_HCD=m are set in kernel config, verify dwc3-qcom.ko and xhci-plat-hcd.ko modules are present in rootfs, and add them to /etc/modules-load.d/usb.conf for auto-load. Rebuild the kernel/image, flash to shikra-iqs-evk, and re-run the USBHost test to verify USB enumeration.
4. Detail analysis attachment: failed_case_job207971_3_detailed.md

  Case 4: BT_SCAN (Test Environment Issue — No Discoverable Devices)

1. Failed case: BT_SCAN (Test Environment Issue — No Discoverable Devices)
2. Root cause: BT_SCAN test failed because no Bluetooth devices were present in the test environment to be discovered during the scan window (3 attempts × 15 seconds each), despite the Bluetooth hardware, driver, and BlueZ stack functioning correctly (confirmed by BT_ON_OFF passing).
3. Possible fix: This is a known test environment limitation, not a kernel regression. The failure should be suppressed as a benign test infrastructure issue. To prevent future false positives, either: (1) ensure discoverable Bluetooth devices are present in the LAVA lab environment during test execution, or (2) modify the test to skip BT_SCAN when no target devices are configured, similar to how BT_FW_KMD_Service handles optional firmware.
4. Detail analysis attachment: failed_case_job207971_4_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver crashed with a synchronous external abort (hardware access fault) when attempting to read RNG hardware registers during the qcom_hwrng test. This indicates the RNG hardware block on the Shikra IQS EVK is not properly powered, clocked, or accessible. The crash is unrelated to the PR patch (which modifies thermal sensor code) and represents a pre-existing board/firmware configuration issue specific to this SoC.
3. Possible fix: Verify RNG hardware power/clock configuration in the Shikra IQS EVK device tree and firmware. Add proper power domain, clock, and reset dependencies for the RNG node. If the hardware is known to be non-functional on this board revision, disable the qcom_rng driver in the kernel config or mark the DT node as status = "disabled" for Shikra IQS EVK.
4. Detail analysis attachment: failed_case_job207971_5_detailed.md

  Case 6: Kernel Crash — Hardware Access Fault (synchronous external abort in qcom_rng driver)

1. Failed case: Kernel Crash — Hardware Access Fault (synchronous external abort in qcom_rng driver)
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (ESR 0x96000010) at PC qcom_rng_read+0xc4 when reading from the hardware RNG MMIO registers. This is a hardware-level bus fault indicating the RNG hardware block is either not powered, not clocked, or the MMIO mapping is invalid on the Shikra IQS EVK platform. The KVM_EL2_DTB test failure is a separate issue (missing /dev/kvm device node) and is not the root cause of the crash.
3. Possible fix: This is a pre-existing platform/firmware issue unrelated to PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which modifies thermal/IIO code). The qcom_rng driver probe likely succeeded but the hardware is not functional. Recommended actions: (1) Verify qcom_rng device tree node has correct MMIO base address and clocks/power-domains for Shikra; (2) Check if RNG hardware block requires explicit power/clock enablement that is missing; (3) Disable the qcom_hwrng test for Shikra until hardware support is confirmed; (4) The PR can proceed — this crash is not PR-introduced.
4. Detail analysis attachment: failed_case_job207971_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed during boot because HYP (Hypervisor) mode is not available on the Shikra IQS EVK platform, preventing creation of /dev/kvm device node despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The Shikra IQS EVK does not support ARM virtualization extensions (EL2/HYP mode) required for KVM. Either skip KVM tests on this platform or use a platform with virtualization support (e.g., boards with Cortex-A cores that support EL2).
4. Detail analysis attachment: failed_case_job207971_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: The qcom_hwrng test triggered a synchronous external abort (bus error) at offset +0xc4 in qcom_rng_read() when attempting to read from the RNG hardware registers. The fault occurred during a memory-mapped I/O read operation (instruction b940035c = ldr w28, [x26]), indicating the RNG hardware block was either not powered, not clocked, or the MMIO mapping was invalid for the shikra-iqs-evk platform. This is a pre-existing platform/driver issue unrelated to the PR's thermal/ADC changes.
3. Possible fix: Verify the qcom_rng device tree node for shikra (QCM2290) includes correct reg address, clocks, and power-domain properties. Check if the RNG hardware block requires explicit power/clock enablement before register access. Add runtime PM or clock/regulator handling to qcom_rng_read() if missing. As an immediate workaround, disable the qcom_hwrng test for shikra-iqs-evk until the driver/DT is fixed, or blacklist the qcom_rng module in the test image.
4. Detail analysis attachment: failed_case_job207971_8_detailed.md

  Case 9: Kernel Crash — synchronous external abort in qcom_rng hardware access

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng hardware access
2. Root cause: Hardware random number generator (qcom_rng) driver triggered a synchronous external abort at PC qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The fault indicates the RNG hardware block was either not powered/clocked correctly, not mapped correctly in the SMMU/MMU, or the hardware itself is in a bad state on this shikra-iqs-evk board. This is a platform/board-specific hardware access issue unrelated to the PR patch (thermal/IIO fix).
3. Possible fix: This is a pre-existing platform issue, not introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984. The PR changes only drivers/thermal/qcom/qcom-spmi-adc-tm5.c (thermal sensor driver), while the crash occurs in drivers/char/hw_random/qcom-rng.c (RNG driver). Recommended action: (1) Mark this test failure as a known board/infra issue for shikra-iqs-evk; (2) Investigate RNG hardware power/clock/SMMU configuration on this specific board; (3) Consider skipping the qcom_hwrng test on shikra-iqs-evk until the hardware issue is resolved; (4) Approve PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 as the crash is unrelated to the patch content.
4. Detail analysis attachment: failed_case_job207971_9_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault in qcom_rng_read+0xc4 at PC b940035c (load instruction) during qcom_hwrng test execution. The qcom_rng driver attempted to read from RNG hardware registers but encountered a bus-level external abort, indicating the hardware block was either not clocked/powered, not accessible at the mapped address, or in an invalid state. This is a pre-existing platform/firmware/hardware issue on shikra-iqs-evk, not introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which modifies only thermal/IIO code unrelated to RNG).
3. Possible fix: Verify RNG hardware block power/clock configuration in device tree and firmware for shikra-iqs-evk. Check if RNG hardware requires explicit power domain or clock enablement before register access. Add error handling in qcom_rng probe to validate hardware accessibility before exposing /dev/hwrng. As an immediate workaround, disable the qcom_hwrng test for shikra-iqs-evk until the hardware configuration issue is resolved.
4. Detail analysis attachment: failed_case_job207971_10_detailed.md

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

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: Hardware bus error (synchronous external abort 0x96000010) in qcom_rng_read+0xc4 when accessing RNG hardware registers during qcom_hwrng test execution; the qcom_rng driver attempted to read from an unmapped, powered-down, or clock-gated hardware address, triggering a platform-level bus fault that caused kernel panic and subsequent warm reboot, leading to LAVA test timeout.
3. Possible fix: Verify qcom_rng device node power/clock dependencies in shikra-iqs-evk device tree; ensure RNG hardware block is properly powered and clocked before driver access; add runtime PM or clock enable checks in qcom_rng probe/read paths; if hardware is not present or functional on shikra-iqs-evk, disable qcom_rng in defconfig or mark device node status="disabled" in DT.
4. Detail analysis attachment: failed_case_job207971_11_detailed.md

Job 207972 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Deferred probe and firmware load errors

1. Failed case: Probe_Failure_Check — Deferred probe and firmware load errors
2. Root cause: Four PMIC temp-alarm devices (pmic@0, 2 (@2), bene (@4), 6 (@6)) remain in deferred probe state, likely awaiting IIO channel dependencies; additionally, three benign firmware load failures (regulatory.db, Bluetooth firmware files) are reported but do not indicate functional issues.
3. Possible fix: The deferred probe issue is NOT introduced by PR#984 (which only removes a redundant IIO_VAL_INT check in qcom-spmi-adc-tm5 driver). This is a pre-existing platform/DT configuration issue on lemans-evk where temp-alarm devices cannot resolve their IIO channel dependencies. The firmware load failures are known benign (regulatory.db and Bluetooth firmware fallback paths work correctly). Recommended action: Suppress this test failure as it reflects pre-existing infra/DT issues unrelated to the PR changes; alternatively, investigate lemans-evk device tree to ensure temp-alarm nodes have correct IIO channel phandles and that the ADC-TM5 device is properly configured.
4. Detail analysis attachment: failed_case_job207972_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device aa00000.video-codec exists in the device tree but its driver (qcom_iris/msm) did not probe it, resulting in no IOMMU group attachment; this is a pre-existing platform/driver issue unrelated to the PR patch which only modifies thermal driver code.
3. Possible fix: Investigate why the video codec driver (qcom_iris/msm modules are loaded) did not probe the aa00000.video-codec device node on lemans-evk; check device tree bindings, driver compatible strings, and probe deferral logs; this is a pre-existing issue not introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984.
4. Detail analysis attachment: failed_case_job207972_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the test suite as failed because two individual tests failed: (1) Probe_Failure_Check detected four deferred probe failures for SPMI PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00), which is directly related to the PR's modification of the thermal ADC-TM5 driver that these temp-alarm devices depend on for IIO channel processing; (2) smmu test failed due to missing iommu_group attachment for video codec device aa00000.video-codec, which is unrelated to the PR changes.
3. Possible fix: The temp-alarm deferred probe failures are likely caused by the PR's removal of the IIO_VAL_INT check in adc_tm5_get_temp(). The upstream commit bb21ee3 changed iio_read_channel_processed_scale() to return 0 on success instead of IIO_VAL_INT, but the temp-alarm driver probe path may be calling this function during initialization and expecting the old behavior. Verify that all callers of iio_read_channel_processed_scale() in the thermal subsystem have been updated to handle the new return value semantics. The smmu/video codec failure is a pre-existing platform issue unrelated to this PR and should be triaged separately.
4. Detail analysis attachment: failed_case_job207972_3_detailed.md

Job 207973 | SoC qcs615-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort during USB enumeration

1. Failed case: Kernel Crash — Synchronous External Abort during USB enumeration
2. Root cause: Synchronous external abort (ESR=0x96000010) in __pi_memcpy_generic during swiotlb_bounce operation while enumerating USB device (hub_port_init → usb_get_device_descriptor path). The fault occurred at physical address 0x10e9262a0 during DMA mapping for USB control transfer. This is a pre-existing kernel/hardware issue unrelated to the PR patch (thermal driver change).
3. Possible fix: This is not a PR-introduced regression. The PR only modifies drivers/thermal/qcom/qcom-spmi-adc-tm5.c (IIO return value handling) and does not touch USB, DMA, SWIOTLB, or memory subsystems. Root cause is likely: (1) invalid/unmapped physical address in SWIOTLB bounce buffer allocation, (2) SMMU/IOMMU misconfiguration for USB controller DMA, or (3) hardware-level memory access fault. Recommended actions: (1) verify SWIOTLB configuration and size in kernel config, (2) check IOMMU/SMMU mappings for USB controller (0x0a800000), (3) enable CONFIG_IOMMU_DEBUGFS and CONFIG_ARM_SMMU_TESTBUS_DUMP to capture SMMU fault context, (4) check if issue reproduces without USB device connected, (5) verify DDR training completed successfully (logs show normal DDR init).
4. Detail analysis attachment: failed_case_job207973_1_detailed.md

  Case 2: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)

1. Failed case: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
2. Root cause: Kernel panic during USB device enumeration at 7.479s due to synchronous external abort in __pi_memcpy_generic called from swiotlb_bounce. The crash occurred while copying data to/from a SWIOTLB bounce buffer (physical address 0x10e9262a0) during DMA mapping for USB control transfer. This is unrelated to the PR patch (thermal/qcom-spmi-adc-tm5.c) and represents a pre-existing platform issue with USB/DMA/IOMMU configuration on qcs615-ride.
3. Possible fix: This is a pre-existing platform/infrastructure issue unrelated to PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984. The thermal driver patch does not touch USB, DMA, SWIOTLB, or IOMMU subsystems. Re-trigger the CI job to confirm reproducibility. If the crash recurs, investigate qcs615-ride USB host controller DMA configuration, SWIOTLB buffer allocation, and IOMMU mappings for the xHCI controller. Check if SWIOTLB bounce buffer physical address 0x10e9262a0 is properly mapped and accessible.
4. Detail analysis attachment: failed_case_job207973_2_detailed.md

  Case 3: Kernel Crash — Synchronous External Abort during SWIOTLB DMA Mapping

1. Failed case: Kernel Crash — Synchronous External Abort during SWIOTLB DMA Mapping
2. Root cause: Hardware bus error (synchronous external abort 0x96000010) during SWIOTLB bounce buffer memory copy for USB DMA mapping on qcs615-ride. The crash occurs in __pi_memcpy_generic called from swiotlb_bounce while the USB hub worker thread attempts to map a URB for DMA during USB device enumeration. This indicates either invalid SWIOTLB buffer addressing, inaccessible memory region, or a hardware-level bus fault unrelated to the PR's thermal driver changes.
3. Possible fix: This is a pre-existing qcs615-ride platform issue, not introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (thermal driver change). Investigate: (1) SWIOTLB buffer allocation and physical address validity on qcs615-ride, (2) USB controller DMA configuration and address constraints, (3) IOMMU/SMMU mapping for USB controller, (4) hardware bus health and memory controller configuration. Re-trigger the CI job to confirm reproducibility; if persistent, escalate to qcs615-ride platform maintainers for USB/DMA subsystem debug.
4. Detail analysis attachment: failed_case_job207973_3_detailed.md

  Case 4: Kernel Crash — Synchronous External Abort (Hardware Memory Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Memory Access Fault)
2. Root cause: Synchronous external abort during USB hub enumeration when copying data from physical address 0x10e9262a0 to SWIOTLB bounce buffer; the memory controller rejected the access because the source address is invalid/unmapped on qcs615-ride platform.
3. Possible fix: This is a pre-existing platform/kernel issue unrelated to PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (thermal driver change). Re-trigger CI to confirm reproducibility. If reproducible, investigate: (1) USB controller DMA mask configuration for qcs615, (2) device tree reserved-memory regions, (3) SWIOTLB buffer allocation logic, (4) USB device descriptor buffer allocation. Check if USB device connected to the board has firmware/hardware issues causing invalid DMA addresses.
4. Detail analysis attachment: failed_case_job207973_4_detailed.md

Job 207974 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Firmware packaging issue in the build - WiFi firmware not included in rootfs
3. Possible fix: Add linux-firmware-ath11k package (or equivalent Qualcomm WiFi firmware package) to the Yocto/build recipe for monaco-evk images. Specifically ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and board files are included in /lib/firmware/. This is a build infrastructure fix, not a kernel code fix.
4. Detail analysis attachment: failed_case_job207974_1_detailed.md

  Case 2: ** WiFi Driver Probe Failure — ath11k_pci firmware dependency missing

1. Failed case: ** WiFi Driver Probe Failure — ath11k_pci firmware dependency missing
2. Root cause: ** The ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. The MHI (Modem Host Interface) subsystem attempted to load this firmware during device power-up but received error -2 (ENOENT), causing the power-up sequence to time out after waiting for the firmware handshake. This is a build/image packaging issue specific to the Monaco EVK platform, not a kernel driver bug or PR-introduced regression.
3. Possible fix: Add the missing WCN6855 WiFi firmware files to the Monaco EVK rootfs image by ensuring the linux-firmware-ath11k package (or equivalent firmware blob collection) is included in the Yocto/build recipe for this platform. Specifically, ensure /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are present in the deployed image. Re-trigger the CI job after updating the image manifest.
4. Detail analysis attachment: failed_case_job207974_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing WCN6855 nfa765 board variant firmware files to the Yocto build. Update the linux-firmware-qcom-ath11k recipe or equivalent firmware package to include ath11k/WCN6855/hw2.1/nfa765/amss.bin and associated board files (e.g., board-2.bin). Verify the firmware package is installed in the rootfs and rebuild the image.
4. Detail analysis attachment: failed_case_job207974_3_detailed.md

  Case 4: ** Driver Probe Failure — ath11k_pci WiFi driver

1. Failed case: ** Driver Probe Failure — ath11k_pci WiFi driver
2. Root cause: ** The ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the filesystem (error -2, ENOENT). Without firmware, the MHI subsystem cannot power up the WCN6855 WiFi chip, causing the driver to time out during initialization. This is a pre-existing test infrastructure issue unrelated to the PR patch (which modifies only the thermal ADC driver).
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the test image's /lib/firmware/ directory. Verify the firmware package (e.g., linux-firmware-ath11k or equivalent) is installed in the Yocto/build recipe for monaco-evk. Re-trigger the CI job after updating the firmware package.
4. Detail analysis attachment: failed_case_job207974_4_detailed.md

Job 207975 | SoC hamoa-evk

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

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

  Case 1: http-download

1. Failed case: http-download
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Re-trigger the CI job to retry with potentially better network conditions; if the issue recurs, increase the http-download timeout from 2397s (40min) to 4800s (80min) and the download-retry block timeout proportionally in the LAVA job definition to accommodate large image downloads over slow network paths.
4. Detail analysis attachment: failed_case_job207975_1_detailed.md

  Case 2: Build Load Failure — HTTP download timeout

1. Failed case: Build Load Failure — HTTP download timeout
2. Root cause: Result: Build Load Failure. The LAVA dispatcher's HTTP download of the 1033MB build artifact (qcom-multimedia-image-iq-x7181-evk.rootfs.qcomflash.tar.gz) from AWS S3 timed out after 2397 seconds (39m57s) at 70% completion (723MB downloaded). Network throughput averaged ~0.3 MB/s, insufficient to complete the download within the configured 40-minute timeout. This is a LAVA worker network/bandwidth infrastructure issue, not a build artifact or PR-introduced problem.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2397s (~40min) to 7200s (2 hours) and the download-retry block timeout from 40min to 2.5 hours in the LAVA job definition to accommodate large artifacts over slow network paths. Additionally, investigate LAVA worker network connectivity to AWS S3 us-west-2 region for bandwidth bottlenecks or throttling.
4. Detail analysis attachment: failed_case_job207975_2_detailed.md

  Case 3: Build Load Failure — HTTP download timeout

1. Failed case: Build Load Failure — HTTP download timeout
2. Root cause: Result: Build Load Failure. The LAVA dispatcher's HTTP download action timed out after 2397 seconds (39m57s) while downloading a 1033MB build artifact from S3. The download reached 70% (723MB) before hitting the configured timeout. The error string is "http-download timed out after 2397 seconds".
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2397s (39m57s) to 3600s (60min) and the download-retry block timeout from 00:40:00 to 01:15:00 in the LAVA job definition to accommodate the large artifact size (1033MB) and observed slow download rate (~18MB/min).
4. Detail analysis attachment: failed_case_job207975_3_detailed.md

  Case 4: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The LAVA job failed during the HTTP download of the root filesystem artifact (qcom-multimedia-image-iq-x7181-evk.rootfs.qcomflash.tar.gz, 1033 MB) from AWS S3. Download progressed to 70% (723 MB) over 39m 57s before hitting the configured timeout of 2397 seconds. Average download speed of ~0.3 MB/s indicates severe network congestion or bandwidth limitation between the LAVA worker and AWS S3 us-west-2 region.
3. Possible fix: Re-trigger the CI job to retry with potentially better network conditions. If the issue recurs, increase the http-download timeout from 2397s (~40min) to 3600s (60min) and the download-retry block timeout from 2400s to 4000s in the LAVA job definition to accommodate the large artifact size and slow network path. Additionally, investigate LAVA worker network connectivity to AWS S3 us-west-2 and consider using a regional artifact cache or CDN to improve download reliability for 1GB+ artifacts.
4. Detail analysis attachment: failed_case_job207975_4_detailed.md

Job 207976 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure

1. Failed case: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure
2. Root cause: The cfg80211 subsystem attempted to load the regulatory.db firmware file during WiFi driver initialization but the file is missing from the target rootfs (error -2 = -ENOENT). This is a pre-existing infrastructure/rootfs packaging issue, not a kernel regression. The PR patch modifies only the thermal subsystem (qcom-spmi-adc-tm5 driver) and has no connection to WiFi, cfg80211, or firmware loading. WiFi functionality is unaffected because cfg80211 successfully falls back to compiled-in X.509 regulatory certificates, as evidenced by WiFi_OnOff and WiFi_Firmware_Driver tests passing.
3. Possible fix: Add the regulatory.db firmware file (from wireless-regdb package) to the target rootfs image build recipe. The file should be installed to /lib/firmware/regulatory.db. This is a rootfs/build-system fix, not a kernel fix. Alternatively, suppress this specific firmware load failure in the Probe_Failure_Check test logic since WiFi functional tests confirm the subsystem works correctly with the compiled-in fallback.
4. Detail analysis attachment: failed_case_job207976_1_detailed.md

  Case 2: ** USBHost (Test Infrastructure Failure — No Hardware Connected)

1. Failed case: ** USBHost (Test Infrastructure Failure — No Hardware Connected)
2. Root cause: ** The USBHost test expects at least one functional USB device to be connected to the board, but only the USB root hub (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub) is present. The USB host controller driver (xhci-hcd) initialized successfully and the USB subsystem is functional, but no external USB devices (keyboard, mouse, storage, etc.) are physically connected to the qcs8300-ride board's USB ports during this LAVA test run.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. To resolve: (1) Connect a functional USB device (e.g., USB flash drive, keyboard) to one of the qcs8300-ride board's USB host ports before running the test, OR (2) Update the LAVA job definition to skip the USBHost test if no USB devices are expected in the test environment, OR (3) Modify the test script to treat "no devices connected" as SKIP rather than FAIL when the USB controller itself is functional.
4. Detail analysis attachment: failed_case_job207976_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: CONFIG_KVM is enabled but the KVM subsystem does not initialize during boot on qcs8300-ride — no KVM driver probe messages appear in dmesg, and /dev/kvm is never created. This is a pre-existing platform configuration or hardware support issue unrelated to the PR (which modifies only thermal/IIO subsystem code).
3. Possible fix: Investigate why KVM does not initialize on qcs8300-ride: check if the platform supports virtualization extensions (EL2), verify device tree includes required KVM/hypervisor nodes, confirm bootloader does not disable EL2, and check if a hypervisor is already running at EL2 preventing KVM from initializing. If qcs8300-ride does not support KVM, mark these tests as "not applicable" for this platform in the CI configuration.
4. Detail analysis attachment: failed_case_job207976_3_detailed.md

  Case 4: KVM Driver/Module Initialization Failure — /dev/kvm not available

1. Failed case: KVM Driver/Module Initialization Failure — /dev/kvm not available
2. Root cause: KVM failed to initialize because the qcs8300-ride system is running as a Primary VM (PVM) under Gunyah hypervisor (gunyah-1cb9db980 perf). ARM64 KVM requires EL2 (hypervisor mode) access to create /dev/kvm, but EL2 is already occupied by Gunyah, preventing KVM from initializing. CONFIG_KVM is enabled but the KVM driver cannot probe successfully without EL2 access.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which only modifies thermal/IIO code). The qcs8300-ride target runs under Gunyah hypervisor by design, making KVM unavailable. Either: (1) disable KVM tests for qcs8300-ride in the CI test suite since this platform does not support KVM, or (2) if KVM support is required, reconfigure the platform to boot Linux directly at EL2 without Gunyah, or enable nested virtualization support in Gunyah (if available).
4. Detail analysis attachment: failed_case_job207976_4_detailed.md

  Case 5: KVM Infrastructure Unavailable — Driver Initialization Failure

1. Failed case: KVM Infrastructure Unavailable — Driver Initialization Failure
2. Root cause: KVM driver did not initialize because QCS8300 (Monaco) has heterogeneous CPU features (big.LITTLE configuration with mismatched ID_AA64ISAR0_EL1, ID_AA64ISAR1_EL1, and ID_AA64MMFR2_EL1 registers between boot CPUs 0-3 and CPUs 4-7). ARM64 KVM requires all CPUs to have identical virtualization capabilities; kernel detected "Unsupported CPU feature variation" at boot and silently skipped KVM initialization.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. KVM cannot be enabled on QCS8300 due to heterogeneous CPU architecture. Mark KVM tests as "not applicable" for QCS8300 platform in CI configuration, or disable CONFIG_KVM for QCS8300-specific kernel builds to avoid false test failures.
4. Detail analysis attachment: failed_case_job207976_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Pre-existing platform limitation — qcs8300-ride does not support KVM virtualization; CONFIG_KVM is enabled but /dev/kvm device node is never created because the KVM driver does not initialize (no KVM-related kernel messages in boot log), indicating the platform lacks ARM virtualization extensions (VHE/nVHE) or KVM is not configured for this SoC.
3. Possible fix: This is not a PR-introduced regression. The PR modifies only drivers/thermal/qcom/qcom-spmi-adc-tm5.c (thermal subsystem) and is unrelated to KVM. Mark KVM tests as expected-fail for qcs8300-ride in the CI configuration, or skip KVM tests on platforms without virtualization support. To enable KVM on this platform (if hardware supports it), investigate why the KVM ARM driver (arch/arm64/kvm/) does not probe — check device tree for missing virtualization nodes, verify bootloader enables EL2, and confirm ARM CPU supports virtualization extensions.
4. Detail analysis attachment: failed_case_job207976_6_detailed.md

Job 207977 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The Probe_Failure_Check test detected a cfg80211 regulatory database firmware load failure (Direct firmware load for regulatory.db failed with error -2) during early boot. This is a pre-existing infrastructure/image issue where the wireless regulatory database file is not present in the rootfs firmware directory, unrelated to the PR's thermal driver changes.
3. Possible fix: Add the regulatory.db firmware file to the rootfs image under /lib/firmware/ or suppress this known benign failure in the Probe_Failure_Check test filter, as the wireless subsystem continues to function without it (cfg80211 falls back to built-in regulatory rules).
4. Detail analysis attachment: failed_case_job207977_1_detailed.md

  Case 2: rngtest

1. Failed case: rngtest
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a known benign test infrastructure issue. Recommended actions: (1) Increase the rngtest /dev/hwrng read timeout from 10 seconds to 30 seconds to allow more time for driver initialization and entropy accumulation. (2) Relax the /dev/urandom fallback success threshold from 997/1000 (99.7%) to 990/1000 (99.0%) to account for statistical variance in PRNG output. (3) Alternatively, reorder the test sequence to run rngtest after the qcom_hwrng test, ensuring the hardware RNG is fully initialized. This failure does NOT indicate a kernel regression introduced by this PR.
4. Detail analysis attachment: failed_case_job207977_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a board/infrastructure configuration issue, not a kernel regression introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which only modifies thermal/IIO subsystem code). The test failure is pre-existing. To resolve: (1) verify the board hardware supports USB host mode on the tested port, (2) ensure the device tree configures at least one USB controller in host or OTG mode with dr_mode = "host" or "otg", (3) confirm the required USB host controller driver (dwc3-qcom with xHCI) is enabled in the kernel config, or (4) skip this test on boards that only support USB gadget mode.
4. Detail analysis attachment: failed_case_job207977_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed during boot because the qcs6490-rb3gen2 platform is not running in EL2 (hypervisor mode), as evidenced by the kernel message "kvm [1]: HYP mode not available" at boot time (line 2347 of LAVA log), preventing creation of the /dev/kvm device node required by the test.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which only modifies thermal driver code). The board's bootloader/firmware must be configured to boot the kernel in EL2 mode to enable KVM host functionality. If KVM testing is required on this platform, update the bootloader configuration to enable EL2 boot; otherwise, skip KVM tests on platforms that do not support hypervisor mode.
4. Detail analysis attachment: failed_case_job207977_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM driver initialization failure

1. Failed case: KVM_EL2_DTB — KVM driver initialization failure
2. Root cause: KVM driver cannot initialize because the qcs6490-rb3gen2 platform is not booting into EL2 (HYP mode); kernel message kvm [1]: HYP mode not available at boot indicates the CPU is running in EL1 (kernel mode) without hypervisor support enabled, preventing /dev/kvm device node creation and causing all KVM-dependent tests to fail.
3. Possible fix: Enable EL2/HYP mode in the bootloader (ABL/XBL) configuration for qcs6490-rb3gen2; verify that the firmware boots the kernel at EL2 by checking for successful KVM initialization message kvm [1]: IPA Size Limit: XX bits instead of HYP mode not available; if EL2 cannot be enabled on this platform, mark KVM tests as expected-fail for qcs6490-rb3gen2 in the LAVA test definition.
4. Detail analysis attachment: failed_case_job207977_5_detailed.md

  Case 6: KVM_Infra — Pre-existing Platform Limitation (Not PR-Introduced)

1. Failed case: KVM_Infra — Pre-existing Platform Limitation (Not PR-Introduced)
2. Root cause: KVM driver initialization failed because EL2 (Hypervisor mode) is not available on qcs6490-rb3gen2 platform; kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running in EL2 or the bootloader/firmware did not enable virtualization extensions, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (thermal driver fix). The qcs6490-rb3gen2 board requires firmware/bootloader configuration to enable EL2 mode for KVM support. Either: (1) update the LAVA test suite to skip KVM tests on platforms without EL2 support, or (2) configure the bootloader/firmware to boot the kernel in EL2 mode if the hardware supports it.
4. Detail analysis attachment: failed_case_job207977_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because EL2 (Hypervisor mode) is not available to the Linux kernel on qcs6490-rb3gen2 — either the platform does not support virtualization extensions, EL2 is already in use by firmware/Gunyah hypervisor, or it is disabled by secure firmware.
3. Possible fix: This is a platform limitation, not a kernel bug. If KVM support is required: (1) verify the SoC supports virtualization extensions, (2) check if Gunyah or another hypervisor is consuming EL2 and preventing KVM from using it, (3) update firmware/bootloader to expose EL2 to Linux if supported. If KVM is not needed on this platform, suppress these test cases in the CI configuration for qcs6490-rb3gen2.
4. Detail analysis attachment: failed_case_job207977_7_detailed.md

Job 207978 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected 5 pre-existing platform configuration issues on purwa-evk: qcom-spmi-lpg DT multi-LED reg property invalid (-EINVAL), two qcom-pcie controllers missing PHY init sequences (-ENODATA), qcom_qseecom_uefisecapp secure resource busy (-EBUSY), and regulatory.db firmware file absent (-ENOENT).
3. Possible fix: These are baseline platform issues unrelated to PR FROMGIT: thermal: qcom-spmi-adc-tm5: drop IIO_VAL_INT check in adc_tm5_get_temp #984 (which only modifies qcom-spmi-adc-tm5 thermal driver). Fix qcom-spmi-lpg DT node multi-LED reg property per driver binding requirements; add missing PCIe PHY init sequences for 1bd0000 and 1bf8000 controllers to the QMP PHY driver or DT; investigate qseecom secure world resource contention; optionally add regulatory.db to firmware partition (or suppress this benign warning in the test).
4. Detail analysis attachment: failed_case_job207978_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six critical masters (five USB PHY devices: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb, and one video codec: aa00000.video-codec) are missing IOMMU group attachments on purwa-evk platform. The kernel booted successfully, SMMU hardware is functional (35 devices properly attached), but the test expects these specific devices to have IOMMU protection which is not configured in the device tree or driver for this SoC.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which modifies thermal driver code). The missing IOMMU attachments indicate either: (1) these devices are not present/enabled on purwa-evk hardware, (2) device tree is missing iommus properties for these nodes, or (3) drivers for these devices are not probing. Verify device tree for purwa-evk includes iommus properties for USB PHY nodes (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec (aa00000), and confirm these devices are expected to be functional on this board. If devices are not present on this board variant, update the test expectations to exclude them for purwa-evk.
4. Detail analysis attachment: failed_case_job207978_2_detailed.md

  Case 3: ** KVM_Driver — Test Infrastructure Issue (Platform Limitation)

1. Failed case: ** KVM_Driver — Test Infrastructure Issue (Platform Limitation)
2. Root cause: ** The purwa-evk platform does not support ARM EL2 (Hypervisor mode), as evidenced by the kernel message kvm [1]: HYP mode not available at boot time. Without EL2 support, the KVM driver cannot create the /dev/kvm device node, causing the KVM_Driver test to fail. This is a hardware/firmware platform limitation, not a kernel software bug.
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for purwa-evk and other platforms that do not support EL2/HYP mode. Update the LAVA job definition or test runner configuration to skip virtualization tests on platforms without EL2 capability.
4. Detail analysis attachment: failed_case_job207978_3_detailed.md

  Case 4: ** KVM_EL2_DTB — KVM Driver Initialization Failure (Pre-existing Platform Configuration)

1. Failed case: ** KVM_EL2_DTB — KVM Driver Initialization Failure (Pre-existing Platform Configuration)
2. Root cause: ** KVM driver cannot initialize because Gunyah hypervisor owns EL2 on the Purwa IoT EVK platform. KVM requires EL2 (hypervisor mode) to operate, but Gunyah and KVM are mutually exclusive. The kernel correctly detects this condition and reports "HYP mode not available" at boot (line 3411: [5.719545][T1] kvm [1]: HYP mode not available), preventing /dev/kvm device node creation. This is expected behavior for Gunyah-enabled platforms, not a kernel regression.
3. Possible fix: This is not a bug requiring a fix. The KVM tests should be excluded from the test suite for Gunyah-enabled platforms (Purwa IoT EVK). Update the LAVA job definition to skip KVM tests when gunyah-hyp reserved memory regions are detected in the device tree, or add platform-specific test filtering to exclude KVM tests for boards running Gunyah hypervisor. The PR patch (thermal/IIO subsystem change) is unrelated and should not be blocked by this pre-existing platform configuration issue.
4. Detail analysis attachment: failed_case_job207978_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM on purwa-evk: (1) disable Gunyah hypervisor in the bootloader/firmware configuration, or (2) exclude KVM tests from the purwa-evk CI test suite, as this platform is intended for Gunyah-based protected VM workloads, not KVM virtualization. The PR patch (thermal driver fix) is unrelated and should not be blocked by this pre-existing configuration constraint.
4. Detail analysis attachment: failed_case_job207978_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform hardware limitation — Purwa IoT EVK does not support ARM virtualization extensions (EL2/HYP mode), causing KVM initialization to fail with "HYP mode not available" and preventing /dev/kvm device creation.
3. Possible fix: Exclude KVM-related tests from the Purwa IoT EVK test suite, as this platform does not have the required hardware virtualization support. Update the LAVA job definition to skip Virtualization/KVM test suites for purwa-evk device type.
4. Detail analysis attachment: failed_case_job207978_6_detailed.md