From: sashiko-bot@kernel.org
To: "Kory Maincent" <kory.maincent@bootlin.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH RFC v3 6/8] drm/bridge: Expose link training state via new DRM_BRIDGE_OP_DP flag
Date: Mon, 12 Oct 2026 15:20:43 +0000 [thread overview]
Message-ID: <sashiko-outbox-168325@kernel.org> (raw)
In-Reply-To: <20261012-feat_link_cap-v3-6-7517f4aba0f3@bootlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm: Probe failure for DP pipelines ending in non-DP connectors
--
commit 1f392a73217bd39ddc3ecb68c1400cefdd77a913
Author: Kory Maincent <kory.maincent@bootlin.com>
Subject: drm/bridge: Expose link training state via new DRM_BRIDGE_OP_DP flag
This commit introduces DRM_BRIDGE_OP_DP, a new bridge operation flag for
bridges that provide DisplayPort connector operations with link training
support. Bridges advertising this flag must fill the dp_link_caps field
with their link capabilities.
> diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
> --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
[ ... ]
> @@ -1079,6 +1097,17 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
> connector_type, ddc);
> if (ret)
> return ERR_PTR(ret);
> + } else if (bridge_connector->bridge_dp) {
> + ret = drmm_connector_init(drm, connector,
> + &drm_bridge_connector_funcs,
> + connector_type, ddc);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ret = drm_dp_source_set_caps(connector,
> + bridge_connector->bridge_dp->dp_link_caps);
> + if (ret)
> + return ERR_PTR(ret);
[Severity: High]
Does this cause a probe failure for DisplayPort pipelines that end in a non-DP
connector?
Earlier in drm_bridge_connector_init(), the final connector_type is determined
by the last bridge in the chain. If a display pipeline ends with an active
converter (like a DP-to-VGA or DP-to-LVDS bridge), the resulting connector
type will be non-DP (e.g., DRM_MODE_CONNECTOR_VGA).
However, this block unconditionally calls drm_dp_source_set_caps() as long as
any upstream bridge advertises DRM_BRIDGE_OP_DP and there is no HDMI bridge.
Looking at drm_dp_source_set_caps() in drm_dp_helper.c, it has a strict check
for the connector type:
if (!(connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector->connector_type == DRM_MODE_CONNECTOR_eDP))
return -EINVAL;
If the pipeline ends in a VGA or LVDS connector, this will return -EINVAL,
which is then propagated up by drm_bridge_connector_init(), causing the entire
display pipeline initialization to fail for otherwise valid bridge chains.
Could we add a check here to ensure the connector type is actually DP or eDP
before calling drm_dp_source_set_caps()?
> } else {
> ret = drmm_connector_init(drm, connector,
> &drm_bridge_connector_funcs,
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-feat_link_cap-v3-0-7517f4aba0f3@bootlin.com?part=6
next prev parent reply other threads:[~2026-10-12 15:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 15:10 [PATCH RFC v3 0/8] Add support for DisplayPort link training information report Kory Maincent
2026-10-12 15:10 ` [PATCH RFC v3 1/8] drm: Move sink link rates reading helpers out of i915 Kory Maincent
2026-10-12 15:26 ` sashiko-bot
2026-10-12 15:10 ` [PATCH RFC v3 2/8] drm: Move DSC capability reading helper " Kory Maincent
2026-10-12 15:10 ` [PATCH RFC v3 3/8] drm: Introduce DisplayPort link training capabilities and state helpers Kory Maincent
2026-10-12 15:23 ` sashiko-bot
2026-10-12 15:10 ` [PATCH RFC v3 4/8] drm/i915/display/dp: Read DPCD DSC capabilities in any case Kory Maincent
2026-10-12 15:11 ` [PATCH RFC v3 5/8] drm/i915/display/dp: Use dp_connector helpers to expose link training state Kory Maincent
2026-10-12 15:24 ` sashiko-bot
2026-10-12 15:11 ` [PATCH RFC v3 6/8] drm/bridge: Expose link training state via new DRM_BRIDGE_OP_DP flag Kory Maincent
2026-10-12 15:20 ` sashiko-bot [this message]
2026-10-12 15:11 ` [PATCH RFC v3 7/8] drm/analogix/anx7625: Use dp_connector helpers to expose link training state Kory Maincent
2026-10-12 15:26 ` sashiko-bot
2026-10-12 15:11 ` [PATCH RFC v3 8/8] drm/mediatek: " Kory Maincent
2026-10-12 15:26 ` sashiko-bot
2026-10-13 18:12 ` ✗ Fi.CI.BUILD: failure for Add support for DisplayPort link training information report Patchwork
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=sashiko-outbox-168325@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=kory.maincent@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 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.