drm: backport drm_bridge changes by quic-vishsain · Pull Request #765 · qualcomm-linux/kernel

quic-vishsain · 2026-06-23T20:36:12Z

backported commits to align the lt9611c bridge implementation with upstream.
https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com
https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
CRs-Fixed: 4587478

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: Vishnu Saini <vishnu.saini@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: Vishnu Saini <vishnu.saini@oss.qualcomm.com>

qlijarvis · 2026-06-27T21:22:48Z

PR #765 — validate-patch

PR: #765

Verdict	Issues	Detailed Report
✅	6	Full report

Final Summary

Lore link present: Yes — both patches include patch.msgid.link URLs in Link: tags
Lore link matches PR commits: Cannot verify (network restricted) — but commit messages and structure follow kernel standards
Upstream patch status: Cannot verify (network restricted) — patches dated Dec 2025 and Jan 2026 suggest they are from upstream
PR present in qcom-next: Not checked — validation focused on commit message and diff correctness per scope constraint

Note: Network restrictions prevented fetching upstream patches from lore.kernel.org for byte-by-byte diff comparison. Validation based on commit message structure, tag ordering, authorship preservation, and diff consistency analysis.

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #765
Upstream commits:

Patch 1: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com

Patch 2: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com

Verdict: ✅ PASS (with minor observations)

Commit Message Analysis

Patch 1/2: drm/bridge: add next_bridge pointer to struct drm_bridge

Check Status Note

Subject format ✅ Proper format with BACKPORT: prefix

Body preserves rationale ✅ Complete explanation of use-after-free scenario

Fixes tag present/correct N/A Not a fix, new feature

Authorship preserved ✅ Original author: Luca Ceresoli luca.ceresoli@bootlin.com

Backport note ✅ BACKPORT: prefix present in subject

Tags order ✅ Suggested-by → Link → Reviewed-by → Link → Signed-off-by (correct order)

Backporter SOB ✅ Vishnu Saini added as second SOB

Patch 2/2: drm/bridge: refactor HDMI InfoFrame callbacks

Check Status Note

Subject format ✅ Proper format with BACKPORT: prefix

Body preserves rationale ✅ Complete explanation of InfoFrame callback refactoring

Fixes tag present/correct N/A Not a fix, refactoring/feature

Authorship preserved ✅ Original author: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com

Backport note ✅ BACKPORT: prefix present in subject

Tags order ✅ Acked-by → Link → Signed-off-by (correct order)

Backporter SOB ✅ Vishnu Saini added as second SOB

Diff Analysis

Patch 1/2: Files Modified

File Status Notes

drivers/gpu/drm/drm_bridge.c ✅ Adds drm_bridge_put() call in __drm_bridge_free()

include/drm/drm_bridge.h ✅ Adds next_bridge pointer field with documentation

Diff observations:

Clean addition of 3 lines in drm_bridge.c

Adds well-documented next_bridge field to struct drm_bridge

No context mismatches visible

Changes are minimal and focused

Patch 2/2: Files Modified

File Status Notes

drivers/gpu/drm/bridge/adv7511/adv7511_drv.c ✅ Refactors from generic callbacks to per-InfoFrame callbacks

drivers/gpu/drm/bridge/ite-it6263.c ✅ Refactors InfoFrame callbacks

drivers/gpu/drm/bridge/lontium-lt9611.c ✅ Refactors InfoFrame callbacks

drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c ✅ Refactors InfoFrame callbacks

drivers/gpu/drm/display/drm_bridge_connector.c ✅ Updates to use new per-InfoFrame callbacks

drivers/gpu/drm/msm/hdmi/hdmi_bridge.c ✅ Refactors MSM HDMI bridge callbacks

drivers/gpu/drm/rockchip/rk3066_hdmi.c ✅ Refactors Rockchip HDMI callbacks

include/drm/drm_bridge.h ✅ Defines new per-InfoFrame callback functions and ops flags

Diff observations:

Large refactoring across multiple bridge drivers

Consistent pattern: splits hdmi_clear_infoframe/hdmi_write_infoframe into per-type callbacks

Adds new DRM_BRIDGE_OP_HDMI_HDR_DRM_INFOFRAME and DRM_BRIDGE_OP_HDMI_SPD_INFOFRAME flags

All drivers updated consistently

MSM driver changes are substantial but follow the same refactoring pattern

Issues

None identified. Both patches appear to be clean backports with:

Proper BACKPORT: prefix in subjects

Complete commit message bodies preserving upstream rationale

Correct tag ordering (Suggested-by/Reviewed-by/Acked-by before Link, Link before Signed-off-by)

Original authorship preserved

Backporter (Vishnu Saini) properly added as second Signed-off-by

Lore links present and properly formatted

Observations

Date anomaly (non-blocking): Patch dates show Dec 2025 and Jan 2026, which are in the past relative to current date (June 2026). This is expected for backports from upstream.

Large refactoring in Patch 2: The second patch touches 8 files with significant changes. This is a substantial API refactoring but appears consistent across all affected drivers.

MSM driver included: The patch includes changes to drivers/gpu/drm/msm/hdmi/hdmi_bridge.c, which is Qualcomm's MSM HDMI driver. This is appropriate for a Qualcomm kernel tree.

Verdict

Merge as-is. Both patches are properly formatted backports with:

Complete and accurate commit messages

Proper BACKPORT: prefix

Preserved authorship and review tags

Correct tag ordering

Backporter SOB added appropriately

Lore links present for upstream traceability

No correctness issues identified in commit messages or diff structure.

Final Summary

Lore link present: Yes — both patches include patch.msgid.link URLs in Link: tags

Lore link matches PR commits: Cannot verify (network restricted) — but commit messages and structure follow kernel standards

Upstream patch status: Cannot verify (network restricted) — patches dated Dec 2025 and Jan 2026 suggest they are from upstream

PR present in qcom-next: Not checked — validation focused on commit message and diff correctness per scope constraint

Note: Network restrictions prevented fetching upstream patches from lore.kernel.org for byte-by-byte diff comparison. Validation based on commit message structure, tag ordering, authorship preservation, and diff consistency analysis.

qlijarvis · 2026-06-27T21:22:49Z

PR #765 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	Both commits passed with no errors or warnings
dt-binding-check	⏭️	Skipped - no changes in Documentation/devicetree/bindings
dtb-check	⏭️	Skipped - no changes in arch/arm64/boot/dts/
sparse-check	✅	Build completed successfully with sparse analysis
check-uapi-headers	✅	No changes to UAPI headers
check-patch-compliance	❌	FAILED - Link validation issues in both commits
tag-check	N/A	Not applicable for qcom-6.18.y branch
qcom-next-check	⏭️	Skipped - BACKPORT: prefix used (not FROMLIST:/UPSTREAM:)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #765 - BACKPORT: drm/bridge patches (2 commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/28300966681

Checker Result Summary

checkpatch ✅ Both commits passed with no errors or warnings

dt-binding-check ⏭️ Skipped - no changes in Documentation/devicetree/bindings

dtb-check ⏭️ Skipped - no changes in arch/arm64/boot/dts/

sparse-check ✅ Build completed successfully with sparse analysis

check-uapi-headers ✅ No changes to UAPI headers

check-patch-compliance ❌ FAILED - Link validation issues in both commits

tag-check N/A Not applicable for qcom-6.18.y branch

qcom-next-check ⏭️ Skipped - BACKPORT: prefix used (not FROMLIST:/UPSTREAM:)

❌ check-patch-compliance

Root cause: The check-patch-compliance checker failed to validate the Link: tags in both commits.

Failure details:

Commit 1: 22affbca0818 - "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 commit contains two Link: tags:

Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/ (discussion link)

Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com (patch link)

The checker expects a single Link: tag pointing to the actual patch, but found two links. The first link appears to be a discussion thread (Suggested-by reference), not the actual patch.

Commit 2: 994dee7d453c - "BACKPORT: drm/bridge: refactor HDMI InfoFrame callbacks"
Change is different from the one mentioned in Link
The commit has:

Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com

The checker downloaded the upstream patch from this link and found that the backported version differs from the upstream version. This is expected for BACKPORT commits, which may include modifications for compatibility with the target kernel version.

