From: sashiko-bot@kernel.org
To: "Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 03/24] drm/msm: create the display connectors from common code
Date: Wed, 22 Jul 2026 07:04:20 +0000 [thread overview]
Message-ID: <20260722070420.7A6851F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260722-drm-msm-display-interface-v1-3-368c10fe62fd@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional calls to modeset_init functions with potentially NULL encoders causes kernel crash or probe failure.
--
--- Patch [3]: [PATCH 03/24] drm/msm: create the display connectors from common code ---
commit a0a4ea009e59812e9ecb6b60251e9294d0b779b8
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drm/msm: create the display connectors from common code
This commit moves the bridge and connector setup logic from the individual
KMS backends into a common msm_kms_init_connectors() function. The backend
is now only responsible for creating the encoder, which is then used by the
common code.
> diff --git a/drivers/gpu/drm/msm/msm_kms.c b/drivers/gpu/drm/msm/msm_kms.c
> index e5d0ea6294484..87530145e82b0 100644
> --- a/drivers/gpu/drm/msm/msm_kms.c
> +++ b/drivers/gpu/drm/msm/msm_kms.c
[ ... ]
> @@ -260,6 +260,57 @@ void msm_drm_kms_uninit(struct device *dev)
> kms->funcs->destroy(kms);
> }
>
> +/*
> + * Set up the bridges and connectors for the display sub-blocks, using the
> + * encoders the backend created in ->kms_init().
> + */
> +static int msm_kms_init_connectors(struct drm_device *ddev)
> +{
> + struct msm_drm_private *priv = ddev->dev_private;
> + struct msm_kms *kms = priv->kms;
> + int i, ret;
[ ... ]
> + if (kms->hdmi) {
> + ret = msm_hdmi_modeset_init(kms->hdmi, ddev, kms->hdmi_encoder);
[Severity: High]
Will this cause a NULL pointer dereference if the encoder was not created?
If the device tree defines an HDMI node (so kms->hdmi is populated), but the
KMS backend's hardware configuration doesn't support the interface, encoder
creation is skipped and kms->hdmi_encoder remains NULL.
If msm_hdmi_modeset_init() receives a NULL encoder and there is no external
bridge, it eventually calls drm_bridge_connector_init():
drivers/gpu/drm/msm/hdmi/hdmi.c:msm_hdmi_modeset_init() {
...
hdmi->connector = drm_bridge_connector_init(hdmi->dev, encoder);
...
}
This unconditionally dereferences the encoder to access the bridge chain:
drivers/gpu/drm/display/drm_bridge_connector.c:drm_bridge_connector_init() {
...
drm_for_each_bridge_in_chain(encoder, bridge) {
...
}
Should there be a check ensuring the encoder was actually populated before
calling msm_hdmi_modeset_init() (and similarly for DP and DSI above this)?
> + if (ret) {
> + DRM_DEV_ERROR(ddev->dev,
> + "modeset_init failed for HDMI: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260722-drm-msm-display-interface-v1-0-368c10fe62fd@oss.qualcomm.com?part=3
next prev parent reply other threads:[~2026-07-22 7:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 6:36 [PATCH 00/24] drm/msm: introduce the struct msm_display interface Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 01/24] drm/msm/dp: reject YUV420-only modes without VSC SDP support Dmitry Baryshkov
2026-07-22 7:03 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 02/24] drm/msm/dp: drop the always-true yuv_supported argument Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 03/24] drm/msm: create the display connectors from common code Dmitry Baryshkov
2026-07-22 7:04 ` sashiko-bot [this message]
2026-07-22 6:36 ` [PATCH 04/24] drm/msm: introduce the struct msm_display interface Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 05/24] drm/msm: route the display snapshot through the " Dmitry Baryshkov
2026-07-22 6:56 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 06/24] drm/msm/hdmi: capture the HDMI registers in the display snapshot Dmitry Baryshkov
2026-07-22 6:59 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 07/24] drm/msm: add the wide_bus_enabled callback to msm_display Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 08/24] drm/msm: add the needs_periph_flush " Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 09/24] drm/msm: add the is_cmd_mode " Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 10/24] drm/msm: add the get_dsc_config " Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 11/24] drm/msm: add the get_te_source " Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 12/24] drm/msm: add is_bonded and needs_encoder callbacks " Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 13/24] drm/msm/hdmi: use dev_get_drvdata() in msm_hdmi_unbind() Dmitry Baryshkov
2026-07-22 7:03 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 14/24] drm/msm: store the display sub-blocks as struct msm_display Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 15/24] drm/msm/dp: do not reject wide-bus modes while a YUV420 mode is active Dmitry Baryshkov
2026-07-22 7:03 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 16/24] drm/msm/dp: remove cached drm_edid from panel Dmitry Baryshkov
2026-07-22 7:08 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 17/24] drm/msm/dp: drop deprecated .mode_set() and use .atomic_pre_enable Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 18/24] drm/msm/hdmi: cache is_hdmi instead of storing the connector Dmitry Baryshkov
2026-07-22 7:06 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 19/24] drm/msm/dp: drop redundant panel->connector Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 20/24] drm/msm/dp: use drm_display_info in mode_valid callbacks Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 21/24] drm/msm/dp: guard subconnector setup on the connector type Dmitry Baryshkov
2026-07-22 6:36 ` [PATCH 22/24] drm/msm/dp: stop storing the connector in struct msm_dp Dmitry Baryshkov
2026-07-22 7:12 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 23/24] drm/msm: create the bridge connectors from common code Dmitry Baryshkov
2026-07-22 7:04 ` sashiko-bot
2026-07-22 6:36 ` [PATCH 24/24] drm/bridge-connector: attach the DP subconnector property Dmitry Baryshkov
2026-07-22 7:05 ` sashiko-bot
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=20260722070420.7A6851F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.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.