Lt9611uxd DSI HDMI Bridge for Shikra IQS by mohitdsor · Pull Request #841 · qualcomm-linux/kernel

mohitdsor · 2026-07-18T21:38:50Z

Lt9611uxd DSI HDMI Bridge for Shikra IQS
CRs-Fixed: 4576295

qswat-orbit-external · 2026-07-20T10:33:51Z

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

qlijarvis · 2026-07-20T14:46:41Z

PR #841 — validate-patch

PR: #841

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

Lore link present: No — no lore.kernel.org link found in patch; no commit message present
Lore link matches PR commits: N/A — no lore link to compare against; patch is a raw diff without commit metadata
Upstream patch status: Unknown — cannot determine without lore link; patch combines multiple unrelated changes that likely have different upstream status
PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #841 (title unknown - no metadata available)
Upstream commit: N/A
Verdict: ❌ FAIL

Commit Message

Check Status Note

Subject matches upstream ❌ No commit message present in patch

Body preserves rationale ❌ No commit message present in patch

Fixes tag present/correct ❌ No commit message present in patch

Authorship preserved ❌ No commit message present in patch

Backport note (if applicable) N/A No commit message present in patch

Diff

File Status Notes

354 files changed ❌ Raw diff without commit metadata; appears to combine multiple unrelated changes

Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml ⚠️ Adds new compatible strings (lt9611c, lt9611ex, lt9611uxd)

Documentation/gpu/drm-kms.rst ⚠️ Mass rename: drm_atomic_state → drm_atomic_commit

Documentation/gpu/todo.rst ⚠️ Updates TODO item about renaming drm_atomic_state

MAINTAINERS ⚠️ Adds new LONTIUM LT9611C entry

arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts ⚠️ Adds HDMI connector and LT9611 regulators

arch/arm64/configs/defconfig ⚠️ Config changes

drivers/gpu/drm/* (300+ files) ⚠️ Mass rename: drm_atomic_state → drm_atomic_commit throughout DRM subsystem

Issues

Critical Issues:

No lore.kernel.org link found — The PR patch contains no commit message and no Link: tag pointing to lore.kernel.org. According to kernel development practices, all patches must reference their upstream source.

No commit message metadata — The patch is a raw diff without From:, Date:, Subject:, or commit body. This violates kernel commit message requirements.

Multiple unrelated changes combined — The patch appears to combine at least three distinct changes:

A massive DRM subsystem-wide refactoring (drm_atomic_state → drm_atomic_commit) touching 300+ files

LT9611 bridge driver binding updates (new compatible strings)

Qualcomm Shikra board DTS additions (HDMI connector, regulators)

MAINTAINERS entry addition

Missing integration evidence — According to integration_presence_report.md, the commit has only "partial" presence in qcom-next/topics. Specifically, 161 added lines are missing from qcom-next, including:

Documentation/gpu/todo.rst changes about renaming drm_atomic_commit

MAINTAINERS entry for LONTIUM LT9611C

Structural Issues:

No commit prefix — Without a commit message, there's no UPSTREAM:, FROMLIST:, BACKPORT:, or QCLINUX: prefix to indicate the patch's origin and status.

No Signed-off-by chain — Required for all kernel contributions per DCO (Developer Certificate of Origin).

Verdict

Do not merge. This PR fails validation on multiple critical criteria:

Missing lore link — Cannot validate against upstream source

Missing commit message — Violates kernel commit requirements

Combining unrelated changes — Should be split into separate, logically independent commits

Incomplete integration — Missing lines indicate the change is not fully present in qcom-next

Required actions before merge:

Split this into separate commits:

One commit for the DRM atomic_state → atomic_commit refactoring (if this is intended to be included)

One commit for LT9611 binding updates

One commit for Shikra DTS additions

One commit for MAINTAINERS update

For each commit, add proper commit message with:

Descriptive subject line with appropriate prefix (UPSTREAM:, FROMLIST:, BACKPORT:, or QCLINUX:)

Commit body explaining the change rationale

Link: tag pointing to lore.kernel.org (for upstream/fromlist patches)

Signed-off-by: chain

Verify each commit's presence in qcom-next or explain why it's not there yet

If the DRM refactoring is unintentional, remove it entirely — this appears to be a massive upstream change that should not be in a vendor tree without clear justification

Final Summary

Lore link present: No — no lore.kernel.org link found in patch; no commit message present

Lore link matches PR commits: N/A — no lore link to compare against; patch is a raw diff without commit metadata

Upstream patch status: Unknown — cannot determine without lore link; patch combines multiple unrelated changes that likely have different upstream status

PR present in qcom-next/topics: Partial — 161/3354 added lines missing from qcom-next, including Documentation/gpu/todo.rst changes and MAINTAINERS entry; indicates incomplete or incorrect integration

Deterministic Integration Presence

Integration Presence Report

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

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

Commit Subject qcom-next topics Final

1/1 `` partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

Final Status

overall_status: 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

qlijarvis · 2026-07-20T14:46:42Z

PR #841 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 commits: 67 errors + 58 warnings (`c5e2179`), email mismatch (2 commits)
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	4 commits: b4 fetch failed (1), content mismatch (3), author mismatch (2)
tag-check	✅	All commits have valid prefixes (BACKPORT:/FROMLIST:)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #841 - Add Lontium LT9611C MIPI DSI to HDMI bridge driver support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/29747685578
Target Branch: qcom-6.18.y (subject prefix check mandatory)

Checker Result Summary

checkpatch ❌ 2 commits: 67 errors + 58 warnings (c5e2179), email mismatch (2 commits)

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed

check-patch-compliance ❌ 4 commits: b4 fetch failed (1), content mismatch (3), author mismatch (2)

tag-check ✅ All commits have valid prefixes (BACKPORT:/FROMLIST:)

❌ checkpatch

Root cause: Commit c5e2179 has 67 indentation errors (spaces instead of tabs) and 58 warnings; 2 commits have From:/Signed-off-by email mismatch.

Failure details:

Commit c5e2179 ("FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support"):
ERROR: code indent should use tabs where possible
#40: FILE: arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts:32:
+                compatible = "hdmi-connector";

WARNING: please, no spaces at the start of a line
#40: FILE: arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts:32:
+                compatible = "hdmi-connector";

[... 67 errors, 58 warnings total ...]

WARNING: From:/Signed-off-by: email address mismatch: 
  'From: Mohit Dsor <mdsor@oss.qualcomm.com>' != 
  'Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>'

c5e21795e4660fcd60c43259a8803dd0424e286b total: 67 errors, 58 warnings, 0 checks, 146 lines checked
Commit 81ea68c ("FROMLIST: arm64: defconfig: Enable LT9611C bridge driver"):
WARNING: From:/Signed-off-by: email address mismatch: 
  'From: Mohit Dsor <mdsor@oss.qualcomm.com>' != 
  'Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>'

81ea68c2c0206e13b0088a64dff31b0ded9975f8 total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Fix:
Indentation errors (c5e2179): The DTS file uses spaces instead of tabs. Run:
git rebase -i 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e  # mark c5e21795e466 as 'edit'
# Convert spaces to tabs in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
sed -i 's/^        /\t/g' arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
git add arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
git commit --amend --no-edit
git rebase --continue
Email mismatch (both commits): The From: line uses mdsor@oss.qualcomm.com but Signed-off-by: uses mohit.dsor@oss.qualcomm.com. Fix by amending the Signed-off-by: to match the From: email:
git rebase -i 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e
# For each commit (c5e21795e466 and 81ea68c2c020), mark as 'edit'
# Edit commit message to change:
#   Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
# to:
#   Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
git commit --amend
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --summary-file --ignore FILE_PATH_CHANGES \
  --git 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e..a1d0ff09cc775a3d74552593d364eba4f8167d3c
❌ check-patch-compliance

Root cause: 4 commits have upstream link/content/author issues: 1 b4 fetch failure, 3 content mismatches, 2 author mismatches.

Failure details:

Commit 1 ("BACKPORT: drm/bridge: add next_bridge pointer to struct drm_bridge"):
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
→ The Link: tag in the commit message points to an invalid or inaccessible lore URL. The checker cannot fetch the upstream patch with b4.

Commit 2 ("BACKPORT: drm/bridge: refactor HDMI InfoFrame callbacks"):
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
  Commit author : Mohit Dsor <mdsor@oss.qualcomm.com>
→ The patch content differs from the upstream lore patch, and the commit author is not the original author.

Commit 4 ("BACKPORT: drm: Rename struct drm_atomic_state to drm_atomic_commit"):
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Maxime Ripard <mripard@kernel.org>
  Commit author : Mohit Dsor <mdsor@oss.qualcomm.com>
→ Same issues: content mismatch and author mismatch.

Commit 14 ("FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support"):
Change is different from the one mentioned in Link
→ Content mismatch only (no author mismatch for this one).

Fix:
b4 fetch failure (Commit 1): Verify the Link: tag in the commit message points to a valid lore.kernel.org URL. If the link is correct but the patch was deleted/moved, update the link. If the link is a PR URL or invalid format, replace it with the correct lore message-ID URL.
Author mismatch (Commits 2, 4): These are BACKPORT: commits where the original author is different from the commit author. For backports, the commit author should be the original author, and the person who backported it should be credited with Signed-off-by: or Co-developed-by:. Fix:
git rebase -i 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e
# For each commit with author mismatch, mark as 'edit'
git commit --amend --author="Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>"  # for commit 2
git commit --amend --author="Maxime Ripard <mripard@kernel.org>"  # for commit 4
# Ensure Mohit Dsor is credited with Signed-off-by:
git rebase --continue
Content mismatch (Commits 2, 4, 14): Fetch the upstream patch with b4 and compare:
b4 am --single-message -C -l -3 <link-from-commit-message> -o /tmp/upstream.mbx
git format-patch -1 <commit-sha> --stdout > /tmp/pr-patch.patch
# Compare the diff sections (ignore context shifts)
diff <(awk '/^diff/,/^--$/' /tmp/upstream.mbx/*.mbx | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/pr-patch.patch | grep -E '^[+-][^+-]')
If the difference is only context lines (line numbers shifted) → not a real issue, but the checker cannot distinguish this. Document the adaptation in the commit message.

If there are missing hunks → add them.

If there are extra hunks → remove them or attribute them separately.

If the changes are legitimate adaptations for backporting → document them in the commit message body (e.g., "Adapted for 6.18.y: ...").
Reproduce locally:
cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base 94c6f41183c5b71f0cd81ca0c46bb17c3c1efa4e \
  --head <PR-head-sha>
Verdict

3 blockers must be fixed before merge:

checkpatch: Fix 67 indentation errors in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts (spaces → tabs).

checkpatch: Fix email mismatch in 2 commits (align Signed-off-by: with From: email).

check-patch-compliance: Fix author mismatch in 2 BACKPORT commits (set original author as commit author, credit backporter with Signed-off-by:).

Non-blocking issues (should fix but not blockers):

check-patch-compliance: Investigate content mismatches in 3 commits — if they are legitimate backport adaptations, document them in commit messages; if they are unintended diffs, align with upstream.

check-patch-compliance: Fix b4 fetch failure for commit 1 (verify Link: URL is valid).

qswat-orbit-external · 2026-07-23T09:42:48Z

Merge Check Failed: No Change Task Found

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

Entities:

kernel.qli.2.0

CR: 4576295

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

qcomlnxci · 2026-07-23T12:58:55Z

Test Matrix

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

qcomlnxci · 2026-07-23T12:58:55Z

Test jobs on 81ea68c

Many bridge drivers store a next_bridge pointer in their private data and use it for attach and sometimes other purposes. This is going to be risky when bridge hot-unplug is used. Considering this example scenario: 1. pipeline: encoder --> bridge A --> bridge B --> bridge C 2. encoder takes a reference to bridge B 3. bridge B takes a next_bridge reference to bridge C 4. encoder calls (bridge B)->b_foo(), which in turns references next_bridge, e.g.: b_foo() { bar(b->next_bridge); } If bridges B and C are removed, bridge C can be freed but B is still allocated because the encoder holds a reference to B. So when step 4 happens, 'b->next-bridge' would be a use-after-free. Calling drm_bridge_put() in the B bridge .remove function does not solve the problem as it leaves a (potentially long) risk window between B removal and the final deallocation of B. A safe moment to put the B reference is in __drm_bridge_free(), when the last reference has been put. This can be done by drivers in the .destroy func. However to avoid the need for so many drivers to implement a .destroy func, just offer a next_bridge pointer to all bridges that is automatically put it in __drm_bridge_free(), exactly when the .destroy func is called. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

Having only a single set of callbacks, hdmi_clear_infoframe and hdmi_write_infoframe, bridge drivers don't have an easy way to signal to the DRM framework, which InfoFrames are actually supported by the hardware and by the driver and which are not. Also, it makes it extremely easy for HDMI bridge drivers to skip implementing the seemingly required InfoFrames (e.g. HDMI VSI). Last, but not least, those callbacks take a single 'type' parameter, which makes it impossible to implement support for multiple VSIs (which will be required once we start working on HDMI Forum VSI). Split the callbacks into a per-InfoFrame-kind pairs, letting the bridge drivers actually signal supported features. The implementation follows the overall drm_bridge design, where the bridge has a single drm_bridge_funcs implementation and signals, which functions are to be called using the drm_bridge->ops flags. The AVI and HDMI VSI are assumed to be required for a normal HDMI operation (with the drivers getting a drm_warn_once() stub implementation if one is missing). The Audio InfoFrame is handled by the existing DRM_BRIDGE_OP_HDMI_AUDIO, while the SPD and HDR DRM InfoFrames got new drm_bridge_ops values. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

…to OP_HDMI There are DRM_BRIDGE_OP_HDMI_AUDIO bridges (e.g. Lontium LT9611UXC) which don't implement DRM_BRIDGE_OP_HDMI and don't implement hdmi_clear_audio_infoframe / hdmi_write_audio_infoframe callbacks. Move corresponding checks under the DRM_BRIDGE_OP_HDMI condition, making sure that we require those callbacks only from the bridges which are actually going to use them. Fixes: b626b1a ("drm/bridge: refactor HDMI InfoFrame callbacks") Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260126-drm-fix-lt9611uxc-v1-1-04a635a8f5cf@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

The KMS framework uses two slightly different definitions for the state concept. For a given object (plane, CRTC, encoder, etc., so drm_$OBJECT_state), the state is the entire state of that object. However, at the device level, drm_atomic_state refers to a state update for a limited number of objects. Thus, drm_atomic_state isn't the entire device state, but only the full state of some objects in that device. This has been an endless source of confusion and thus bugs. We can rename the drm_atomic_state structure to drm_atomic_commit to make it less confusing. This patch was created using: rg -l drm_atomic_state | \ xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g' mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

All the objects that need to implement some callbacks in KMS have a pointer in there structure to the main drm_device. However, it's not the case for drm_private_objs, which makes it harder than it needs to be to implement some of its callbacks. Let's add that pointer. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20251014-drm-private-obj-reset-v2-1-6dd60e985e9d@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

Since we're going to move the drm_private_obj state allocation to a callback, we need to be able to deal with its possible failure. Make drm_private_obj_init return an error code on failure. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-1-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

…vate_obj The drm_private_obj initialization was inconsistent with the rest of the KMS objects. Indeed, it required to pass a preallocated state in drm_private_obj_init(), while all the others objects would have a reset callback that would be called later on to create the state. However, reset really is meant to reset the hardware and software state. That it creates an initial state is a side-effect that has been used in all objects but drm_private_obj. This is made more complex since some drm_private_obj, the DisplayPort ones in particular, need to be persistent across and suspend/resume cycle, and such a cycle would call drm_mode_config_reset(). Thus, we need to add a new callback to allocate a pristine state for a given private object. This discussion has also came up during the atomic state readout discussion, so it might be introduced into the other objects later on. Until all drivers are converted to that new allocation pattern, we will only call it if the passed state is NULL. This will be removed eventually. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

Now that we have an atomic_create_state callback for drm_private_objs, we can provide a helper for it. It's somewhat different from the other similar helpers though, because we definitely expect drm_private_obj to be subclassed. It wouldn't make sense for a driver to use it as-is. So we can't provide a straight implementation of the atomic_create_state callback, but rather we provide the parts that will deal with the drm_private_obj initialization, and we will leave the allocation and initialization of the subclass to drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-3-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

…ate_state The bridge implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-4-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

Commit 47b5ac7 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states: atomic_create_state, a dedicated hook that allocates and initializes a pristine state without any side effect. The bridge atomic_reset callback is already fallible and in practice only allocates and initializes state without touching hardware. However, the reset name does not make this contract clear: callers and implementers cannot tell from the name alone whether the hardware will be affected or when the hook is safe to call. Add an atomic_create_state callback to drm_bridge_funcs to make the contract explicit: allocate a pristine state, initialize it, no side effects. The core calls it when available, falling back to atomic_reset otherwise. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-6-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

…e_state() The drm_atomic_helper_bridge_reset() helper is deprecated in favour of the new atomic_create_state callback. Add drm_atomic_helper_bridge_create_state() as the counterpart helper for this new callback, and make drm_atomic_helper_bridge_reset() call this new helper. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-7-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>

of_drm_find_bridge() does not increment the refcount for the returned bridge, but that is required now. However converting it and all its users is not realistically doable at once given the large amount of (direct and indirect) callers and the complexity of some. Solve this issue by creating a new of_drm_find_and_get_bridge() function that is identical to of_drm_find_bridge() except also it takes a reference. Then of_drm_find_bridge() will be deprecated to be eventually removed. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

@panel

drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL into the @panel or the @bridge arguments, thus making a very partial usage of this rather complex function. Besides, the bridge returned in @bridge is not refcounted, thus making this API unsafe when DRM bridge hotplug will be introduced. Solve both issues for the cases of calls to drm_of_find_panel_or_bridge() with a NULL @panel pointer by adding a new function that only looks for bridges (and is thus much simpler) and increments the refcount of the returned bridge. The new function is identical to drm_of_find_panel_or_bridge() except it: - handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of of_drm_find_bridge() internally to return a refcounted bridge - is simpler to use: just takes no @panel parameter, returns the pointer in the return value instead of a double pointer argument - has a simpler implementation: it is equal to drm_of_find_panel_or_bridge() after removing the code that becomes dead when @panel == NULL Also add this function to drm_bridge.c and not drm_of.c because it returns bridges only. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-2-f61c9e498b3f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

…o HDMI driver LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link: https://lore.kernel.org/all/20260808-lt9611c-v7-v10-1-ee90a136d82a@oss.qualcomm.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

…iver LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link: https://lore.kernel.org/all/20260808-lt9611c-v7-v10-2-ee90a136d82a@oss.qualcomm.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Co-developed-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

… support Enable the Shikra MDSS display subsystem on the Qualcomm Shikra IQS EVK board and add the Lontium LT9611UXD DSI-to-HDMI bridge node. The LT9611UXD is connected via I2C (bus 4, address 0x41), powered by a GPIO-controlled 3.3V regulator (PM8150 GPIO4) and an always-on 1.8V rail. Reset is on GPIO76 and interrupt on GPIO85. The bridge receives DSI output from MDSS and drives an HDMI-A connector, with the link wired as: DPU -> DSI0 -> LT9611UXD -> HDMI. Link: https://lore.kernel.org/all/20260728-shikra-work-v3-1-e08c322596ac@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

Enable the Lontium LT9611C DSI-to-HDMI bridge driver as a module. This driver supports the LT9611UXD chip used on the Shikra IQS EVK board to provide HDMI output via the MDSS DSI interface. Link: https://lore.kernel.org/all/20260728-shikra-work-v3-2-e08c322596ac@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

qlijarvis · 2026-08-09T07:36:44Z

PR #841 — validate-patch

PR: #841

Verdict	Issues	Detailed Report
❌	3	Full report

Final Summary

Lore link present: No — no lore.kernel.org Link tags found in pr.patch
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: Unknown — cannot determine without lore link or commit message metadata
PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #841 (qualcomm-linux/kernel)
Upstream commit: (none found)
Verdict: ❌ FAIL

Commit Message

Check Status Note

Subject matches upstream ❌ No commit message present in pr.patch

Body preserves rationale ❌ No commit message present in pr.patch

Fixes tag present/correct ❌ No commit message present in pr.patch

Authorship preserved ❌ No commit metadata present in pr.patch

Backport note (if applicable) N/A No commit message present

Diff

File Status Notes

354 files changed ❌ Raw diff without commit message or lore attribution

Documentation/gpu/drm-kms.rst ⚠️ drm_atomic_state → drm_atomic_commit rename (appears to be upstream TODO item)

Documentation/ABI/testing/sysfs-lontium-firmware ⚠️ New sysfs ABI for Lontium bridge (no lore link)

Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml ⚠️ New compatible strings (lt9611c, lt9611ex, lt9611uxd) without lore link

arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts ⚠️ New HDMI connector node without lore link

drivers/gpu/drm/bridge/lontium-lt9611*.c ⚠️ Driver changes without lore attribution

348+ other files ⚠️ Massive drm_atomic_state rename across entire DRM subsystem

Issues

Critical:

No lore.kernel.org link found — The PR contains no Link: tags pointing to lore.kernel.org in the commit message(s). This skill only validates patches against lore.kernel.org sources.

No commit message metadata — The pr.patch file is a raw diff without commit message, author, date, or any trailers (Signed-off-by, Link, etc.). Cannot verify commit message correctness, authorship, or upstream attribution.

Multiple unrelated changes in single commit — The PR mixes:

A massive DRM subsystem-wide refactoring (drm_atomic_state → drm_atomic_commit, 348+ files)

Lontium bridge driver additions (new sysfs ABI, new compatible strings, driver changes)

Qualcomm Shikra device tree additions (HDMI connector node)

These should be separate commits with individual lore links and proper commit messages.

No commit prefix — No UPSTREAM:, FROMLIST:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND: prefix found to indicate the source and status of these changes.

Observations:

The drm_atomic_state → drm_atomic_commit rename appears to implement the TODO item documented in Documentation/gpu/todo.rst (which is itself modified in this PR).

The Lontium bridge changes add support for new chip variants (lt9611c, lt9611ex, lt9611uxd) and a new sysfs firmware interface.

The Shikra device tree changes add HDMI display support via the lt9611 bridge.

Verdict

Do not merge. This PR fails validation for the following reasons:

No lore.kernel.org link — Cannot validate patch content against upstream source. Every commit must have a Link: tag pointing to the lore.kernel.org posting or upstream commit.

Missing commit message — The patch lacks all required metadata: subject line, commit body, authorship, trailers, and attribution.

Improper commit structure — Multiple unrelated changes are bundled together. Each logical change must be a separate commit with its own lore link and commit message.

Missing commit prefix — Cannot determine if these are upstream patches (UPSTREAM:), patches under review (FROMLIST:), backports (BACKPORT:), or vendor-specific changes (QCLINUX:).

Recommendation

The PR author must:

Split into separate commits — Create individual commits for:

DRM atomic state rename (if this is an upstream patch, add UPSTREAM: or FROMLIST: prefix + lore link)

Lontium bridge binding updates (add appropriate prefix + lore link)

Lontium bridge driver changes (add appropriate prefix + lore link)

Shikra device tree additions (add QCLINUX: prefix if vendor-only, or lore link if posted upstream)

Add proper commit messages — Each commit must have:

Subject line with appropriate prefix (UPSTREAM:, FROMLIST:, BACKPORT:, or QCLINUX:)

Commit body explaining the change

Signed-off-by: trailer

Link: tag pointing to lore.kernel.org (for upstream/FROMLIST commits)

Verify upstream status — For the DRM atomic state rename:

If this is an accepted upstream patch, use UPSTREAM: prefix and link to the merged commit

If this is a patch under review, use FROMLIST: prefix and link to the lore posting

If this is vendor-only work, use QCLINUX: prefix (no lore link required)

Re-submit — After restructuring, re-submit as a proper patch series with individual commits, each with correct metadata and lore attribution.

Final Summary

Lore link present: No — no lore.kernel.org Link tags found in pr.patch

Lore link matches PR commits: N/A — no lore link to compare against

Upstream patch status: Unknown — cannot determine without lore link or commit message metadata

PR present in qcom-next/topics: Partial — integration_presence_report.md shows 1/1 commit has partial 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 `` 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

qlijarvis · 2026-08-09T07:36:45Z

PR #841 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	3 commits with issues: 65 errors + 57 warnings in DTS file (spaces vs tabs), 15 warnings + 11 checks in drm_atomic rename, 1 warning in 2 other commits
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	5 commits with issues: 2 b4 fetch failures, 2 content mismatches with author mismatches, 1 content mismatch
tag-check	✅	All commits have valid prefixes (BACKPORT/FROMLIST)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #841 - Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI bridge support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/31299625467

Checker Result Summary

checkpatch ❌ 3 commits with issues: 65 errors + 57 warnings in DTS file (spaces vs tabs), 15 warnings + 11 checks in drm_atomic rename, 1 warning in 2 other commits

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed

check-patch-compliance ❌ 5 commits with issues: 2 b4 fetch failures, 2 content mismatches with author mismatches, 1 content mismatch

tag-check ✅ All commits have valid prefixes (BACKPORT/FROMLIST)

❌ checkpatch

Root cause: Three commits have coding style violations.

Failure details:

Commit 4a47441 ("FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support")

65 errors, 57 warnings - DTS file uses spaces instead of tabs for indentation
ERROR: code indent should use tabs where possible
#40: FILE: arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts:32:
+                compatible = "hdmi-connector";

WARNING: please, no spaces at the start of a line
#40: FILE: arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts:32:
+                compatible = "hdmi-connector";
This pattern repeats for all added lines in the DTS file (lines 32-151).

Commit e205300 ("BACKPORT: drm: Rename struct drm_atomic_state to drm_atomic_commit")

15 warnings, 11 checks - Large mechanical rename introduces:

Line length warnings (7 lines exceed 100 chars)

Alignment checks (11 instances where alignment should match open parenthesis)

Function parameter naming warnings (4 instances missing identifier names)

Bare unsigned warning (1 instance)

Obsolete file modification warnings (2 instances for cirrus-qemu.c)

Commit message line length warning (1 instance)

Commit e266078 ("BACKPORT: drm/display: bridge_connector: move audio_infoframe checks to OP_HDMI")

1 warning - Unknown commit ID in Fixes: tag
WARNING: Unknown commit id 'b626b1a1c9cc', maybe rebased or not pulled?
#15: 
Fixes: b626b1a1c9cc ("drm/bridge: refactor HDMI InfoFrame callbacks")
Commit 0254521 ("BACKPORT: drm/bridge: Add new atomic_create_state callback")

1 warning - Unknown commit ID in commit message
WARNING: Unknown commit id '47b5ac7daa46', maybe rebased or not pulled?
#6: 
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
Fix:

For commit 4a47441 (DTS indentation):
git rebase -i <base_sha>   # mark commit 4a47441f551a as 'edit'
# Convert spaces to tabs in the DTS file
sed -i 's/^        /\t/g; s/^                /\t\t/g; s/^                        /\t\t\t/g; s/^                                /\t\t\t\t/g' arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
git add arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
git commit --amend --no-edit
git rebase --continue
For commit e205300 (drm_atomic rename):

The warnings are mostly acceptable for a large mechanical rename (12,313 lines changed)

Line length warnings on function declarations are acceptable when the function name itself is long

Alignment checks can be fixed if desired, but are low priority for a backport

The obsolete file warning is informational only

Consider adding --fix-inplace to auto-fix alignment issues if needed

For commits e266078 and 0254521 (unknown commit IDs):

These are acceptable - the referenced commits exist upstream but may not be in the current tree

No action required unless the Fixes: tag needs to reference a different commit

Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 8635749eab9a..829f1ebba4f9
❌ check-patch-compliance

Root cause: Five commits have upstream link or content/author verification issues.

Failure details:

Commit 38a2bea ("BACKPORT: drm/bridge: add next_bridge pointer to struct drm_bridge")
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
→ b4 cannot fetch the patch from the provided lore link.

Commit 520ba01 ("BACKPORT: drm/bridge: refactor HDMI InfoFrame callbacks")
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
  Commit author : Mohit Dsor <mdsor@oss.qualcomm.com>
→ Both content and author differ from upstream.

Commit e205300 ("BACKPORT: drm: Rename struct drm_atomic_state to drm_atomic_commit")
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Maxime Ripard <mripard@kernel.org>
  Commit author : Mohit Dsor <mdsor@oss.qualcomm.com>
→ Both content and author differ from upstream.

Commit cd73147 ("BACKPORT: drm/bridge: add of_drm_find_and_get_bridge()")
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com
→ b4 cannot fetch the patch from the provided lore link.

Commit 4a47441 ("FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support")
Change is different from the one mentioned in Link
→ Content differs from upstream (likely due to the spaces-vs-tabs issue).

Fix:

For b4 fetch failures (commits 38a2bea, cd73147):
Verify the lore links are correct and accessible

The links appear to use message-ID format - ensure they resolve correctly
Run the suggested b4 command locally to verify:
b4 am --single-message -C -l -3 <link>
If the link is incorrect, update the commit message with the correct lore URL
For author mismatches (commits 520ba01, e205300):
These are BACKPORT commits, so author changes may be intentional if significant modifications were made
If the backport is faithful to upstream, restore the original author:
git rebase -i <base_sha>   # mark commit as 'edit'
git commit --amend --author="Original Author <email>"
git rebase --continue
If substantial changes were made, keep current author but add Co-developed-by: for original author
For content mismatch (commit 4a47441):

This is likely caused by the spaces-vs-tabs issue

After fixing the checkpatch errors, the content should match upstream

Reproduce locally:
# For each failing commit:
b4 am --single-message -C -l -3 <lore-link> -o /tmp/out
git format-patch -1 <sha> --stdout > /tmp/pr.patch
diff <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/pr.patch | grep -E '^[+-][^+-]')
Verdict

3 blockers must be fixed before merge:

Critical: Commit 4a47441 - Fix DTS indentation (65 errors, 57 warnings) - spaces must be converted to tabs

High: Verify and fix b4 fetch failures for 2 commits (38a2bea, cd73147) - ensure lore links are correct

Medium: Resolve author mismatches for 2 commits (520ba01, e205300) - restore original authors if backports are faithful

The large drm_atomic rename commit (e205300) has 15 warnings + 11 checks, but these are mostly acceptable for a mechanical rename of 12,313 lines. The alignment and line-length issues are low priority for a backport.

All other checkers passed cleanly.

qcomlnxci · 2026-08-10T13:16:44Z

Test jobs on 829f1eb

qcomlnxci · 2026-08-10T13:16:48Z

Test Matrix

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

mohitdsor changed the base branch from main to qcom-6.18.y July 18, 2026 21:39

mohitdsor requested review from a team, jingyiwang42, Shiraz Hashim (shashim-quic) and Trilok Soni (trsoni) July 18, 2026 21:39

mohitdsor force-pushed the lt9611uxd_dsi_hdmi branch from 68c10e8 to 686f80c Compare July 20, 2026 10:33

mohitdsor force-pushed the lt9611uxd_dsi_hdmi branch 3 times, most recently from 8958547 to 81ea68c Compare July 20, 2026 13:44

Shiraz Hashim (shashim-quic) approved these changes Jul 23, 2026

View reviewed changes

Shiraz Hashim (shashim-quic) previously approved these changes Jul 28, 2026

View reviewed changes

Mohit Dsor and others added 13 commits August 9, 2026 11:25

Sunyun Yang and others added 4 commits August 9, 2026 11:47

mohitdsor dismissed Shiraz Hashim (shashim-quic)’s stale review via 829f1eb August 9, 2026 06:45

mohitdsor force-pushed the lt9611uxd_dsi_hdmi branch from 81ea68c to 829f1eb Compare August 9, 2026 06:45

qcomlnxci requested review from a team and Tingwei Zhang (quic-tingweiz) August 9, 2026 06:46

Shiraz Hashim (shashim-quic) approved these changes Aug 10, 2026

View reviewed changes

Uh oh!

Conversation

mohitdsor commented Jul 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qswat-orbit-external Bot commented Jul 20, 2026

Uh oh!

qlijarvis commented Jul 20, 2026

PR #841 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Issues

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 20, 2026

PR #841 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ checkpatch

❌ check-patch-compliance

Verdict

Uh oh!

qswat-orbit-external Bot commented Jul 23, 2026

Uh oh!

qcomlnxci commented Jul 23, 2026

Test Matrix

Uh oh!

qcomlnxci commented Jul 23, 2026

Test jobs on 81ea68c

Uh oh!

qlijarvis commented Aug 9, 2026

PR #841 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Issues

Verdict

Recommendation

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Aug 9, 2026

PR #841 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ checkpatch

❌ check-patch-compliance

Verdict

Uh oh!

qcomlnxci commented Aug 10, 2026

Test jobs on 829f1eb

Uh oh!

qcomlnxci commented Aug 10, 2026

Test Matrix

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

mohitdsor commented Jul 18, 2026 •

edited

Loading