kernel/linux.git/drivers/gpu/drm/drm_bridge.c, branch v7.1-rc5

Merge v7.0-rc7 into drm-next

2026-04-07T10:36:31+00:00

Thomas Zimmermann needs 2f42c1a61616 ("drm/ast: dp501: Fix initialization of SCU2C") for drm-misc-next. Conflicts: - drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c Just between e927b36ae18b ("drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()") and it's cherry-pick that confused git. - drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c Deleted in 6b0a6116286e ("drm/amd/pm: Unify version check in SMUv11") but some cherry-picks confused git. Same for v12/v14. Signed-off-by: Simona Vetter

drm/bridge: Fix refcount shown via debugfs for encoder_bridges_show()

2026-03-26T10:25:03+00:00

A typical bridge refcount value is 3 after a bridge chain is formed: - devm_drm_bridge_alloc() initializes the refcount value to be 1. - drm_bridge_add() gets an additional reference hence 2. - drm_bridge_attach() gets the third reference hence 3. This typical refcount value aligns with allbridges_show()'s behaviour. However, since encoder_bridges_show() uses drm_for_each_bridge_in_chain_scoped() to automatically get/put the bridge reference while iterating, a bogus reference is accidentally got when showing the wrong typical refcount value as 4 to users via debugfs. Fix this by caching the refcount value returned from kref_read() while iterating and explicitly decreasing the cached refcount value by 1 before showing it to users. Fixes: bd57048e4576 ("drm/bridge: use drm_for_each_bridge_in_chain_scoped()") Signed-off-by: Liu Ying Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Link: https://patch.msgid.link/20260318-drm-misc-next-2026-03-05-fix-encoder-bridges-refcount-v3-1-147fea581279@nxp.com Signed-off-by: Luca Ceresoli

drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace

2026-03-24T12:54:35+00:00

The hdmi_colorspace enum was defined to represent the colorspace value of the HDMI infoframes. It was later used by some HDMI drivers to express the output format they should be setting up. During the introduction of the HDMI helpers, it then was used to represent it in the drm_connector_hdmi_state structure. However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* defines, and now with the drm_output_color_format enum. Let's consolidate around drm_output_color_format in drm_connector_hdmi_state to facilitate the current effort to provide a global output format selection mechanism. Acked-by: Jani Nikula Reviewed-by: Nicolas Frattaroli Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard

drm/bridge: add drm_bridge_clear_and_put()

2026-03-20T10:02:12+00:00

Drivers having a struct drm_bridge pointer pointing to a bridge in many cases hold that reference until the owning device is removed. In those cases the reference to the bridge can be put in the .remove callback (possibly using devm actions) or in the .destroy func (possibly with the help of struct drm_bridge::next_bridge). At those moments the driver should not be operating anymore and won't dereference the bridge pointer after it is put. However there are cases when drivers need to stop holding a reference to a bridge even when their device is not being removed. This is the case for bridge hot-unplug, when a bridge is removed but the previous entity (bridge or encoder) is staying. In such case the "previous entity" needs to put it but cannot do it via devm or .destroy, because it is not being removed. The easy way to dispose of such pointer is: drm_bridge_put(my_priv->some_bridge); my_priv->some_bridge = NULL; However this is risky because there is a time window between the two lines where the reference is put, and thus the bridge could be deallocated, but the pointer is still assigned. If other functions of the same driver were invoked concurrently they might dereference my_priv->some_bridge during that window, resulting in use-after-free. A correct solution is to clear the pointer before putting the reference, but that needs a temporary variable: struct drm_bridge *temp = my_priv->some_bridge; my_priv->some_bridge = NULL; drm_bridge_put(temp); This solution is however annoying to write, so the incorrect version might still sneak in. Add a simple, easy to use function to put a bridge after setting its pointer to NULL in the correct way. Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260310-drm-bridge-atomic-vs-remove-clear_and_put-v2-1-51fe222f3cf0@bootlin.com Signed-off-by: Luca Ceresoli

drm/atomic: Remove state argument to drm_atomic_private_obj_init

2026-03-20T09:03:11+00:00

Now that all drm_private_objs users have been converted to use atomic_create_state instead of the old ad-hoc initialization, we can remove the state parameter from drm_private_obj_init and the fallback code. Reviewed-by: Dmitry Baryshkov Reviewed-by: Tomi Valkeinen Reviewed-by: Liviu Dudau Reviewed-by: Maíra Canal Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-4-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard

Merge drm/drm-next into drm-misc-next

2026-02-23T10:48:20+00:00

Let's merge 7.0-rc1 to start the new drm-misc-next window Signed-off-by: Maxime Ripard

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

drm/bridge: Switch private_obj initialization to atomic_create_state

2026-02-10T09:05:58+00:00

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 Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-4-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard

drm/bridge: fix kdoc syntax

2026-01-21T17:02:28+00:00

Use the correct kdoc syntax for bullet list. Fixes kdoc error and warning: Documentation/gpu/drm-kms-helpers:197: ./drivers/gpu/drm/drm_bridge.c:1519: ERROR: Unexpected indentation. [docutils] Documentation/gpu/drm-kms-helpers:197: ./drivers/gpu/drm/drm_bridge.c:1521: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512302319.1PGGt3CN-lkp@intel.com/ Fixes: 9da0e06abda8 ("drm/bridge: deprecate of_drm_find_bridge()") Reviewed-by: Nicolas Frattaroli Link: https://patch.msgid.link/20251231-drm-bridge-alloc-getput-drm_of_find_bridge-kdoc-fix-v1-1-193a03f0609c@bootlin.com Signed-off-by: Luca Ceresoli