From: Jayesh Choudhary <j-choudhary@ti.com>
To: <dri-devel@lists.freedesktop.org>, <sjakhade@cadence.com>,
<jsarha@ti.com>, <tomi.valkeinen@ideasonboard.com>,
<mripard@kernel.org>, <Laurent.pinchart@ideasonboard.com>,
<andrzej.hajda@intel.com>, <neil.armstrong@linaro.org>,
<rfoss@kernel.org>
Cc: <amishin@t-argos.ru>, <jani.nikula@intel.com>,
<tzimmermann@suse.de>, <maarten.lankhorst@linux.intel.com>,
<jonas@kwiboo.se>, <jernej.skrabec@gmail.com>,
<linux-kernel@vger.kernel.org>, <devarsht@ti.com>,
<j-choudhary@ti.com>
Subject: [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
Date: Thu, 16 Jan 2025 16:46:36 +0530 [thread overview]
Message-ID: <20250116111636.157641-1-j-choudhary@ti.com> (raw)
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
the connector structure is not initialised in the bridge. That's done
by encoder. So in case of some failure in cdns_mhdp_atomic_enable,
when we schedule work for modeset_retry_work, we will use the mutex
of connector which will result in NULL pointer dereference.
Handle it by adding condition for the connector. Otherwise, since
the modeset_retry_work tries to set the connector status as bad,
set the mhdp->plugged as false which would give the connector
status as disconnected in detect hook.
Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
NOTE: Found this issue in one particular board where edid read failed.
Issue log: <https://gist.github.com/Jayesh2000/233f87f9becdf1e66f1da6fd53f77429>
Adding conditional fixes the null pointer issue but there is still
flooding of these logs (128 times):
"cdns-mhdp8546 a000000.bridge: Failed to read DPCD addr 0"
Sending RFC as I am still not sure about how to handle this flooding.
Is it okay to decrease the log level for DPCD read and DPCD write in
the cdns_mhdp_transfer to debug?
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 24 ++++++++++---------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d081850e3c03..6a121a2700d2 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2363,18 +2363,20 @@ static void cdns_mhdp_modeset_retry_fn(struct work_struct *work)
mhdp = container_of(work, typeof(*mhdp), modeset_retry_work);
- conn = &mhdp->connector;
-
- /* Grab the locks before changing connector property */
- mutex_lock(&conn->dev->mode_config.mutex);
-
- /*
- * Set connector link status to BAD and send a Uevent to notify
- * userspace to do a modeset.
- */
- drm_connector_set_link_status_property(conn, DRM_MODE_LINK_STATUS_BAD);
- mutex_unlock(&conn->dev->mode_config.mutex);
+ if (mhdp->connector.dev) {
+ conn = &mhdp->connector;
+ /* Grab the locks before changing connector property */
+ mutex_lock(&conn->dev->mode_config.mutex);
+ /*
+ * Set connector link status to BAD and send a Uevent to notify
+ * userspace to do a modeset.
+ */
+ drm_connector_set_link_status_property(conn, DRM_MODE_LINK_STATUS_BAD);
+ mutex_unlock(&conn->dev->mode_config.mutex);
+ } else {
+ mhdp->plugged = false;
+ }
/* Send Hotplug uevent so userspace can reprobe */
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
}
--
2.34.1
next reply other threads:[~2025-01-16 11:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 11:16 Jayesh Choudhary [this message]
2025-01-23 16:20 ` [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference Tomi Valkeinen
2025-01-24 8:08 ` Alexander Stein
2025-01-28 5:57 ` Jayesh Choudhary
2025-05-21 7:36 ` Jayesh Choudhary
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=20250116111636.157641-1-j-choudhary@ti.com \
--to=j-choudhary@ti.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=amishin@t-argos.ru \
--cc=andrzej.hajda@intel.com \
--cc=devarsht@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=jsarha@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=sjakhade@cadence.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
/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.