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
next prev parent 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