dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 09/11] drm/mcde: dsi: don't create a panel_bridge
Date: Fri, 14 Aug 2026 14:24:20 +0000	[thread overview]
Message-ID: <20260814142421.128F01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814-drm-bridge-every-panel-v1-9-19cd5277cc8d@bootlin.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The reference to the remote bridge (next_bridge) acquired during bind is permanently leaked on unbind.

Pre-existing issues:
- [High] Component unbind is missing drm_bridge_remove(), leading to list corruption and memory leaks upon rebind or module unload.
- [High] The driver returns -EINVAL instead of -EPROBE_DEFER when the downstream bridge is not found, breaking probe deferral.
- [High] Calling devm_clk_get() inside a repeatable component bind function causes a devres leak.
--

--- Patch [9]: [PATCH 09/11] drm/mcde: dsi: don't create a panel_bridge ---
commit 62f9247edbd74ae414416ce89cd9ec90e6811731
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>

drm/mcde: dsi: don't create a panel_bridge

Now a panel_bridge is automatically created for every drm_panel, so this
code (similar to an open-coded variant of drm_of_find_panel_or_bridge())
would lead to creating a second panel_bridge for the same panel.

> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index ce078aa3910f2..ec45440d20d70 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
[ ... ]
> @@ -1076,7 +1075,6 @@ static int mcde_dsi_bind(struct device *dev, struct device *master,
>  	struct drm_device *drm = data;
>  	struct mcde *mcde = to_mcde(drm);
>  	struct mcde_dsi *d = dev_get_drvdata(dev);
> -	struct drm_panel *panel = NULL;

[Severity: High]
This is a pre-existing issue, but does calling devm_clk_get() inside
mcde_dsi_bind() cause a devres memory leak?

Since component drivers can be unbound and rebound multiple times (such as
via sysfs or master probe deferral), devres allocations in the bind
path will accumulate every time the component binds, because devres chunks
are bound to the platform device's lifetime, not the component bind/unbind
lifecycle.

[ ... ]
> @@ -1104,40 +1102,21 @@ static int mcde_dsi_bind(struct device *dev, struct device *master,
>  
>  	/* Look for a panel as a child to this node */
>  	for_each_available_child_of_node_scoped(dev->of_node, child) {
> -		panel = of_drm_find_panel(child);
> -		if (IS_ERR(panel)) {
> -			dev_err(dev, "failed to find panel try bridge (%ld)\n",
> -				PTR_ERR(panel));
> -			panel = NULL;
> -
> -			bridge = of_drm_find_and_get_bridge(child);
> -			if (!bridge) {
> -				dev_err(dev, "failed to find bridge\n");
> -				return -EINVAL;
> -			}
> +		bridge = of_drm_find_and_get_bridge(child);
> +		if (!bridge) {
> +			dev_err(dev, "failed to find bridge\n");
> +			return -EINVAL;

[Severity: High]
This isn't a bug introduced by this patch, but should this return
-EPROBE_DEFER instead of -EINVAL when the downstream bridge is not found?

Returning a hard -EINVAL when of_drm_find_and_get_bridge() returns NULL
aborts the display probe irrevocably if the downstream panel/bridge probes
after the MCDE DSI host, rather than deferring the probe until it is ready.

[ ... ]
> @@ -1159,8 +1138,6 @@ static void mcde_dsi_unbind(struct device *dev, struct device *master,
>  {
>  	struct mcde_dsi *d = dev_get_drvdata(dev);
>  
> -	if (d->panel)
> -		drm_panel_bridge_remove(d->bridge.next_bridge);

[Severity: High]
Since this patch removes drm_panel_bridge_remove(), is a call to
drm_bridge_put(d->bridge.next_bridge) needed here to balance the reference
acquired in mcde_dsi_bind()?

In mcde_dsi_bind(), a reference to the downstream bridge is acquired and
stored via:

    d->bridge.next_bridge = drm_bridge_get(bridge);

Without a corresponding drm_bridge_put() here, the reference is stranded.
Upon the next rebind, a new reference is acquired and overwrites the old
pointer, permanently leaking the downstream bridge reference.

[Severity: High]
This is a pre-existing issue, but is a call to drm_bridge_remove(&d->bridge)
missing from mcde_dsi_unbind()?

mcde_dsi_bind() registers the bridge globally via
drm_bridge_add(&d->bridge). Without drm_bridge_remove() in the unbind path,
a rebind will call drm_bridge_add() on the same bridge object.

This invokes list_del_init(&bridge->list) without holding the bridge_lock,
introducing a data race that can corrupt the global bridge_list if traversed
concurrently. Additionally, it prevents the bridge's refcount from ever
reaching zero.

>  	regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET,
>  			   PRCM_DSI_SW_RESET_DSI0_SW_RESETN, 0);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260814-drm-bridge-every-panel-v1-0-19cd5277cc8d@bootlin.com?part=9

  reply	other threads:[~2026-08-14 14:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 14:05 [PATCH 00/11] drm/panel: add a panel_bridge to every panel Luca Ceresoli
2026-08-14 14:05 ` [PATCH 01/11] drm: of: drm_of_find_panel_or_bridge: simplify freeing the remote node pointer Luca Ceresoli
2026-08-17  8:21   ` Maxime Ripard
2026-08-14 14:05 ` [PATCH 02/11] drm: of: drm_of_find_panel_or_bridge: simplify error return paths Luca Ceresoli
2026-08-17  8:23   ` Maxime Ripard
2026-08-14 14:05 ` [PATCH 03/11] drm: of: drm_of_find_panel_or_bridge: prioritize the bridge, not the panel Luca Ceresoli
2026-08-14 14:20   ` sashiko-bot
2026-08-17  8:26   ` Maxime Ripard
2026-08-17 12:23     ` Luca Ceresoli
2026-08-24  8:16       ` Maxime Ripard
2026-08-24 14:15         ` Luca Ceresoli
2026-08-14 14:05 ` [PATCH 04/11] drm/panel: merge the drm_kms_helper module into the drm module Luca Ceresoli
2026-08-14 14:13   ` sashiko-bot
2026-08-17  8:31   ` Maxime Ripard
2026-08-17 12:27     ` Luca Ceresoli
2026-08-24  7:48       ` Maxime Ripard
2026-08-24 14:16         ` Luca Ceresoli
2026-08-14 14:05 ` [PATCH 05/11] drm/bridge: panel: add a panel_bridge to every panel Luca Ceresoli
2026-08-14 14:25   ` sashiko-bot
2026-08-17 14:07     ` Luca Ceresoli
2026-08-17  8:42   ` Maxime Ripard
2026-08-17 12:30     ` Luca Ceresoli
2026-08-14 14:05 ` [PATCH 06/11] drm/bridge: tc358767: don't create a panel_bridge Luca Ceresoli
2026-08-14 14:17   ` sashiko-bot
2026-08-14 14:05 ` [PATCH 07/11] drm/bridge: waveshare-dsi: " Luca Ceresoli
2026-08-14 14:05 ` [PATCH 08/11] drm/mcde: dsi: simplify device_node management using scoped for_each variant Luca Ceresoli
2026-08-14 14:19   ` sashiko-bot
2026-08-17  8:43   ` Maxime Ripard
2026-08-17 12:25   ` Linus Walleij
2026-08-17 12:34     ` Luca Ceresoli
2026-08-14 14:05 ` [PATCH 09/11] drm/mcde: dsi: don't create a panel_bridge Luca Ceresoli
2026-08-14 14:24   ` sashiko-bot [this message]
2026-08-17 12:23   ` Linus Walleij
2026-08-14 14:05 ` [PATCH 10/11] drm/bridge: fsl-ldb: " Luca Ceresoli
2026-08-14 14:18   ` sashiko-bot
2026-08-14 14:05 ` [PATCH 11/11] drm/bridge: samsung-dsim: " Luca Ceresoli
2026-08-14 14:23   ` sashiko-bot
2026-08-14 14:13 ` [PATCH 00/11] drm/panel: add a panel_bridge to every panel Luca Ceresoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260814142421.128F01F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox