From: sashiko-bot@kernel.org
To: "Damon Ding" <damon.ding@rock-chips.com>
Cc: dri-devel@lists.freedesktop.org, robh@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 09/10] drm/bridge: analogix_dp: Restrict forced connected status only for panel endpoint
Date: Tue, 04 Aug 2026 08:30:52 +0000 [thread overview]
Message-ID: <20260804083053.70A301F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804081717.741404-10-damon.ding@rock-chips.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing early return in analogix_dp_bridge_detect() causes unintended hardware accesses and significant delays for panel bridges.
- [Medium] Missing drm_bridge_put() causes a reference count leak for the bridge returned by drm_bridge_chain_get_last_bridge().
--
--- Patch [9]: [PATCH v2 09/10] drm/bridge: analogix_dp: Restrict forced connected status only for panel endpoint ---
commit 7e658941bfdab69a58f5d04d4acd4ae671e37ea8
Author: Damon Ding <damon.ding@rock-chips.com>
drm/bridge: analogix_dp: Restrict forced connected status only for panel endpoint
This commit limits the unconditional connected status shortcut to cases
where the last bridge in the chain is a panel. For other cases, it relies
on analogix_dp_detect_hpd() to report accurate hotplug state.
Link: https://lore.kernel.org/all/5209243.oAaWjsssbx@diego/
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1c85ca93ee7b1..f7db5b5a3f917 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -910,8 +910,15 @@ analogix_dp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *conne
> struct analogix_dp_device *dp = to_dp(bridge);
> enum drm_connector_status status = connector_status_disconnected;
>
> - if (dp->plat_data->next_bridge)
> - return connector_status_connected;
> + /*
> + * Only assume connected when the bridge chain ends with a panel.
> + * Panel bridges lack a detect callback and historically rely on
> + * this shortcut. For other next bridge types (e.g., DP connector
> + * bridges), fall through to analogix_dp_detect_hpd() to report
> + * accurate hotplug state.
> + */
> + if (dp->plat_data->next_bridge && dp->last_bridge_is_panel)
> + status = connector_status_connected;
>
> if (!analogix_dp_detect_hpd(dp))
> status = connector_status_connected;
[Severity: High]
Does this unintentionally fall through and execute analogix_dp_detect_hpd()
even when the bridge chain ends with a panel?
Previously, analogix_dp_bridge_detect() returned early here. By just
assigning the status without returning, it looks like panel bridges will now
unconditionally execute analogix_dp_detect_hpd(). This can introduce an
unnecessary 100ms delay and unintended register/AUX writes to manually force
HPD on hardware that lacks an HPD signal.
Should there be an early return here instead of continuing execution?
[ ... ]
> @@ -938,6 +946,10 @@ static int analogix_dp_bridge_attach(struct drm_bridge *bridge,
> dev_err(dp->dev, "failed to attach following panel or bridge (%d)\n", ret);
> return ret;
> }
> +
> + last_bridge = drm_bridge_chain_get_last_bridge(dp->encoder);
> + if (drm_bridge_is_panel(last_bridge))
> + dp->last_bridge_is_panel = true;
> }
>
> return 0;
[Severity: Medium]
Does this leak the reference to the last bridge in analogix_dp_bridge_attach()?
drm_bridge_chain_get_last_bridge() increments the reference count of the
returned bridge, but it doesn't appear that drm_bridge_put() is called
before the function returns. Will this prevent proper cleanup when the
device is unbound or the module is unloaded?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804081717.741404-1-damon.ding@rock-chips.com?part=9
next prev parent reply other threads:[~2026-08-04 8:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 8:17 [PATCH v2 00/10] Add HPD support for Rockchip Analogix DP Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 01/10] drm/bridge: analogix_dp: Manage pm runtime and IRQ for native HPD pin detection Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:37 ` sashiko-bot
2026-08-04 8:17 ` [PATCH v2 02/10] drm/bridge: analogix_dp: Return bitmask from analogix_dp_get_irq_type() Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 03/10] drm/bridge: analogix_dp: Add IRQF_ONESHOT and simplify IRQ handling Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:33 ` sashiko-bot
2026-08-04 8:17 ` [PATCH v2 04/10] drm/bridge: analogix_dp: Extend clear_hotplug_interrupts to accept IRQ bitmask Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 05/10] drm/bridge: analogix_dp: Extend mute/unmute HPD interrupts to accept irq bitmask Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 06/10] drm/bridge: analogix_dp: Simplify analogix_dp_config_interrupt() Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 07/10] drm/bridge: analogix_dp: Use platform-specific HPD detection scheme Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:32 ` sashiko-bot
2026-08-04 8:17 ` [PATCH v2 08/10] drm/bridge: analogix_dp: Skip native HPD interrupt ops for GPIO HPD Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:17 ` [PATCH v2 09/10] drm/bridge: analogix_dp: Restrict forced connected status only for panel endpoint Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:30 ` sashiko-bot [this message]
2026-08-04 8:17 ` [PATCH v2 10/10] drm/bridge: analogix_dp: Handle HPD notification from downstream bridge Damon Ding
2026-08-04 8:17 ` Damon Ding
2026-08-04 8:44 ` sashiko-bot
2026-08-04 22:39 ` [PATCH v2 00/10] Add HPD support for Rockchip Analogix DP Heiko Stübner
2026-08-04 22:39 ` Heiko Stübner
2026-08-05 4:06 ` Damon Ding
2026-08-05 4:06 ` Damon Ding
2026-08-05 23:42 ` Heiko Stübner
2026-08-05 23:42 ` Heiko Stübner
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=20260804083053.70A301F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=damon.ding@rock-chips.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robh@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.