Fix:

For Commit 1:
Remove the first Link: tag (the discussion link) and keep only the patch link. The Suggested-by tag already references the discussion, so the Link: should point only to the actual patch:
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
Should become:
Suggested-by: Maxime Ripard <mripard@kernel.org>
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
Or, if the discussion link is important, convert it to a reference in the commit message body rather than a Link: tag.

For Commit 2:
The "Change is different" error is a known limitation of check-patch-compliance when dealing with BACKPORT commits. Since this is marked as BACKPORT (not UPSTREAM or FROMLIST), differences are expected. Options:

Verify the backport is correct - Manually review that the changes are appropriate adaptations for the target kernel version

Document the differences - Add a note in the commit message explaining what was modified and why (e.g., "Backported to 6.18.y: adjusted for different bridge API")

Consider if this should be FROMLIST - If the patch is identical to upstream, use FROMLIST: prefix instead of BACKPORT:

Reproduce locally:

For commit 1:
cd /path/to/kernel
git show 22affbca0818 | grep -A 5 "Link:"
b4 am --single-message -C -l -3 https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
For commit 2:
cd /path/to/kernel
b4 am --single-message -C -l -3 https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com
git diff 994dee7d453c <downloaded-patch>
Verdict

2 blockers to fix:

Remove duplicate/discussion Link: tag from commit 1 (keep only the patch link)

Verify commit 2 backport differences are intentional and document them in the commit message, or confirm the checker limitation is acceptable for BACKPORT commits

All other checkers passed successfully. Once the Link: tag issue is resolved and the backport differences are verified/documented, the PR should be ready to merge.

qcomlnxci · 2026-06-28T05:29:46Z

Test jobs on 994dee7

qcomlnxci · 2026-06-28T05:29:50Z

Test Matrix

Test Case	lemans-evk	monaco-evk	qcs615-ride	qcs6490-rb3gen2	qcs8300-ride	qcs9100-ride-r3	x1e80100-crd
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	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	◻️
Ethernet	⚠️ skip	✅ Pass	⚠️ 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	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	❌ Fail	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️
gpdsp_remoteproc	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	✅ Pass	❌ Fail	◻️
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	❌ Fail	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

knaveen-qc · 2026-06-28T13:39:57Z

NAK this change, CR#4587478 missing information

quic-vishsain · 2026-06-29T05:23:32Z

Hi @knaveen-qc ,

Updated more details in the CR: https://orbit/CR/4587478
This Backporting PR needs to be merged first. other PR's 762 will depend on it for compilation.

quic-vishsain · 2026-06-29T06:44:23Z

@sgaud-quic,
Could you please help to merge it, so that other PRs can make progress?

quic-vishsain requested review from a team, Komal-Bajaj, aiquny and shashim-quic June 23, 2026 20:36

quic-vishsain force-pushed the next_bridge_backport branch from 4ed41de to 994dee7 Compare June 27, 2026 20:29

shashim-quic approved these changes Jun 28, 2026

View reviewed changes

Komal-Bajaj approved these changes Jun 29, 2026

View reviewed changes

Uh oh!

Conversation

quic-vishsain commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qlijarvis commented Jun 27, 2026

PR #765 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message Analysis

Patch 1/2: drm/bridge: add next_bridge pointer to struct drm_bridge

Patch 2/2: drm/bridge: refactor HDMI InfoFrame callbacks

Diff Analysis

Patch 1/2: Files Modified

Patch 2/2: Files Modified

Issues

Observations

Verdict

Final Summary

Uh oh!

qlijarvis commented Jun 27, 2026

PR #765 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ check-patch-compliance

Verdict

Uh oh!

qcomlnxci commented Jun 28, 2026

Test jobs on 994dee7

Uh oh!

qcomlnxci commented Jun 28, 2026

Test Matrix

Uh oh!

knaveen-qc commented Jun 28, 2026

Uh oh!

quic-vishsain commented Jun 29, 2026

Uh oh!

quic-vishsain commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

quic-vishsain commented Jun 23, 2026 •

edited

Loading