From: Johan Hovold <johan@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Vinod Koul <vkoul@kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Kuogee Hsieh <quic_khsieh@quicinc.com>,
freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH 2/6] drm/bridge: aux-hpd: separate allocation and registration
Date: Fri, 23 Feb 2024 13:46:15 +0100 [thread overview]
Message-ID: <ZdiTlwTOCROGD_AY@hovoldconsulting.com> (raw)
In-Reply-To: <CAA8EJpoxe8BmyFqMC5yrqdx-Sx2VR_2gT3x6WT9MyhdLuw+xmA@mail.gmail.com>
On Thu, Feb 22, 2024 at 10:57:07PM +0200, Dmitry Baryshkov wrote:
> On Sat, 17 Feb 2024 at 17:03, Johan Hovold <johan+linaro@kernel.org> wrote:
> >
> > Combining allocation and registration is an anti-pattern that should be
> > avoided. Add two new functions for allocating and registering an dp-hpd
> > bridge with a proper 'devm' prefix so that it is clear that these are
> > device managed interfaces.
> >
> > devm_drm_dp_hpd_bridge_alloc()
> > devm_drm_dp_hpd_bridge_add()
> >
> > The new interface will be used to fix a use-after-free bug in the
> > Qualcomm PMIC GLINK driver and may prevent similar issues from being
> > introduced elsewhere.
> >
> > The existing drm_dp_hpd_bridge_register() is reimplemented using the
> > above and left in place for now.
> >
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Thanks for reviewing.
> Minor nit below.
> > diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
> > index c4c423e97f06..4453906105ca 100644
> > --- a/include/drm/bridge/aux-bridge.h
> > +++ b/include/drm/bridge/aux-bridge.h
> > @@ -9,6 +9,8 @@
> >
> > #include <drm/drm_connector.h>
> >
> > +struct auxiliary_device;
> > +
> > #if IS_ENABLED(CONFIG_DRM_AUX_BRIDGE)
> > int drm_aux_bridge_register(struct device *parent);
> > #else
> > @@ -19,10 +21,23 @@ static inline int drm_aux_bridge_register(struct device *parent)
> > #endif
> >
> > #if IS_ENABLED(CONFIG_DRM_AUX_HPD_BRIDGE)
> > +struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent, struct device_node *np);
> > +int devm_drm_dp_hpd_bridge_add(struct device *dev, struct auxiliary_device *adev);
>
> I had a pretty close idea during prototyping, but I ended up doing it
> as a single function for the following reasons:
>
> First, this exports the implementation detail that internally the code
> uses an aux device.
That's not an issue. The opposite, with interfaces trying to do too much
and hide details from the developers so that they can no longer reason
about what is going on, is a real problem though.
> Also, by exporting the aux device the code becomes less type-safe. By
> mistake one can call devm_drm_dp_hpd_bridge_add() on any aux device,
> which is not necessarily the HPD bridge.
No. First, that is currently not even an issue either as the
registration interface is safe to use with any aux device.
Second, if you cared about about type-safety you wouldn't have used a
struct device pointer for drm_aux_hpd_bridge_notify() which you back
cast to an aux device.
> I'd prefer to see an opaque device-specific structure instead. WDYT?
That should have been there from the start. But I'm not interested in
cleaning up this mess beyond what is minimally required to fix the
regressions it caused.
This can be reworked for 6.9 or later.
> > struct device *drm_dp_hpd_bridge_register(struct device *parent,
> > struct device_node *np);
> > void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status);
Johan
next prev parent reply other threads:[~2024-02-23 12:46 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 15:02 [PATCH 0/6] soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Johan Hovold
2024-02-17 15:02 ` [PATCH 1/6] drm/bridge: aux-hpd: fix OF node leaks Johan Hovold
2024-02-19 17:48 ` Markus Elfring
2024-02-20 7:24 ` Johan Hovold
2024-02-20 11:52 ` Julia Lawall
2024-02-20 11:55 ` Dmitry Baryshkov
2024-02-20 12:56 ` Julia Lawall
2024-02-20 13:35 ` Dmitry Baryshkov
2024-02-22 1:22 ` Bjorn Andersson
2024-02-22 21:00 ` Dmitry Baryshkov
2024-02-23 10:56 ` Neil Armstrong
2024-02-23 10:56 ` Neil Armstrong
2024-02-17 15:02 ` [PATCH 2/6] drm/bridge: aux-hpd: separate allocation and registration Johan Hovold
2024-02-22 2:06 ` Bjorn Andersson
2024-02-22 16:06 ` Johan Hovold
2024-02-22 20:57 ` Dmitry Baryshkov
2024-02-23 12:46 ` Johan Hovold [this message]
2024-02-17 15:02 ` [PATCH 3/6] soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Johan Hovold
2024-02-20 8:25 ` Markus Elfring
2024-02-20 10:55 ` Markus Elfring
2024-02-20 11:26 ` Johan Hovold
2024-02-20 12:40 ` [3/6] " Markus Elfring
2024-02-22 2:11 ` [PATCH 3/6] " Bjorn Andersson
2024-02-22 21:10 ` Dmitry Baryshkov
2024-02-17 15:02 ` [PATCH 4/6] soc: qcom: pmic_glink: Fix boot when QRTR=m Johan Hovold
2024-02-22 2:18 ` Bjorn Andersson
2024-02-22 21:10 ` Dmitry Baryshkov
2024-02-23 11:04 ` Neil Armstrong
2024-02-17 15:02 ` [PATCH 5/6] phy: qcom-qmp-combo: fix drm bridge registration Johan Hovold
2024-02-19 9:03 ` Neil Armstrong
2024-02-22 2:21 ` Bjorn Andersson
2024-02-22 21:11 ` Dmitry Baryshkov
2024-02-23 12:09 ` Vinod Koul
2024-02-17 15:02 ` [PATCH 6/6] phy: qcom-qmp-combo: fix type-c switch registration Johan Hovold
2024-02-22 2:23 ` Bjorn Andersson
2024-02-22 21:12 ` Dmitry Baryshkov
2024-02-23 12:10 ` Vinod Koul
2024-02-23 11:02 ` [PATCH 0/6] soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Neil Armstrong
2024-02-23 11:03 ` Neil Armstrong
2024-02-23 12:51 ` Johan Hovold
2024-02-23 13:52 ` Neil Armstrong
2024-02-23 14:18 ` Dmitry Baryshkov
2024-02-23 14:28 ` Johan Hovold
2024-02-23 14:21 ` Johan Hovold
2024-02-23 14:38 ` Neil Armstrong
2024-02-23 14:52 ` Johan Hovold
2024-02-23 14:55 ` Neil Armstrong
2024-02-23 15:07 ` Dmitry Baryshkov
2024-02-23 14:54 ` Neil Armstrong
2024-02-23 15:06 ` (subset) " Dmitry Baryshkov
2024-03-06 17:47 ` Vinod Koul
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=ZdiTlwTOCROGD_AY@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=johan+linaro@kernel.org \
--cc=jonas@kwiboo.se \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=rfoss@kernel.org \
--cc=robdclark@gmail.com \
--cc=tzimmermann@suse.de \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox