From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Jayesh Choudhary <j-choudhary@ti.com>,
dri-devel@lists.freedesktop.org, sjakhade@cadence.com,
jsarha@ti.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
Subject: Re: [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
Date: Thu, 23 Jan 2025 18:20:34 +0200 [thread overview]
Message-ID: <e76f94b9-b138-46e7-bb18-b33dd98c9abb@ideasonboard.com> (raw)
In-Reply-To: <20250116111636.157641-1-j-choudhary@ti.com>
Hi,
On 16/01/2025 13:16, Jayesh Choudhary wrote:
> For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
Any idea if any other platform than K3 is using this driver? tidss
supports DRM_BRIDGE_ATTACH_NO_CONNECTOR, so if K3 is the only user, we
could drop the legacy !DRM_BRIDGE_ATTACH_NO_CONNECTOR case. Which would
remove quite a bit of code, I think, and make the driver a bit more easy
to understand (although I think it could use a major cleanup...).
> 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.
I'm not quite sure if this whole system makes sense (no one else is
doing it), but I think you can find the connector from the current
state. Then setting the property could be done for
DRM_BRIDGE_ATTACH_NO_CONNECTOR case too.
Tomi
> 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);
> }
next prev parent reply other threads:[~2025-01-23 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 11:16 [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference Jayesh Choudhary
2025-01-23 16:20 ` Tomi Valkeinen [this message]
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=e76f94b9-b138-46e7-bb18-b33dd98c9abb@ideasonboard.com \
--to=tomi.valkeinen@ideasonboard.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=j-choudhary@ti.com \
--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=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.