kernel/linux.git/drivers/gpu/drm/drm_bridge.c, branch linux-7.0.y

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

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

drm/bridge: add next_bridge pointer to struct drm_bridge

2025-12-30T09:11:33+00:00

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 Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/ Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: make of_drm_find_bridge() a wrapper of of_drm_find_and_get_bridge()

2025-12-30T09:11:32+00:00

of_drm_find_bridge() is identical to of_drm_find_and_get_bridge() except it does not increment the refcount. Rewrite it as a wrapper and put the bridge being returned so the behaviour is still the same. Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-4-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: deprecate of_drm_find_bridge()

2025-12-30T09:11:32+00:00

of_drm_find_bridge() does not increment the returned bridge refcount. of_drm_find_and_get_bridge() is to be used as a replacement. Suggested-by: Maxime Ripard Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/ Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-2-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: add of_drm_find_and_get_bridge()

2025-12-30T09:11:32+00:00

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 Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/ Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit()

2025-12-11T10:28:43+00:00

To allow DRM bridges to be removable, add synchronization functions allowing to tell when a bridge hardware has been physically unplugged and to mark a critical section that should not be entered after that. This is inspired by the drm_dev_unplugged/enter/exit() functions for struct drm_device. Suggested-by: Maxime Ripard Link: https://lore.kernel.org/all/20250106-vigorous-talented-viper-fa49d9@houat/ Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251112-drm-bridge-atomic-vs-remove-v3-1-85db717ce094@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: add warning for bridges using neither devm_drm_bridge_alloc() nor drm_bridge_add()

2025-11-03T12:04:55+00:00

The correct sequence for bridge initialization is: 1. devm_drm_bridge_alloc() 2. drm_bridge_add() 3. drm_bridge_attach() For bridges missing either 1 or 2 there are warnings in place already, presenting an explanatory error message. Bridges missing both 1 and 2 would still face a poorly understandable message, as reported in a recent regression report [0]: WARNING: [...] at [...]/lib/refcount.c:25 drm_bridge_attach+0x2c/0x1dc ... Call trace: ... drm_bridge_attach ... Add a new warning to ensure an understandable message is logged in such cases. Use the same message and warning message already in place in drm_bridge_add(). [0] https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/ Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-5-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli