From: Jani Nikula <jani.nikula@linux.intel.com>
To: Jonathan Cavitt <jonathan.cavitt@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: alex.zuo@intel.com, jonathan.cavitt@intel.com,
ville.syrjala@linux.intel.com
Subject: Re: [PATCH v3] drm/i915/display: Check some INVALID_TRANSCODER cases
Date: Mon, 17 Aug 2026 18:39:13 +0300 [thread overview]
Message-ID: <a44cf38460b6c7f26cd00624b3a9a96b7b896f4e@intel.com> (raw)
In-Reply-To: <20260817145838.252365-1-jonathan.cavitt@intel.com>
On Mon, 17 Aug 2026, Jonathan Cavitt <jonathan.cavitt@intel.com> wrote:
> There are some cases in intel_ddi.c, such as in intel_ddi_is_audio_enabled
> and intel_ddi_compute_config_late, where we attempt to perform a BIT
> shift using a passed transcoder enum value. This value may be -1,
> INVALID_TRANSCODER, which can result in undefined behavior if this
> occurs.
>
> In the former case, we can simply return false if this is the transcoder
> passed (as audio is not enabled on an invalid transcoder).
>
> In the latter case, the likely expected behavior is to set the
> crtc_state->sync_mode_slaves_mask to zero, so just do that directly and
> avoid a risky bit shift.
>
> The likelihood of either case occurring during normal execution is
> unknown and possibly very low. Regardless, this covers a static analyis
> issue.
>
> v2: Rewrite the latter case to streamline it (Ville)
>
> v3: Target cpu_transcoder in intel_ddi_compute_config_late change (Jani)
>
> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9b3b526e5e55..2bfbb6297b5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3893,7 +3893,8 @@ static void intel_ddi_set_idle_link_train(struct intel_dp *intel_dp,
> static bool intel_ddi_is_audio_enabled(struct intel_display *display,
> enum transcoder cpu_transcoder)
> {
> - if (cpu_transcoder == TRANSCODER_EDP)
> + if (cpu_transcoder == TRANSCODER_EDP ||
> + cpu_transcoder == INVALID_TRANSCODER)
> return false;
>
> if (!intel_display_power_is_enabled(display, POWER_DOMAIN_AUDIO_MMIO))
> @@ -4679,6 +4680,10 @@ static int intel_ddi_compute_config_late(struct intel_atomic_state *state,
>
> if (crtc_state->master_transcoder == crtc_state->cpu_transcoder) {
> crtc_state->master_transcoder = INVALID_TRANSCODER;
> + if (crtc_state->cpu_transcoder == INVALID_TRANSCODER) {
> + crtc_state->sync_mode_slaves_mask = 0;
> + return 0;
> + }
> crtc_state->sync_mode_slaves_mask = port_sync_transcoders &
> ~REG_BIT(crtc_state->cpu_transcoder);
What I dislike about this is the crtc_state->cpu_transcoder being
INVALID_TRANSCODER now looks like a normal state of things, which it
isn't.
Adding checks for it reinforces the idea that you should check for it
everywhere. Which you shouldn't.
In the code path being checked, crtc_state->master_transcoder also ends
up being INVALID_TRANSCODER by coincidence, through a ffs(0) - 1
computation. We should never end up with INVALID_TRANSCODER as a result
of a computation like that. It should always be explicit
INVALID_TRANSCODER through other checks, i.e. port_sync_transcoders
being 0 in this case.
BR,
Jani.
> }
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-08-17 15:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 14:58 [PATCH v3] drm/i915/display: Check some INVALID_TRANSCODER cases Jonathan Cavitt
2026-08-17 15:39 ` Jani Nikula [this message]
2026-08-17 16:04 ` ✓ i915.CI.BAT: success for drm/i915/display: Check some INVALID_TRANSCODER cases (rev3) Patchwork
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=a44cf38460b6c7f26cd00624b3a9a96b7b896f4e@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=alex.zuo@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=ville.syrjala@linux.intel.com \
/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.