From: sashiko-bot@kernel.org
To: "Svyatoslav Ryhel" <clamor95@gmail.com>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v4 5/7] drm/tegra: rgb: Parameterize configuration based on bus flags
Date: Thu, 22 Oct 2026 13:41:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-181560@kernel.org> (raw)
In-Reply-To: <20261022132259.240717-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/tegra: unlocked bridge state access in tegra_rgb_encoder_enable()
--
commit 743a0ce150c28976e990ee80b4eaf7239b83fcc3
Author: Svyatoslav Ryhel <clamor95@gmail.com>
drm/tegra: rgb: Parameterize configuration based on bus flags
This commit updates tegra_rgb_encoder_enable() to configure pixel clock
polarity, display enable polarity, and data alignment in the Tegra display
controller registers using bus flags retrieved from the attached bridge state.
> diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
> index b6d09a8d8e5ea..da9e37fe36689 100644
> --- a/drivers/gpu/drm/tegra/rgb.c
> +++ b/drivers/gpu/drm/tegra/rgb.c
[ ... ]
> @@ -104,14 +105,24 @@ static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
> struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> struct tegra_output *output = encoder_to_output(encoder);
> struct tegra_rgb *rgb = to_rgb(output);
> - u32 value;
> + struct drm_bridge_state *bridge_state;
> + u32 bus_flags, value;
> +
> + /* Get but flags from the bridge state. */
> + bridge_state = drm_bridge_get_current_state(output->bridge);
> + if (bridge_state)
> + bus_flags = bridge_state->input_bus_cfg.flags;
> + else
> + bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> + DRM_BUS_FLAG_DE_HIGH |
> + DRM_BUS_FLAG_DATA_MSB_TO_LSB;
[Severity: High]
Does calling drm_bridge_get_current_state(output->bridge) from
tegra_rgb_encoder_enable() in drivers/gpu/drm/tegra/rgb.c access the bridge
state without holding output->bridge->base.lock?
Looking at drm_bridge_get_current_state(), it asserts that bridge->base.lock
is held before reading bridge->base.state:
include/drm/drm_bridge.h:drm_bridge_get_current_state() {
if (!bridge)
return NULL;
drm_modeset_lock_assert_held(&bridge->base.lock);
if (!bridge->base.state)
return NULL;
return drm_priv_to_bridge_state(bridge->base.state);
}
There appear to be two paths where output->bridge->base.lock is not held when
tegra_rgb_encoder_enable() runs:
1. Non-blocking atomic modeset commits (DRM_IOCTL_MODE_ATOMIC with
DRM_MODE_ATOMIC_NONBLOCK | DRM_MODE_ATOMIC_ALLOW_MODESET):
tegra_drm_mode_config_funcs.atomic_commit uses drm_atomic_helper_commit() in
drivers/gpu/drm/drm_atomic_helper.c, which swaps state via
drm_atomic_helper_swap_state() and schedules state->commit_work onto
system_dfl_wq, after which drm_mode_atomic_ioctl() in
drivers/gpu/drm/drm_atomic_uapi.c immediately drops all acquired modeset
locks:
drivers/gpu/drm/drm_atomic_helper.c:drm_atomic_helper_commit() {
...
drm_atomic_commit_get(state);
if (nonblock)
queue_work(system_dfl_wq, &state->commit_work);
else
commit_tail(state, false);
...
}
drivers/gpu/drm/drm_atomic_uapi.c:drm_mode_atomic_ioctl() {
...
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
...
}
When the system_dfl_wq worker executes
commit_tail() -> tegra_atomic_commit_tail() ->
drm_atomic_helper_commit_modeset_enables() ->
drm_atomic_helper_commit_encoder_bridge_enable() ->
tegra_rgb_encoder_enable(), no drm_modeset_lock is held by the worker thread.
2. Bridges without .atomic_duplicate_state during synchronous modeset commits:
drm_bridge_attach() always initializes bridge->base.lock via
drm_atomic_private_obj_init(), but drm_atomic_add_encoder_bridges() skips
acquiring bridge->base.lock when the bridge does not implement
.atomic_duplicate_state:
drivers/gpu/drm/drm_atomic.c:drm_atomic_add_encoder_bridges() {
...
drm_for_each_bridge_in_chain(encoder, bridge) {
/* Skip bridges that don't implement the atomic state hooks. */
if (!bridge->funcs->atomic_duplicate_state)
continue;
bridge_state = drm_atomic_get_bridge_state(state, bridge);
...
}
In both cases, calling drm_bridge_get_current_state(output->bridge) triggers a
lockdep warning on drm_modeset_lock_assert_held(&bridge->base.lock) under
CONFIG_PROVE_LOCKING and reads output->bridge->base.state without holding
bridge->base.lock.
Should tegra_rgb_encoder_helper_funcs implement .atomic_enable() instead of
.enable() and look up the bridge state from the atomic state via
drm_atomic_get_new_bridge_state(state, output->bridge)?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261022132259.240717-1-clamor95@gmail.com?part=5
next prev parent reply other threads:[~2026-10-22 13:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 13:22 [PATCH v4 0/7] drm/tegra: Add support for Tegra20/Tegra30 8-bit CPU interface Svyatoslav Ryhel
2026-10-22 13:22 ` [PATCH v4 1/7] dt-bindings: display: panel: Document Hitachi TX10D07VM0BAA and LG LH400WV3 panels Svyatoslav Ryhel
2026-10-22 13:22 ` [PATCH v4 2/7] drm/panel: Add Hitachi TX10D07VM0BAA MIPI DBI Type B panel driver Svyatoslav Ryhel
2026-10-22 13:39 ` sashiko-bot
2026-10-22 13:22 ` [PATCH v4 3/7] drm/panel: Add LG LH400WV3-SD04 " Svyatoslav Ryhel
2026-10-22 13:22 ` [PATCH v4 4/7] drm/tegra: dc: Expand available registers layouts Svyatoslav Ryhel
2026-10-23 7:14 ` Mikko Perttunen
2026-10-23 8:06 ` Svyatoslav Ryhel
2026-10-22 13:22 ` [PATCH v4 5/7] drm/tegra: rgb: Parameterize configuration based on bus flags Svyatoslav Ryhel
2026-10-22 13:41 ` sashiko-bot [this message]
2026-10-22 13:22 ` [PATCH v4 6/7] dt-bindings: display: tegra: Document 8-bit CPU parallel interface Svyatoslav Ryhel
2026-10-22 13:47 ` sashiko-bot
2026-10-22 13:22 ` [PATCH v4 7/7] drm/tegra: Add support for 8-bit CPU interface Svyatoslav Ryhel
2026-10-22 13:53 ` sashiko-bot
2026-10-23 7:53 ` Mikko Perttunen
2026-10-23 8:26 ` Svyatoslav Ryhel
2026-10-23 14:14 ` Svyatoslav Ryhel
2026-10-25 1:42 ` Mikko Perttunen
2026-10-25 8:51 ` Svyatoslav Ryhel
2026-10-28 1:35 ` Mikko Perttunen
2026-10-28 12:46 ` Svyatoslav Ryhel
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=sashiko-outbox-181560@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=clamor95@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robh@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 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.