Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
Cc: imx@lists.linux.dev, Frank.Li@kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC v2 16/24] drm/mipi-dsi: notify about DSI attach
Date: Thu, 01 Oct 2026 13:15:07 +0000	[thread overview]
Message-ID: <20261001131508.5F50F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001-drm-bridge-hotplug-v2-16-8e34986dcb68@bootlin.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm: commit message contradicts ATTACHED event semantics
--

commit 3106f1037d08f7d82066d0ccd2f170f5facd1bf0
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>

drm/mipi-dsi: notify about DSI attach

This commit introduces an event notification when a DSI device is attached to
its host. This is added in preparation for DRM bridge hotplug support.

>     In preparation to support DRM bridge hotplug, let the drm_mipi_dsi code
>     emit an event when a DSI device is attached to the corresponding DSI host,
>     so that this event can trigger the actions needed to deconfigure the
>     pipeline and unregister the connector as appropriate.

[Severity: Medium]
Does this commit message contradict the ATTACHED event semantics used in
mipi_dsi_attach() in drivers/gpu/drm/drm_mipi_dsi.c?

The commit message explicitly claims the DRM_MIPI_DSI_ATTACHED event is
intended to trigger actions to "deconfigure the pipeline and unregister the
connector". However, since this event is emitted when a device is attached,
shouldn't it be used to configure the pipeline and register the connector
(which is what the hotplug helper actually does)?

The teardown path is structurally safe because error unwinding (via devres)
calls drm_bridge_remove(), which detaches the bridge from the encoder and
emits DRM_BRIDGE_DETACHED. The hotplug helper correctly listens to
DRM_BRIDGE_DETACHED to unregister the connector, meaning the lifecycle is
perfectly symmetrical without needing a dedicated DRM_MIPI_DSI_DETACHED
event.

Could the commit message be updated to reflect that this event triggers
configuration and registration rather than deconfiguration and
unregistration?

> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 3ac1dd5ad640a..eaa474da4a519 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
[ ... ]
> @@ -386,6 +387,8 @@ int mipi_dsi_attach(struct mipi_dsi_device *dsi)
>  
>  	dsi->attached = true;
>  
> +	drm_event_notifier_notify(DRM_MIPI_DSI_ATTACHED, dsi);
> +
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001-drm-bridge-hotplug-v2-0-8e34986dcb68@bootlin.com?part=16

  reply	other threads:[~2026-10-01 13:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 12:42 [PATCH RFC v2 00/24] drm bridge hotplug Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 01/24] drm/connector: split drmm_connector_hdmi_init() in 3 parts Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 02/24] drm/connector: add drm_connector_hdmi_dynamic_init() Luca Ceresoli
2026-10-01 12:48   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 03/24] drm/display: bridge-connector: split code allocation from initialization Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 04/24] drm/display: bridge-connector: hoist error management to common code Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 05/24] drm/display: bridge-connector: use a dynamic connector Luca Ceresoli
2026-10-01 12:56   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 06/24] drm/display: bridge-connector: add APIs to add/remove the connector dynamically Luca Ceresoli
2026-10-01 12:56   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 07/24] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe Luca Ceresoli
2026-10-01 13:01   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 08/24] drm/bridge: initialize chain_node list head on allocation Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 09/24] drm/bridge: initialize chain_node list head on detach and attach errors Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 10/24] drm/encoder: add drm_encoder_cleanup_from() Luca Ceresoli
2026-10-01 13:05   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 11/24] drm/atomic: move drm_atomic_helper_disable_all() and drm_atomic_helper_shutdown() from drm_atomic_helper to drm_atomic Luca Ceresoli
2026-10-01 13:03   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 12/24] drm/bridge: shutdown and cleanup on bridge unplug Luca Ceresoli
2026-10-01 13:14   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 13/24] drm/mipi-dsi: turn DRM_MIPI_DSI into a tristate Luca Ceresoli
2026-10-01 13:17   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 14/24] drm: event-notifier: add mechanism to notify about hotplug events Luca Ceresoli
2026-10-01 13:12   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 15/24] drm/bridge: notify about detached bridges Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 16/24] drm/mipi-dsi: notify about DSI attach Luca Ceresoli
2026-10-01 13:15   ` sashiko-bot [this message]
2026-10-01 12:42 ` [PATCH RFC v2 17/24] drm/bridge: add drm_bridge_get_next() and supporting func Luca Ceresoli
2026-10-01 13:20   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 18/24] drm/panel: implement .get_next_bridge Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 19/24] drm/bridge: display-connector: " Luca Ceresoli
2026-10-01 12:42 ` [PATCH RFC v2 20/24] drm/bridge: ti-sn65dsi83: " Luca Ceresoli
2026-10-01 13:23   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 21/24] drm/bridge: ti-sn65dsi86: " Luca Ceresoli
2026-10-01 13:25   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 22/24] drm/bridge: samsung-dsim: " Luca Ceresoli
2026-10-01 13:27   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 23/24] drm: drm_hotplug_helper: new helper to implement bridge hotplug Luca Ceresoli
2026-10-01 13:31   ` sashiko-bot
2026-10-01 12:42 ` [PATCH RFC v2 24/24] drm/mxsfb/lcdif: enable " Luca Ceresoli
2026-10-01 13:31   ` 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=20261001131508.5F50F1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --cc=luca.ceresoli@bootlin.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox