Skip to content

Lt9611uxd DSI HDMI Bridge for Shikra IQS#841

Open
mohitdsor wants to merge 15 commits into
qualcomm-linux:qcom-6.18.yfrom
mohitdsor:lt9611uxd_dsi_hdmi
Open

Lt9611uxd DSI HDMI Bridge for Shikra IQS#841
mohitdsor wants to merge 15 commits into
qualcomm-linux:qcom-6.18.yfrom
mohitdsor:lt9611uxd_dsi_hdmi

Conversation

@mohitdsor

@mohitdsor mohitdsor commented Jul 18, 2026

Copy link
Copy Markdown

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

@mohitdsor
mohitdsor changed the base branch from main to qcom-6.18.y July 18, 2026 21:39
Mohit Dsor and others added 13 commits July 20, 2026 16:03
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>
…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/lkml/20260716-lt9611c-v7-v7-1-7553a14735fc@oss.qualcomm.com/
Signed-off-by: Sunyun Yang <syyang@lontium.com>
Signed-off-by: Mohit Dsor <mdsor@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/lkml/20260716-lt9611c-v7-v7-2-7553a14735fc@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>
@mohitdsor
mohitdsor force-pushed the lt9611uxd_dsi_hdmi branch from 68c10e8 to 686f80c Compare July 20, 2026 10:33
@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

Mohit Dsor added 2 commits July 20, 2026 16:28
… 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/lkml/20260717-shikra-work-v2-1-86ae8552259e@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/lkml/20260717-shikra-work-v2-2-86ae8552259e@oss.qualcomm.com/
Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
@mohitdsor
mohitdsor force-pushed the lt9611uxd_dsi_hdmi branch 3 times, most recently from 8958547 to 81ea68c Compare July 20, 2026 13:44
@qlijarvis

Copy link
Copy Markdown

PR #841 — validate-patch

PR: #841

Verdict Issues Detailed Report
0 Full report

Final Summary

  1. Lore link present: No — no lore.kernel.org link found in patch; no commit message present
  2. Lore link matches PR commits: N/A — no lore link to compare against; patch is a raw diff without commit metadata
  3. Upstream patch status: Unknown — cannot determine without lore link; patch combines multiple unrelated changes that likely have different upstream status
  4. 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:

  1. 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.

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

  3. 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
  4. 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:

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

  2. 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:

  1. Missing lore link — Cannot validate against upstream source
  2. Missing commit message — Violates kernel commit requirements
  3. Combining unrelated changes — Should be split into separate, logically independent commits
  4. Incomplete integration — Missing lines indicate the change is not fully present in qcom-next

Required actions before merge:

  1. 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
  2. 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
  3. Verify each commit's presence in qcom-next or explain why it's not there yet

  4. 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

  1. Lore link present: No — no lore.kernel.org link found in patch; no commit message present
  2. Lore link matches PR commits: N/A — no lore link to compare against; patch is a raw diff without commit metadata
  3. Upstream patch status: Unknown — cannot determine without lore link; patch combines multiple unrelated changes that likely have different upstream status
  4. 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

Copy link
Copy Markdown

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:

  1. 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
  2. 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:

  1. 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.

  2. 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
  3. 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:

  1. checkpatch: Fix 67 indentation errors in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts (spaces → tabs).
  2. checkpatch: Fix email mismatch in 2 commits (align Signed-off-by: with From: email).
  3. 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).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants