Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Maxime Ripard" <mripard@kernel.org>
Cc: imx@lists.linux.dev, dri-devel@lists.freedesktop.org,
	Frank.Li@kernel.org
Subject: Re: [PATCH v2 19/78] drm/bridge: imx8qxp-pxl2dpi: Switch to atomic_create_state
Date: Mon, 08 Jun 2026 16:00:04 +0000	[thread overview]
Message-ID: <20260608160004.EC91C1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-19-0a91018bf886@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Global device state corruption in atomic_check.
--

commit e8d715f17c3f8417137a6f4c52d8a5d876a47307
Author: Maxime Ripard <mripard@kernel.org>

drm/bridge: imx8qxp-pxl2dpi: Switch to atomic_create_state

This commit replaces the deprecated atomic_reset callback and its helper
with the atomic_create_state callback and its counterpart.

> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index 87305d3e0c398..2fc9831f7e611 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -210,7 +210,7 @@ imx8qxp_pxl2dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>  static const struct drm_bridge_funcs imx8qxp_pxl2dpi_bridge_funcs = {
>  	.atomic_duplicate_state	= drm_atomic_helper_bridge_duplicate_state,
>  	.atomic_destroy_state	= drm_atomic_helper_bridge_destroy_state,
> -	.atomic_reset		= drm_atomic_helper_bridge_reset,
> +	.atomic_create_state		= drm_atomic_helper_bridge_create_state,
>  	.attach			= imx8qxp_pxl2dpi_bridge_attach,
>  	.destroy		= imx8qxp_pxl2dpi_bridge_destroy,
>  	.atomic_check		= imx8qxp_pxl2dpi_bridge_atomic_check,

[Severity: High]
This isn't a bug introduced by this patch, but does
imx8qxp_pxl2dpi_bridge_atomic_check() mutate global device state during the
atomic check phase?

In the DRM atomic framework, atomic_check can be executed for test-only
commits (DRM_MODE_ATOMIC_TEST_ONLY), which never proceed to the hardware
commit phase.

Looking at imx8qxp_pxl2dpi_bridge_atomic_check() in
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c:

    p2d->in_bus_format = bridge_state->input_bus_cfg.format;
    p2d->out_bus_format = bridge_state->output_bus_cfg.format;

For non-blocking commits, the commit tail executes in a background worker
without holding modeset locks. It then calls mode_set where this state is read:

drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c:imx8qxp_pxl2dpi_bridge_mode_set() {
    ...
    switch (p2d->out_bus_format) {
    ...
}

Can a concurrent test-only commit overwrite this global state while an
ongoing non-blocking commit is reading it, leading to the display hardware
being misconfigured with test-only bus formats?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-drm-no-more-bridge-reset-v2-0-0a91018bf886@kernel.org?part=19

  reply	other threads:[~2026-06-08 16:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08 14:35 [PATCH v2 00/78] drm/bridge: Convert all reset users to create_state Maxime Ripard
2026-06-08 14:35 ` [PATCH v2 14/78] drm/bridge: imx8mp-hdmi-pvi: Switch to atomic_create_state Maxime Ripard
2026-06-08 15:45   ` sashiko-bot
2026-06-09  6:47   ` Liu Ying
2026-06-08 14:35 ` [PATCH v2 15/78] drm/bridge: imx8qm-ldb: " Maxime Ripard
2026-06-09  6:51   ` Liu Ying
2026-06-08 14:35 ` [PATCH v2 16/78] drm/bridge: imx8qxp-ldb: " Maxime Ripard
2026-06-09  6:52   ` Liu Ying
2026-06-08 14:35 ` [PATCH v2 17/78] drm/bridge: imx8qxp-pixel-combiner: " Maxime Ripard
2026-06-08 15:55   ` sashiko-bot
2026-06-09  6:53   ` Liu Ying
2026-06-08 14:36 ` [PATCH v2 18/78] drm/bridge: imx8qxp-pixel-link: " Maxime Ripard
2026-06-09  6:54   ` Liu Ying
2026-06-08 14:36 ` [PATCH v2 19/78] drm/bridge: imx8qxp-pxl2dpi: " Maxime Ripard
2026-06-08 16:00   ` sashiko-bot [this message]
2026-06-09  6:54   ` Liu Ying
2026-06-08 14:36 ` [PATCH v2 47/78] drm/imx: parallel-display: " 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=20260608160004.EC91C1F00893@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=mripard@kernel.org \
    --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