From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v2 1/2] drm/i915/display: Use explicit cast in POWER_DOMAIN_*() macros
Date: Wed, 12 Feb 2025 20:55:59 +0200 [thread overview]
Message-ID: <Z6zuv5ZIQrut0Uf5@intel.com> (raw)
In-Reply-To: <173938586622.145254.18264992862975057866@intel.com>
On Wed, Feb 12, 2025 at 03:44:26PM -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2025-02-12 14:59:28-03:00)
> >Quoting Ville Syrjälä (2025-02-12 14:52:19-03:00)
> >>On Wed, Feb 12, 2025 at 02:43:16PM -0300, Gustavo Sousa wrote:
> >>> Let the compiler know that we are intetionally using a different enum
> >>> type to perform arithmetic with enum intel_display_power_domain in the
> >>> POWER_DOMAIN_*(). Do that by explicitly casting the macro argument to
> >>> int.
> >>>
> >>> Reported-by: kernel test robot <lkp@intel.com>
> >>> Closes: https://lore.kernel.org/oe-kbuild-all/202502120809.XfmcqkBD-lkp@intel.com/
> >>> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_display_power.h | 6 +++---
> >>> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h b/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> index a3a5c1be8bab..3caa3f517a32 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> >>> @@ -117,12 +117,12 @@ enum intel_display_power_domain {
> >>> POWER_DOMAIN_INVALID = POWER_DOMAIN_NUM,
> >>> };
> >>>
> >>> -#define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
> >>> +#define POWER_DOMAIN_PIPE(pipe) ((int)(pipe) + POWER_DOMAIN_PIPE_A)
> >>> #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
> >>> - ((pipe) + POWER_DOMAIN_PIPE_PANEL_FITTER_A)
> >>> + ((int)(pipe) + POWER_DOMAIN_PIPE_PANEL_FITTER_A)
> >>> #define POWER_DOMAIN_TRANSCODER(tran) \
> >>> ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
> >>> - (tran) + POWER_DOMAIN_TRANSCODER_A)
> >>> + (int)(tran) + POWER_DOMAIN_TRANSCODER_A)
> >>
> >>I've generally gone for the
> >>POWER_DOMAIN_TRANSCODER_A + (tran) - TRANSCODER_A
> >>form for such things, to also make sure it works
> >>even if TRANSCODER_A isn't 0 anymore.
> >>Does that avoid the warning as well?
> >
> >Hm... That's a good idea; and I think it might avoid the warning indeed
> >(maybe we would need parentheses around (tran) - TRANSCODER_A).
>
> I did a quick test and this also took care of removing the clang warning
> in my environment:
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h b/drivers/gpu/drm/i915/display/intel_display_power.h
> index e354051e8982..d46b35dbe018 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -123,7 +123,7 @@ enum intel_display_power_domain {
> ((enum intel_display_power_domain)((int)(pipe) + POWER_DOMAIN_PIPE_PANEL_FITTER_A))
> #define POWER_DOMAIN_TRANSCODER(tran) \
> ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
> - (enum intel_display_power_domain)((int)(tran) + POWER_DOMAIN_TRANSCODER_A))
> + (enum intel_display_power_domain)(POWER_DOMAIN_TRANSCODER_A + ((tran) - TRANSCODER_A)))
>
> struct intel_power_domain_mask {
> DECLARE_BITMAP(bits, POWER_DOMAIN_NUM);
>
> The parentheses around (tran) - TRANSCODER_A were indeed necessary,
> probably for the compiler to see that as an int expression.
>
> We can get rid of the parentheses if we do (tran) - TRANSCODER_A before
> adding POWER_DOMAIN_TRANSCODER_A:
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h b/drivers/gpu/drm/i915/display/intel_display_power.h
> index e354051e8982..b15eb4fd5062 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -123,7 +123,7 @@ enum intel_display_power_domain {
> ((enum intel_display_power_domain)((int)(pipe) + POWER_DOMAIN_PIPE_PANEL_FITTER_A))
> #define POWER_DOMAIN_TRANSCODER(tran) \
> ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
> - (enum intel_display_power_domain)((int)(tran) + POWER_DOMAIN_TRANSCODER_A))
> + (enum intel_display_power_domain)((tran) - TRANSCODER_A + POWER_DOMAIN_TRANSCODER_A))
Looks reasoanble enough to me. Do we still need the final cast?
>
> struct intel_power_domain_mask {
> DECLARE_BITMAP(bits, POWER_DOMAIN_NUM);
>
> I'm tending more toward the second alternative.
>
> --
> Gustavo Sousa
>
> >
> >>
> >>Maybe these should even be functions rather than macros?
> >
> >Yeah. I actually considered this possibility, but went with the macros
> >to keep the change simple.
> >
> >If that's welcome, I could go ahead with turning those macros into
> >static inline functions.
> >
> >--
> >Gustavo Sousa
> >
> >>
> >>>
> >>> struct intel_power_domain_mask {
> >>> DECLARE_BITMAP(bits, POWER_DOMAIN_NUM);
> >>> --
> >>> 2.48.1
> >>
> >>--
> >>Ville Syrjälä
> >>Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-02-12 18:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 17:43 [PATCH v2 0/2] Improve type-safety on POWER_DOMAIN_*() macros Gustavo Sousa
2025-02-12 17:43 ` [PATCH v2 1/2] drm/i915/display: Use explicit cast in " Gustavo Sousa
2025-02-12 17:52 ` Ville Syrjälä
2025-02-12 17:59 ` Gustavo Sousa
2025-02-12 18:44 ` Gustavo Sousa
2025-02-12 18:55 ` Ville Syrjälä [this message]
2025-02-12 19:02 ` Gustavo Sousa
2025-02-12 17:43 ` [PATCH v2 2/2] drm/i915/display: Make POWER_DOMAIN_*() always result in enum intel_display_power_domain Gustavo Sousa
2025-02-12 21:26 ` ✓ CI.Patch_applied: success for Improve type-safety on POWER_DOMAIN_*() macros (rev2) Patchwork
2025-02-12 21:26 ` ✓ CI.checkpatch: " Patchwork
2025-02-12 21:27 ` ✓ CI.KUnit: " Patchwork
2025-02-12 21:44 ` ✓ CI.Build: " Patchwork
2025-02-12 21:46 ` ✓ CI.Hooks: " Patchwork
2025-02-12 21:48 ` ✓ CI.checksparse: " Patchwork
2025-02-12 22:07 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-12 23:28 ` ✗ Fi.CI.SPARSE: warning " Patchwork
2025-02-12 23:45 ` ✗ i915.CI.BAT: failure " Patchwork
2025-02-13 7:46 ` ✗ Xe.CI.Full: " 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=Z6zuv5ZIQrut0Uf5@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=gustavo.sousa@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@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.