From: Maxime Ripard <mripard@kernel.org>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Inki Dae <inki.dae@samsung.com>,
Jagan Teki <jagan@amarulasolutions.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Hui Pu <Hui.Pu@gehealthcare.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-sunxi@lists.linux.dev, Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices
Date: Mon, 7 Jul 2025 08:16:49 +0200 [thread overview]
Message-ID: <20250707-strange-warm-bear-cb4ee8@houat> (raw)
In-Reply-To: <20250625-drm-dsi-host-no-device-ptr-v1-0-e36bc258a7c5@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 5009 bytes --]
Hi Luca,
On Wed, Jun 25, 2025 at 06:45:04PM +0200, Luca Ceresoli wrote:
> This series is the first attempt at avoiding DSI host drivers to have
> pointers to DSI devices (struct mipi_dsi_device), as discussed during the
> Linux Plumbers Conference 2024 with Maxime and Dmitry.
>
> It is working, but I consider this a draft in order to discuss and
> challenge the proposed approach.
>
> Overall work
> ============
>
> This is part of the work towards removal of bridges from a still existing
> DRM pipeline without use-after-free. The grand plan as discussed in [1].
> Here's the work breakdown (➜ marks the current series):
>
> 1. … add refcounting to DRM bridges (struct drm_bridge)
> (based on devm_drm_bridge_alloc() [0])
> A. ✔ add new alloc API and refcounting (in v6.16-rc1)
> B. ✔ convert all bridge drivers to new API (now in drm-misc-next)
> C. ✔ kunit tests (now in drm-misc-next)
> D. … add get/put to drm_bridge_add/remove() + attach/detach()
> and warn on old allocation pattern (under review)
> E. … add get/put on drm_bridge accessors
> 1. … drm_bridge_chain_get_first_bridge() + add a cleanup action
> 2. … drm_bridge_chain_get_last_bridge()
> 3. drm_bridge_get_prev_bridge()
> 4. drm_bridge_get_next_bridge()
> 5. drm_for_each_bridge_in_chain()
> 6. drm_bridge_connector_init
> 7. of_drm_find_bridge
> 8. drm_of_find_panel_or_bridge, *_of_get_bridge
> F. debugfs improvements
> 2. handle gracefully atomic updates during bridge removal
> 3. ➜ avoid DSI host drivers to have dangling pointers to DSI devices
> (this series)
> 4. finish the hotplug bridge work, removing the "always-disconnected"
> connector, moving code to the core and potentially removing the
> hotplug-bridge itself (this needs to be clarified as points 1-3 are
> developed)
>
> [0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0cc6aadd7fc1e629b715ea3d1ba537ef2da95eec
> [1] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/t/#u
>
> Motivation
> ==========
>
> The motivation for this series is that with hot-pluggable hardware a DSI
> device can be disconnected from the DSI host at runtime, and later on
> reconnected, potentially with a different model having different bus
> parameters.
>
> DSI host drivers currently receive a struct mipi_dsi_device pointer in the
> attach callback and some store it permanently for later access to the bur
> format data (lanes, channel, pixel format etc). The stored pointer can
> become dangling if the device is removed, leading to a use-after-free.
>
> Currently the data exchange between DSI host and device happens primarily
> by two means:
>
> * the device requests attach, detach and message transfer to the host by
> calling mipi_dsi_attach/detach/transfer which in turn call the callbacks
> in struct mipi_dsi_host_ops
> - for this to work, struct mipi_dsi_device has a pointer to the host:
> this is OK because the goal is supporting hotplug of the "remote"
> part of the DRM pipeline
> * the host accesses directly the fields of struct mipi_dsi_device, to
> which it receives a pointer in the .attach and .detach callbacks
>
> The second bullet is the problematic one, which we want to remove.
>
> Strategy
> ========
>
> I devised two possible strategies to address it:
>
> 1. change the host ops to not pass a struct mipi_dsi_device, but instead
> to pass only a copy of the needed information (bus format mainly), so
> the host driver does never access any info from the device
>
> 2. let the host get info from the device as needed, but without having a
> pointer to it; this is be based on:
> - storing a __private mipi_dsi_device pointer in struct mipi_dsi_host
> - adding getters to the DSI core for the host to query the needed
> info, e.g. drm_mipi_dsi_host_get_device_lanes(host) (the getters
> would be allowed to dereference the device pointer)
>
> This series implements strategy 1. It does so by adding a .attach_new host
> op, which does not take a mipi_dsi_device pointer, and converting most host
> drivers to it. Once all drivers are converted, the old op can be removed,
> and .attach_new renamed to .attach.
I don't recall discussing this particular aspect at Plumbers, so sorry
if we're coming back to the same discussion we had.
I'm not necessarily opposed to changing the MIPI-DSI bus API, but I
don't think changing the semantics to remove the fact that a particular
device is connected or not is a good idea.
I would have expected to have bus driver (maybe) take a device pointer
at attach, and drop it at detach.
Then, when we detect the hotplug of a DSI device, we detach it from its
parent, and we're done.
What prevents us from using that approach?
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <mripard@kernel.org>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Inki Dae <inki.dae@samsung.com>,
Jagan Teki <jagan@amarulasolutions.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Hui Pu <Hui.Pu@gehealthcare.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-sunxi@lists.linux.dev, Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices
Date: Mon, 7 Jul 2025 08:16:49 +0200 [thread overview]
Message-ID: <20250707-strange-warm-bear-cb4ee8@houat> (raw)
In-Reply-To: <20250625-drm-dsi-host-no-device-ptr-v1-0-e36bc258a7c5@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5009 bytes --]
Hi Luca,
On Wed, Jun 25, 2025 at 06:45:04PM +0200, Luca Ceresoli wrote:
> This series is the first attempt at avoiding DSI host drivers to have
> pointers to DSI devices (struct mipi_dsi_device), as discussed during the
> Linux Plumbers Conference 2024 with Maxime and Dmitry.
>
> It is working, but I consider this a draft in order to discuss and
> challenge the proposed approach.
>
> Overall work
> ============
>
> This is part of the work towards removal of bridges from a still existing
> DRM pipeline without use-after-free. The grand plan as discussed in [1].
> Here's the work breakdown (➜ marks the current series):
>
> 1. … add refcounting to DRM bridges (struct drm_bridge)
> (based on devm_drm_bridge_alloc() [0])
> A. ✔ add new alloc API and refcounting (in v6.16-rc1)
> B. ✔ convert all bridge drivers to new API (now in drm-misc-next)
> C. ✔ kunit tests (now in drm-misc-next)
> D. … add get/put to drm_bridge_add/remove() + attach/detach()
> and warn on old allocation pattern (under review)
> E. … add get/put on drm_bridge accessors
> 1. … drm_bridge_chain_get_first_bridge() + add a cleanup action
> 2. … drm_bridge_chain_get_last_bridge()
> 3. drm_bridge_get_prev_bridge()
> 4. drm_bridge_get_next_bridge()
> 5. drm_for_each_bridge_in_chain()
> 6. drm_bridge_connector_init
> 7. of_drm_find_bridge
> 8. drm_of_find_panel_or_bridge, *_of_get_bridge
> F. debugfs improvements
> 2. handle gracefully atomic updates during bridge removal
> 3. ➜ avoid DSI host drivers to have dangling pointers to DSI devices
> (this series)
> 4. finish the hotplug bridge work, removing the "always-disconnected"
> connector, moving code to the core and potentially removing the
> hotplug-bridge itself (this needs to be clarified as points 1-3 are
> developed)
>
> [0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0cc6aadd7fc1e629b715ea3d1ba537ef2da95eec
> [1] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/t/#u
>
> Motivation
> ==========
>
> The motivation for this series is that with hot-pluggable hardware a DSI
> device can be disconnected from the DSI host at runtime, and later on
> reconnected, potentially with a different model having different bus
> parameters.
>
> DSI host drivers currently receive a struct mipi_dsi_device pointer in the
> attach callback and some store it permanently for later access to the bur
> format data (lanes, channel, pixel format etc). The stored pointer can
> become dangling if the device is removed, leading to a use-after-free.
>
> Currently the data exchange between DSI host and device happens primarily
> by two means:
>
> * the device requests attach, detach and message transfer to the host by
> calling mipi_dsi_attach/detach/transfer which in turn call the callbacks
> in struct mipi_dsi_host_ops
> - for this to work, struct mipi_dsi_device has a pointer to the host:
> this is OK because the goal is supporting hotplug of the "remote"
> part of the DRM pipeline
> * the host accesses directly the fields of struct mipi_dsi_device, to
> which it receives a pointer in the .attach and .detach callbacks
>
> The second bullet is the problematic one, which we want to remove.
>
> Strategy
> ========
>
> I devised two possible strategies to address it:
>
> 1. change the host ops to not pass a struct mipi_dsi_device, but instead
> to pass only a copy of the needed information (bus format mainly), so
> the host driver does never access any info from the device
>
> 2. let the host get info from the device as needed, but without having a
> pointer to it; this is be based on:
> - storing a __private mipi_dsi_device pointer in struct mipi_dsi_host
> - adding getters to the DSI core for the host to query the needed
> info, e.g. drm_mipi_dsi_host_get_device_lanes(host) (the getters
> would be allowed to dereference the device pointer)
>
> This series implements strategy 1. It does so by adding a .attach_new host
> op, which does not take a mipi_dsi_device pointer, and converting most host
> drivers to it. Once all drivers are converted, the old op can be removed,
> and .attach_new renamed to .attach.
I don't recall discussing this particular aspect at Plumbers, so sorry
if we're coming back to the same discussion we had.
I'm not necessarily opposed to changing the MIPI-DSI bus API, but I
don't think changing the semantics to remove the fact that a particular
device is connected or not is a good idea.
I would have expected to have bus driver (maybe) take a device pointer
at attach, and drop it at detach.
Then, when we detect the hotplug of a DSI device, we detach it from its
parent, and we're done.
What prevents us from using that approach?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
next prev parent reply other threads:[~2025-07-07 6:23 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 16:45 [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices Luca Ceresoli
2025-06-25 16:45 ` Luca Ceresoli
2025-06-25 16:45 ` [PATCH 01/32] drm/mipi-dsi: add sanity check of lane number in mipi_dsi_attach() Luca Ceresoli
2025-06-25 16:45 ` [PATCH 02/32] drm/hisilicon/kirin: remove redundant lanes number check Luca Ceresoli
2025-06-25 16:45 ` [PATCH 03/32] drm/bridge: nwl-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 04/32] drm/mcde: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 05/32] drm/mipi-dsi: log DSI device attach and detach Luca Ceresoli
2025-06-25 16:45 ` [PATCH 06/32] drm/bridge: samsung-dsim: remove redundant logging Luca Ceresoli
2025-06-25 16:45 ` [PATCH 07/32] drm/bridge: nwl-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 08/32] drm/bridge: cdns-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 09/32] drm/mcde: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 10/32] drm/sun4i: dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 11/32] drm/bridge: synopsys/dsi2: remove DSI device pointer from private callbacks Luca Ceresoli
2025-06-25 16:45 ` [PATCH RFC 12/32] drm/meson: dsi: remove unneeded DSI device check Luca Ceresoli
2025-06-25 16:45 ` Luca Ceresoli
2025-06-25 16:45 ` [PATCH 13/32] drm/mipi-dsi: move format define above Luca Ceresoli
2025-06-25 16:45 ` [PATCH 14/32] drm/mipi-dsi: add .attach_new to mipi_dsi_host_ops Luca Ceresoli
2025-06-25 16:45 ` [PATCH 15/32] drm: adp: mipi: convert to the .attach_new op Luca Ceresoli
2025-06-25 16:45 ` [PATCH 16/32] drm/kmb: dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 17/32] drm/i915/dsi: " Luca Ceresoli
2025-06-25 18:42 ` Jani Nikula
2025-06-25 16:45 ` [PATCH 18/32] drm/hisilicon/kirin: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 19/32] drm/bridge: synopsys/dsi2: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 20/32] drm/msm/dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 21/32] drm/rcar-du: dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 22/32] drm: renesas: rz-du: rzg2l_mipi_dsi: " Luca Ceresoli
2025-06-26 23:42 ` kernel test robot
2025-06-25 16:45 ` [PATCH 23/32] drm/vc4: dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 24/32] drm/mediatek: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 25/32] drm/bridge: nwl-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 26/32] drm/bridge: cdns-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 27/32] drm/bridge: tc358768: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 28/32] drm/sprd: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 29/32] drm/bridge: synopsys: dw-mipi-dsi: " Luca Ceresoli
2025-06-25 16:45 ` [PATCH 30/32] drm/mcde: store a pointer to mipi_dsi_host to perform TE requests Luca Ceresoli
2025-06-25 16:45 ` [PATCH 31/32] drm/mcde: use the DSI host pointer in mcde_dsi_irq Luca Ceresoli
2025-06-25 16:45 ` [PATCH 32/32] drm/mcde: convert to the .attach_new op Luca Ceresoli
2025-07-07 6:16 ` Maxime Ripard [this message]
2025-07-07 6:16 ` [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices Maxime Ripard
2025-07-07 9:58 ` Luca Ceresoli
2025-07-07 9:58 ` Luca Ceresoli
2025-07-07 10:13 ` Luca Ceresoli
2025-07-07 10:13 ` Luca Ceresoli
2025-07-14 15:28 ` Luca Ceresoli
2025-07-14 15:28 ` Luca Ceresoli
2025-07-25 15:22 ` Maxime Ripard
2025-07-25 15:22 ` Maxime Ripard
2025-07-25 15:32 ` Luca Ceresoli
2025-07-25 15:32 ` Luca Ceresoli
2025-07-25 15:17 ` Maxime Ripard
2025-07-25 15:17 ` Maxime Ripard
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=20250707-strange-warm-bear-cb4ee8@houat \
--to=mripard@kernel.org \
--cc=Hui.Pu@gehealthcare.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=jagan@amarulasolutions.com \
--cc=jani.nikula@linux.intel.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=luca.ceresoli@bootlin.com \
--cc=lumag@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.petazzoni@bootlin.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.