kernel/linux.git/drivers/gpu/drm/drm_bridge.c, branch v6.19.11

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

drm/bridge: add warning for bridges attached without being added

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

DRM bridges must be added before they are attached. Add a warning to catch violations. The warning is based on the bridge not being part of any list, so it will trigger if the bridge is being attached without ever having been added. It won't catch cases of bridges attached after having been added and then removed, because in that case the bridge will be in bridge_lingering_list. However such a case is both more demanding to detect and less likely to happen, so it can be left unchecked, at least for now. Suggested-by: Maxime Ripard Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-4-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: document that adding a bridge is mandatory before attach

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

At the moment it's not documented that you need to add a bridge before attaching it. Clarify that. Suggested-by: Maxime Ripard Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou Reviewed-by: Maxime Ripard Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-3-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: refcount last_bridge in drm_atomic_bridge_chain_select_bus_fmts()

2025-10-03T07:05:25+00:00

Get a reference for the last_bridge when it is obtained and release it using a cleanup action. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250924-b4-drm-bridge-alloc-getput-drm_atomic_bridge_chain_select_bus_fmts-v1-1-f8c2efdb783f@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: adapt drm_bridge_add/remove() docs, mention the lingering list

2025-09-23T20:20:05+00:00

The role of drm_bridge_add/remove() is more complex now after having added the lingering list. Update the kdoc accordingly. Also stop mentioning the global list(s) in the first line of the docs: the most important thing to mention here is that bridges are registered and deregistered, lists are just the type of container used to implement such (de)registration. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250915-drm-bridge-debugfs-removed-v9-3-6e5c0aff5de9@bootlin.com Signed-off-by: Luca Ceresoli

drm/debugfs: show lingering bridges

2025-09-23T20:20:05+00:00

The usefulness of /sys/kernel/debug/dri/bridges is limited as it only shows bridges between drm_bridge_add() and drm_bridge_remove(). However refcounted bridges can stay allocated and lingering for a long time after drm_bridge_remove(), and a memory leak due to a missing drm_bridge_put() would not be visible in this debugfs file. Add lingering bridges to the /sys/kernel/debug/dri/bridges output. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250915-drm-bridge-debugfs-removed-v9-2-6e5c0aff5de9@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: add list of removed refcounted bridges

2025-09-23T20:20:05+00:00

Between drm_bridge_add() and drm_bridge_remove() bridges are registered to the DRM core via the global bridge_list and visible in /sys/kernel/debug/dri/bridges. However between drm_bridge_remove() and the last drm_bridge_put() memory is still allocated even though the bridge is not registered, i.e. not in bridges_list, and also not visible in debugfs. This prevents debugging refcounted bridges lifetime, especially leaks due to a missing drm_bridge_put(). In order to allow debugfs to also show the removed bridges, move such bridges into a new ad-hoc list until they are eventually freed. Note this requires adding INIT_LIST_HEAD(&bridge->list) in the bridge initialization code. The lack of such init was not exposing any bug so far, but it would with the new code, for example when a bridge is allocated and then freed without calling drm_bridge_add(), which is common on probe errors. drm_bridge_add() needs special care for bridges being added after having been previously added and then removed. This happens for example for many non-DCS DSI host bridge drivers like samsung-dsim which drm_bridge_add/remove() themselves every time the DSI device does a DSI attaches/detach. When the DSI device is hot-pluggable this happens multiple times in the lifetime of the DSI host bridge. On every attach after the first one, drm_bridge_add() finds bridge->list in the removed list, not at the initialized state as drm_bridge_add() currently expects. Add a list_del_init() to remove the bridge from the lingering list and bring bridge->list back to the initialized state. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250915-drm-bridge-debugfs-removed-v9-1-6e5c0aff5de9@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: put the bridge returned by drm_bridge_get_next_bridge()

2025-09-16T13:22:41+00:00

The bridge returned by drm_bridge_get_next_bridge() is refcounted. Put it when done. We need to ensure it is not put before either next_bridge or next_bridge_state is in use, thus for simplicity use a cleanup action. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250801-drm-bridge-alloc-getput-drm_bridge_get_next_bridge-v2-8-888912b0be13@bootlin.com Signed-off-by: Luca Ceresoli

drm/bridge: use drm_for_each_bridge_in_chain_scoped()

2025-09-16T13:02:45+00:00

Use drm_for_each_bridge_in_chain_scoped() instead of drm_for_each_bridge_in_chain() to ensure the bridge being looped on is refcounted. Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250808-drm-bridge-alloc-getput-for_each_bridge-v2-6-edb6ee81edf1@bootlin.com Signed-off-by: Luca Ceresoli

drm/debugfs: bridges_show: show refcount

2025-09-02T09:18:55+00:00

Now that bridges are refcounted, exposing the refcount in debugfs can be useful. Suggested-by: Dmitry Baryshkov Reviewed-by: Maxime Ripard Link: https://lore.kernel.org/r/20250819-drm-bridge-debugfs-removed-v7-1-970702579978@bootlin.com Signed-off-by: Luca Ceresoli