[PATCH] drm/bridge: ti-sn65dsi86: Put the host node if DSI attachment fails

[PATCH] drm/bridge: ti-sn65dsi86: Put the host node if DSI attachment fails

[Wentao Liang]

ti_sn_bridge_parse_dsi_host() takes a reference to the remote DSI host
node. If ti_sn_attach_host() fails, ti_sn_bridge_probe() removes the
bridge but leaves the node reference held. The remove callback is not
called after failed probe, so a deferred probe can leak another reference
on each attempt.

Drop the host node reference in the existing attachment failure path.

Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe")
Cc: stable@vger.kernel.org
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 48b83df9aed6..f4cf3b4af876 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1465,6 +1465,7 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
 
 err_remove_bridge:
 	drm_bridge_remove(&pdata->bridge);
+	of_node_put(pdata->host_node);
 	return ret;
 }
 
-- 
2.34.1

Re: [PATCH] drm/bridge: ti-sn65dsi86: Put the host node if DSI attachment fails

[Krzysztof Kozlowski]

On 03/11/2026 07:51, Wentao Liang wrote:
> ti_sn_bridge_parse_dsi_host() takes a reference to the remote DSI host
> node. If ti_sn_attach_host() fails, ti_sn_bridge_probe() removes the
> bridge but leaves the node reference held. The remove callback is not
> called after failed probe, so a deferred probe can leak another reference
> on each attempt.
> 
> Drop the host node reference in the existing attachment failure path.
> 
> Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe")
> Cc: stable@vger.kernel.org
> Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

Not even bothering to run checkpatch.

> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>

Another fake identity of "vulab" doing exactly the same as other cases,
repeating same mistake of running unsupervised crappy bot even though
was asked multiple times to fix that.


Best regards,
Krzysztof