All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-24 21:09 Gwan-gyeong Mun
  2022-10-25  1:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
                   ` (11 more replies)
  0 siblings, 12 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-24 21:09 UTC (permalink / raw)
  To: andi.shyti; +Cc: intel-gfx

If a non-constant variable is used as the first argument of the FIELD_PREP
macro, a build error occurs when using the clang compiler.

Fix the following build error used with clang compiler:

drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
        bits_to_set = FIELD_PREP(field_msk, nval);
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
                __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
                                    ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
        __compiletime_assert(condition, msg, prefix, suffix)
        ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
                if (!(condition))                                       \

Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
---
 drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e9781493025..782a621b1928 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
 
 static void
 hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-			  u32 field_msk, int nshift,
-			  unsigned int scale_factor, long lval)
+			  int nshift, unsigned int scale_factor, long lval)
 {
 	u32 nval;
-	u32 bits_to_clear;
-	u32 bits_to_set;
 
 	/* Computation in 64-bits to avoid overflow. Round to nearest. */
 	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
 
-	bits_to_clear = field_msk;
-	bits_to_set = FIELD_PREP(field_msk, nval);
-
 	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
-					    bits_to_clear, bits_to_set);
+					    PKG_PWR_LIM_1,
+					    FIELD_PREP(PKG_PWR_LIM_1, nval));
 }
 
 /*
@@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
 	case hwmon_power_max:
 		hwm_field_scale_and_write(ddat,
 					  hwmon->rg.pkg_rapl_limit,
-					  PKG_PWR_LIM_1,
 					  hwmon->scl_shift_power,
 					  SF_POWER, val);
 		return 0;
-- 
2.37.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
@ 2022-10-25  1:34 ` Patchwork
  2022-10-25  1:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-25  1:34 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler
URL   : https://patchwork.freedesktop.org/series/110094/
State : warning

== Summary ==

Error: dim checkpatch failed
be30883f7e71 drm/i915/hwmon: Fix a build error used with clang compiler
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#23: 
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

total: 0 errors, 1 warnings, 0 checks, 31 lines checked



^ permalink raw reply	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
  2022-10-25  1:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2022-10-25  1:57 ` Patchwork
  2022-10-25  3:14   ` [Intel-gfx] " Dixit, Ashutosh
                   ` (9 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-25  1:57 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 8618 bytes --]

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler
URL   : https://patchwork.freedesktop.org/series/110094/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12288 -> Patchwork_110094v1
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_110094v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110094v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/index.html

Participating hosts (41 -> 41)
------------------------------

  Additional (1): bat-atsm-1 
  Missing    (1): fi-ctg-p8600 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_110094v1:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@hugepages:
    - fi-cfl-8109u:       [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-cfl-8109u/igt@i915_selftest@live@hugepages.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-cfl-8109u/igt@i915_selftest@live@hugepages.html

  * igt@i915_suspend@basic-s3-without-i915:
    - fi-rkl-11600:       NOTRUN -> [INCOMPLETE][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@hugepages:
    - {fi-jsl-1}:         [PASS][4] -> [DMESG-FAIL][5]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-jsl-1/igt@i915_selftest@live@hugepages.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-jsl-1/igt@i915_selftest@live@hugepages.html

  
Known issues
------------

  Here are the changes found in Patchwork_110094v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_suspend@basic-s3-without-i915:
    - fi-kbl-x1275:       NOTRUN -> [SKIP][6] ([fdo#109271])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-kbl-x1275/igt@i915_suspend@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-hsw-4770:        NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-hsw-4770/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-kbl-x1275:       NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-kbl-x1275/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-adl-ddr5:        NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-adl-ddr5/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@runner@aborted:
    - fi-cfl-8109u:       NOTRUN -> [FAIL][10] ([i915#4312])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-cfl-8109u/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@gem_huc_copy@huc-copy:
    - {bat-dg2-8}:        [FAIL][11] ([i915#7029]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/bat-dg2-8/igt@gem_huc_copy@huc-copy.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/bat-dg2-8/igt@gem_huc_copy@huc-copy.html

  * igt@i915_pm_rpm@basic-rte:
    - {bat-rplp-1}:       [DMESG-WARN][13] -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/bat-rplp-1/igt@i915_pm_rpm@basic-rte.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/bat-rplp-1/igt@i915_pm_rpm@basic-rte.html

  * igt@i915_selftest@live@gt_lrc:
    - {fi-tgl-dsi}:       [INCOMPLETE][15] ([i915#6856] / [i915#7125]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@hangcheck:
    - fi-hsw-4770:        [INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html

  * igt@i915_selftest@live@hugepages:
    - fi-rkl-11600:       [DMESG-FAIL][19] -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-rkl-11600/igt@i915_selftest@live@hugepages.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-rkl-11600/igt@i915_selftest@live@hugepages.html
    - fi-kbl-x1275:       [DMESG-FAIL][21] -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-kbl-x1275/igt@i915_selftest@live@hugepages.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-kbl-x1275/igt@i915_selftest@live@hugepages.html
    - fi-adl-ddr5:        [DMESG-FAIL][23] -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-adl-ddr5/igt@i915_selftest@live@hugepages.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-adl-ddr5/igt@i915_selftest@live@hugepages.html
    - {fi-ehl-2}:         [DMESG-FAIL][25] -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/fi-ehl-2/igt@i915_selftest@live@hugepages.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/fi-ehl-2/igt@i915_selftest@live@hugepages.html
    - {bat-adlm-1}:       [DMESG-FAIL][27] -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/bat-adlm-1/igt@i915_selftest@live@hugepages.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/bat-adlm-1/igt@i915_selftest@live@hugepages.html

  * igt@i915_selftest@live@slpc:
    - {bat-rpls-1}:       [DMESG-FAIL][29] ([i915#6367]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/bat-rpls-1/igt@i915_selftest@live@slpc.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/bat-rpls-1/igt@i915_selftest@live@slpc.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#6856]: https://gitlab.freedesktop.org/drm/intel/issues/6856
  [i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
  [i915#7030]: https://gitlab.freedesktop.org/drm/intel/issues/7030
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125


Build changes
-------------

  * Linux: CI_DRM_12288 -> Patchwork_110094v1

  CI-20190529: 20190529
  CI_DRM_12288: 61a92db3f6785121281a51f95960a3282d47117d @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7025: f8b8e0713f87460a2c050ec8fe18fa487f98e228 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110094v1: 61a92db3f6785121281a51f95960a3282d47117d @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

979f07fa0832 drm/i915/hwmon: Fix a build error used with clang compiler

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v1/index.html

[-- Attachment #2: Type: text/html, Size: 9042 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
@ 2022-10-25  3:14   ` Dixit, Ashutosh
  2022-10-25  1:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
                     ` (10 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-25  3:14 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: andi.shyti, anshuman.gupta, intel-gfx, llvm

On Mon, 24 Oct 2022 14:09:53 -0700, Gwan-gyeong Mun wrote:
>

Hi GG,

> If a non-constant variable is used as the first argument of the FIELD_PREP
> macro, a build error occurs when using the clang compiler.
>
> Fix the following build error used with clang compiler:
>
> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]

What is 18446744073709551615? You may want to limit the length of this line
or checkpatch doesn't complain?

>         bits_to_set = FIELD_PREP(field_msk, nval);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>         __compiletime_assert(condition, msg, prefix, suffix)
>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>                 if (!(condition))                                       \
>
> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..782a621b1928 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>
>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> -
>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    FIELD_PREP(PKG_PWR_LIM_1, nval));

I don't want to give up so easily. We might have future uses for the
function where we want field_msk to be passed into the function (rather
than set inside the function as in this patch).

Do we understand what clang is complaining about? And why this compiles
with gcc?

Copying llvm@lists.linux.dev too.

Thanks.
--
Ashutosh


>  }
>
>  /*
> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>	case hwmon_power_max:
>		hwm_field_scale_and_write(ddat,
>					  hwmon->rg.pkg_rapl_limit,
> -					  PKG_PWR_LIM_1,
>					  hwmon->scl_shift_power,
>					  SF_POWER, val);
>		return 0;
> --
> 2.37.1
>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-25  3:14   ` Dixit, Ashutosh
  0 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-25  3:14 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx, llvm

On Mon, 24 Oct 2022 14:09:53 -0700, Gwan-gyeong Mun wrote:
>

Hi GG,

> If a non-constant variable is used as the first argument of the FIELD_PREP
> macro, a build error occurs when using the clang compiler.
>
> Fix the following build error used with clang compiler:
>
> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]

What is 18446744073709551615? You may want to limit the length of this line
or checkpatch doesn't complain?

>         bits_to_set = FIELD_PREP(field_msk, nval);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>         __compiletime_assert(condition, msg, prefix, suffix)
>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>                 if (!(condition))                                       \
>
> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..782a621b1928 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>
>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> -
>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    FIELD_PREP(PKG_PWR_LIM_1, nval));

I don't want to give up so easily. We might have future uses for the
function where we want field_msk to be passed into the function (rather
than set inside the function as in this patch).

Do we understand what clang is complaining about? And why this compiles
with gcc?

Copying llvm@lists.linux.dev too.

Thanks.
--
Ashutosh


>  }
>
>  /*
> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>	case hwmon_power_max:
>		hwm_field_scale_and_write(ddat,
>					  hwmon->rg.pkg_rapl_limit,
> -					  PKG_PWR_LIM_1,
>					  hwmon->scl_shift_power,
>					  SF_POWER, val);
>		return 0;
> --
> 2.37.1
>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (2 preceding siblings ...)
  2022-10-25  3:14   ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-25  9:15 ` Andi Shyti
  2022-10-25 14:27 ` Jani Nikula
                   ` (7 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Andi Shyti @ 2022-10-25  9:15 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

On Tue, Oct 25, 2022 at 12:09:53AM +0300, Gwan-gyeong Mun wrote:
> If a non-constant variable is used as the first argument of the FIELD_PREP
> macro, a build error occurs when using the clang compiler.

good catch! FIELD_PREP wants indeed a constant as a first
paramenter, also for gcc.

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

> Fix the following build error used with clang compiler:
> 
> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>         bits_to_set = FIELD_PREP(field_msk, nval);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>         __compiletime_assert(condition, msg, prefix, suffix)
>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>                 if (!(condition))                                       \
> 
> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..782a621b1928 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>  
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>  	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>  
>  	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>  	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>  
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> -
>  	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
>  }
>  
>  /*
> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>  	case hwmon_power_max:
>  		hwm_field_scale_and_write(ddat,
>  					  hwmon->rg.pkg_rapl_limit,
> -					  PKG_PWR_LIM_1,
>  					  hwmon->scl_shift_power,
>  					  SF_POWER, val);
>  		return 0;
> -- 
> 2.37.1

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25  3:14   ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-25  9:25     ` Andi Shyti
  -1 siblings, 0 replies; 47+ messages in thread
From: Andi Shyti @ 2022-10-25  9:25 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: intel-gfx, llvm

Hi Ashutosh,

> > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> 
> What is 18446744073709551615? You may want to limit the length of this line
> or checkpatch doesn't complain?

yeah! I am not a clang user, and this must be some ugly error
output. I don't think it makes sense to break it, though.

> >         bits_to_set = FIELD_PREP(field_msk, nval);
> >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> >         __compiletime_assert(condition, msg, prefix, suffix)
> >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> >                 if (!(condition))                                       \
> >
> > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 9e9781493025..782a621b1928 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >
> >  static void
> >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > -			  u32 field_msk, int nshift,
> > -			  unsigned int scale_factor, long lval)
> > +			  int nshift, unsigned int scale_factor, long lval)
> >  {
> >	u32 nval;
> > -	u32 bits_to_clear;
> > -	u32 bits_to_set;
> >
> >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >
> > -	bits_to_clear = field_msk;
> > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > -
> >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > -					    bits_to_clear, bits_to_set);
> > +					    PKG_PWR_LIM_1,
> > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> 
> I don't want to give up so easily. We might have future uses for the
> function where we want field_msk to be passed into the function (rather
> than set inside the function as in this patch).
> 
> Do we understand what clang is complaining about? And why this compiles
> with gcc?

Because we are not compiling the builtin functions with gcc but
gcc has support for them. The FIELD_PREP checks if the first
parameter is a constant:

	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),

where _mask was our field_mask, but we ignore it. Apparently
clang doesn't.

If we want to stick to gcc only, then I still think the patch is
correct for two reasons:

  1. it's cleaner
  2. we would get on with the job and if one day we will decide
     to suppport builtin functions in gcc as well, we will sleep
     peacefully :)

> Copying llvm@lists.linux.dev too.

maybe llvm folks have a better opinion.

Thanks,
Andi

> Thanks.
> --
> Ashutosh
> 
> 
> >  }
> >
> >  /*
> > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> >	case hwmon_power_max:
> >		hwm_field_scale_and_write(ddat,
> >					  hwmon->rg.pkg_rapl_limit,
> > -					  PKG_PWR_LIM_1,
> >					  hwmon->scl_shift_power,
> >					  SF_POWER, val);
> >		return 0;
> > --
> > 2.37.1
> >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-25  9:25     ` Andi Shyti
  0 siblings, 0 replies; 47+ messages in thread
From: Andi Shyti @ 2022-10-25  9:25 UTC (permalink / raw)
  To: Dixit, Ashutosh
  Cc: Gwan-gyeong Mun, andi.shyti, anshuman.gupta, intel-gfx, llvm

Hi Ashutosh,

> > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> 
> What is 18446744073709551615? You may want to limit the length of this line
> or checkpatch doesn't complain?

yeah! I am not a clang user, and this must be some ugly error
output. I don't think it makes sense to break it, though.

> >         bits_to_set = FIELD_PREP(field_msk, nval);
> >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> >         __compiletime_assert(condition, msg, prefix, suffix)
> >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> >                 if (!(condition))                                       \
> >
> > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 9e9781493025..782a621b1928 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >
> >  static void
> >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > -			  u32 field_msk, int nshift,
> > -			  unsigned int scale_factor, long lval)
> > +			  int nshift, unsigned int scale_factor, long lval)
> >  {
> >	u32 nval;
> > -	u32 bits_to_clear;
> > -	u32 bits_to_set;
> >
> >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >
> > -	bits_to_clear = field_msk;
> > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > -
> >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > -					    bits_to_clear, bits_to_set);
> > +					    PKG_PWR_LIM_1,
> > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> 
> I don't want to give up so easily. We might have future uses for the
> function where we want field_msk to be passed into the function (rather
> than set inside the function as in this patch).
> 
> Do we understand what clang is complaining about? And why this compiles
> with gcc?

Because we are not compiling the builtin functions with gcc but
gcc has support for them. The FIELD_PREP checks if the first
parameter is a constant:

	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),

where _mask was our field_mask, but we ignore it. Apparently
clang doesn't.

If we want to stick to gcc only, then I still think the patch is
correct for two reasons:

  1. it's cleaner
  2. we would get on with the job and if one day we will decide
     to suppport builtin functions in gcc as well, we will sleep
     peacefully :)

> Copying llvm@lists.linux.dev too.

maybe llvm folks have a better opinion.

Thanks,
Andi

> Thanks.
> --
> Ashutosh
> 
> 
> >  }
> >
> >  /*
> > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> >	case hwmon_power_max:
> >		hwm_field_scale_and_write(ddat,
> >					  hwmon->rg.pkg_rapl_limit,
> > -					  PKG_PWR_LIM_1,
> >					  hwmon->scl_shift_power,
> >					  SF_POWER, val);
> >		return 0;
> > --
> > 2.37.1
> >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (3 preceding siblings ...)
  2022-10-25  9:15 ` Andi Shyti
@ 2022-10-25 14:27 ` Jani Nikula
  2022-10-25 14:30   ` Jani Nikula
  2022-10-27 17:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2) Patchwork
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 47+ messages in thread
From: Jani Nikula @ 2022-10-25 14:27 UTC (permalink / raw)
  To: Gwan-gyeong Mun, andi.shyti; +Cc: intel-gfx

On Tue, 25 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
> If a non-constant variable is used as the first argument of the FIELD_PREP
> macro, a build error occurs when using the clang compiler.
>
> Fix the following build error used with clang compiler:
>
> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>         bits_to_set = FIELD_PREP(field_msk, nval);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>         __compiletime_assert(condition, msg, prefix, suffix)
>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>                 if (!(condition))                                       \
>
> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..782a621b1928 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>  
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>  	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>  
>  	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>  	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>  
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);

Please just switch to REG_FIELD_PREP() and it should be fine.

BR,
Jani.


> -
>  	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
>  }
>  
>  /*
> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>  	case hwmon_power_max:
>  		hwm_field_scale_and_write(ddat,
>  					  hwmon->rg.pkg_rapl_limit,
> -					  PKG_PWR_LIM_1,
>  					  hwmon->scl_shift_power,
>  					  SF_POWER, val);
>  		return 0;

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25 14:27 ` Jani Nikula
@ 2022-10-25 14:30   ` Jani Nikula
  2022-10-25 18:46     ` Dixit, Ashutosh
  0 siblings, 1 reply; 47+ messages in thread
From: Jani Nikula @ 2022-10-25 14:30 UTC (permalink / raw)
  To: Gwan-gyeong Mun, andi.shyti; +Cc: intel-gfx

On Tue, 25 Oct 2022, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Tue, 25 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
>> If a non-constant variable is used as the first argument of the FIELD_PREP
>> macro, a build error occurs when using the clang compiler.
>>
>> Fix the following build error used with clang compiler:
>>
>> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>>         bits_to_set = FIELD_PREP(field_msk, nval);
>>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
>> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
>> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>>         __compiletime_assert(condition, msg, prefix, suffix)
>>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>>                 if (!(condition))                                       \
>>
>> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
>> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
>> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>>  1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..782a621b1928 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>  
>>  static void
>>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -			  u32 field_msk, int nshift,
>> -			  unsigned int scale_factor, long lval)
>> +			  int nshift, unsigned int scale_factor, long lval)
>>  {
>>  	u32 nval;
>> -	u32 bits_to_clear;
>> -	u32 bits_to_set;
>>  
>>  	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>>  	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>  
>> -	bits_to_clear = field_msk;
>> -	bits_to_set = FIELD_PREP(field_msk, nval);
>
> Please just switch to REG_FIELD_PREP() and it should be fine.

Actually, probably not, but please switch to it anyway. ;)


>
> BR,
> Jani.
>
>
>> -
>>  	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> -					    bits_to_clear, bits_to_set);
>> +					    PKG_PWR_LIM_1,
>> +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
>>  }
>>  
>>  /*
>> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>>  	case hwmon_power_max:
>>  		hwm_field_scale_and_write(ddat,
>>  					  hwmon->rg.pkg_rapl_limit,
>> -					  PKG_PWR_LIM_1,
>>  					  hwmon->scl_shift_power,
>>  					  SF_POWER, val);
>>  		return 0;

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25  9:25     ` Andi Shyti
@ 2022-10-25 16:46       ` Nick Desaulniers
  -1 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-25 16:46 UTC (permalink / raw)
  To: Andi Shyti
  Cc: Dixit, Ashutosh, Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm, LKML

Start of lore thread for context:
https://lore.kernel.org/intel-gfx/20221024210953.1572998-1-gwan-gyeong.mun@intel.com/

On Tue, Oct 25, 2022 at 2:25 AM Andi Shyti <andi.shyti@linux.intel.com> wrote:
>
> Hi Ashutosh,
>
> > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > What is 18446744073709551615? You may want to limit the length of this line
> > or checkpatch doesn't complain?
>
> yeah! I am not a clang user, and this must be some ugly error
> output. I don't think it makes sense to break it, though.
>
> > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > >         __compiletime_assert(condition, msg, prefix, suffix)
> > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > >                 if (!(condition))                                       \
> > >
> > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 9e9781493025..782a621b1928 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > >
> > >  static void
> > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > -                     u32 field_msk, int nshift,
> > > -                     unsigned int scale_factor, long lval)
> > > +                     int nshift, unsigned int scale_factor, long lval)
> > >  {
> > >     u32 nval;
> > > -   u32 bits_to_clear;
> > > -   u32 bits_to_set;
> > >
> > >     /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > >     nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > >
> > > -   bits_to_clear = field_msk;
> > > -   bits_to_set = FIELD_PREP(field_msk, nval);
> > > -
> > >     hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > -                                       bits_to_clear, bits_to_set);
> > > +                                       PKG_PWR_LIM_1,
> > > +                                       FIELD_PREP(PKG_PWR_LIM_1, nval));
> >
> > I don't want to give up so easily. We might have future uses for the
> > function where we want field_msk to be passed into the function (rather
> > than set inside the function as in this patch).
> >
> > Do we understand what clang is complaining about? And why this compiles
> > with gcc?
>
> Because we are not compiling the builtin functions with gcc but
> gcc has support for them. The FIELD_PREP checks if the first
> parameter is a constant:
>
>         BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
>
> where _mask was our field_mask, but we ignore it. Apparently
> clang doesn't.

So we've been in this code before. I'm having vague memories of
commit 444da3f52407 ("bitfield.h: don't compile-time validate _val in
FIELD_FIT")

But looking at the first __builtin_constant_p check in
__BF_FIELD_CHECK, I'm curious if that might need to be __is_constexpr
rather than __builtin_constant_p; a change like
commit 4d45bc82df66 ("coresight: etm4x: avoid build failure with
unrolled loops")

__builtin_constant_p is evaluated after most optimizations have run;
__is_constexpr must be evaluated by compiler front ends during
semantic analysis.

But reading through the full lore thread, it sounds like Jani has
another suggestion to try instead.
https://lore.kernel.org/intel-gfx/87eduwdllr.fsf@intel.com/

Please re-cc us and our list if that doesn't work out.

>
> If we want to stick to gcc only, then I still think the patch is
> correct for two reasons:
>
>   1. it's cleaner
>   2. we would get on with the job and if one day we will decide
>      to suppport builtin functions in gcc as well, we will sleep
>      peacefully :)
>
> > Copying llvm@lists.linux.dev too.
>
> maybe llvm folks have a better opinion.
>
> Thanks,
> Andi
>
> > Thanks.
> > --
> > Ashutosh
> >
> >
> > >  }
> > >
> > >  /*
> > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > >     case hwmon_power_max:
> > >             hwm_field_scale_and_write(ddat,
> > >                                       hwmon->rg.pkg_rapl_limit,
> > > -                                     PKG_PWR_LIM_1,
> > >                                       hwmon->scl_shift_power,
> > >                                       SF_POWER, val);
> > >             return 0;
> > > --
> > > 2.37.1
> > >
>


-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-25 16:46       ` Nick Desaulniers
  0 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-25 16:46 UTC (permalink / raw)
  To: Andi Shyti; +Cc: intel-gfx, llvm, LKML

Start of lore thread for context:
https://lore.kernel.org/intel-gfx/20221024210953.1572998-1-gwan-gyeong.mun@intel.com/

On Tue, Oct 25, 2022 at 2:25 AM Andi Shyti <andi.shyti@linux.intel.com> wrote:
>
> Hi Ashutosh,
>
> > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > What is 18446744073709551615? You may want to limit the length of this line
> > or checkpatch doesn't complain?
>
> yeah! I am not a clang user, and this must be some ugly error
> output. I don't think it makes sense to break it, though.
>
> > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > >         __compiletime_assert(condition, msg, prefix, suffix)
> > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > >                 if (!(condition))                                       \
> > >
> > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 9e9781493025..782a621b1928 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > >
> > >  static void
> > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > -                     u32 field_msk, int nshift,
> > > -                     unsigned int scale_factor, long lval)
> > > +                     int nshift, unsigned int scale_factor, long lval)
> > >  {
> > >     u32 nval;
> > > -   u32 bits_to_clear;
> > > -   u32 bits_to_set;
> > >
> > >     /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > >     nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > >
> > > -   bits_to_clear = field_msk;
> > > -   bits_to_set = FIELD_PREP(field_msk, nval);
> > > -
> > >     hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > -                                       bits_to_clear, bits_to_set);
> > > +                                       PKG_PWR_LIM_1,
> > > +                                       FIELD_PREP(PKG_PWR_LIM_1, nval));
> >
> > I don't want to give up so easily. We might have future uses for the
> > function where we want field_msk to be passed into the function (rather
> > than set inside the function as in this patch).
> >
> > Do we understand what clang is complaining about? And why this compiles
> > with gcc?
>
> Because we are not compiling the builtin functions with gcc but
> gcc has support for them. The FIELD_PREP checks if the first
> parameter is a constant:
>
>         BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
>
> where _mask was our field_mask, but we ignore it. Apparently
> clang doesn't.

So we've been in this code before. I'm having vague memories of
commit 444da3f52407 ("bitfield.h: don't compile-time validate _val in
FIELD_FIT")

But looking at the first __builtin_constant_p check in
__BF_FIELD_CHECK, I'm curious if that might need to be __is_constexpr
rather than __builtin_constant_p; a change like
commit 4d45bc82df66 ("coresight: etm4x: avoid build failure with
unrolled loops")

__builtin_constant_p is evaluated after most optimizations have run;
__is_constexpr must be evaluated by compiler front ends during
semantic analysis.

But reading through the full lore thread, it sounds like Jani has
another suggestion to try instead.
https://lore.kernel.org/intel-gfx/87eduwdllr.fsf@intel.com/

Please re-cc us and our list if that doesn't work out.

>
> If we want to stick to gcc only, then I still think the patch is
> correct for two reasons:
>
>   1. it's cleaner
>   2. we would get on with the job and if one day we will decide
>      to suppport builtin functions in gcc as well, we will sleep
>      peacefully :)
>
> > Copying llvm@lists.linux.dev too.
>
> maybe llvm folks have a better opinion.
>
> Thanks,
> Andi
>
> > Thanks.
> > --
> > Ashutosh
> >
> >
> > >  }
> > >
> > >  /*
> > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > >     case hwmon_power_max:
> > >             hwm_field_scale_and_write(ddat,
> > >                                       hwmon->rg.pkg_rapl_limit,
> > > -                                     PKG_PWR_LIM_1,
> > >                                       hwmon->scl_shift_power,
> > >                                       SF_POWER, val);
> > >             return 0;
> > > --
> > > 2.37.1
> > >
>


-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25  9:25     ` Andi Shyti
@ 2022-10-25 18:45       ` Dixit, Ashutosh
  -1 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-25 18:45 UTC (permalink / raw)
  To: Andi Shyti
  Cc: Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm,
	Nick Desaulniers, linux-kernel

On Tue, 25 Oct 2022 02:25:06 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,

Hi Andi :)

> > > If a non-constant variable is used as the first argument of the FIELD_PREP
> > > macro, a build error occurs when using the clang compiler.

A "non-constant variable" does not seem to be the cause of the compile
error with clang, see below.

>
> > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > What is 18446744073709551615? You may want to limit the length of this line
> > or checkpatch doesn't complain?
>
> yeah! I am not a clang user, and this must be some ugly error
> output. I don't think it makes sense to break it, though.

18446744073709551615 == ~0ull (see use in __BF_FIELD_CHECK).

>
> > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \

So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
also occurs here):

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \

So it goes through previous checks including the "mask is not constant"
check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
after most optimizations have run" so by that time both compilers (gcc and
clang) have figured out that even though _mask is coming in as function
argument it is really the constant below:

#define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

But it is not clear why clang chokes on this "type of reg too small for
mask" check (and gcc doesn't) since everything is u32.

It is for this reason I want someone from llvm to chime in.

> > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > >         __compiletime_assert(condition, msg, prefix, suffix)
> > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > >                 if (!(condition))                                       \
> > >
> > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 9e9781493025..782a621b1928 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > >
> > >  static void
> > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > -			  u32 field_msk, int nshift,
> > > -			  unsigned int scale_factor, long lval)
> > > +			  int nshift, unsigned int scale_factor, long lval)
> > >  {
> > >	u32 nval;
> > > -	u32 bits_to_clear;
> > > -	u32 bits_to_set;
> > >
> > >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> > >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > >
> > > -	bits_to_clear = field_msk;
> > > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > > -
> > >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > -					    bits_to_clear, bits_to_set);
> > > +					    PKG_PWR_LIM_1,
> > > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> >
> > I don't want to give up so easily. We might have future uses for the
> > function where we want field_msk to be passed into the function (rather
> > than set inside the function as in this patch).
> >
> > Do we understand what clang is complaining about? And why this compiles
> > with gcc?
>
> Because we are not compiling the builtin functions with gcc but
> gcc has support for them. The FIELD_PREP checks if the first
> parameter is a constant:
>
>	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
>
> where _mask was our field_mask, but we ignore it. Apparently
> clang doesn't.

So we have debunked this above.

> If we want to stick to gcc only, then I still think the patch is
> correct for two reasons:
>
>   1. it's cleaner
>   2. we would get on with the job and if one day we will decide
>      to suppport builtin functions in gcc as well, we will sleep
>      peacefully :)

I disagree with the patch even if we need to fix this in i915 (rather than
say change the headers or something in clang).

Note that hwm_field_scale_and_write() pairs with hwm_field_read_and_scale()
(they are basically a set/get pair) so it is desirable they have identical
arguments. This patch breaks that symmetry.

If we have to fix this in i915, I prefer the following patch (so just skip
the checks in FIELD_PREP):

@@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
        nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

        bits_to_clear = field_msk;
-       bits_to_set = FIELD_PREP(field_msk, nval);
+       bits_to_set = (nval << __bf_shf(field_msk)) & field_msk;

        hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,

But I'd wait to hear from clang/llvm folks first.

> > Copying llvm@lists.linux.dev too.
>
> maybe llvm folks have a better opinion.
>

Thanks.
--
Ashutosh

> > >  }
> > >
> > >  /*
> > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > >	case hwmon_power_max:
> > >		hwm_field_scale_and_write(ddat,
> > >					  hwmon->rg.pkg_rapl_limit,
> > > -					  PKG_PWR_LIM_1,
> > >					  hwmon->scl_shift_power,
> > >					  SF_POWER, val);
> > >		return 0;
> > > --
> > > 2.37.1
> > >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-25 18:45       ` Dixit, Ashutosh
  0 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-25 18:45 UTC (permalink / raw)
  To: Andi Shyti; +Cc: intel-gfx, llvm, Nick Desaulniers, linux-kernel

On Tue, 25 Oct 2022 02:25:06 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,

Hi Andi :)

> > > If a non-constant variable is used as the first argument of the FIELD_PREP
> > > macro, a build error occurs when using the clang compiler.

A "non-constant variable" does not seem to be the cause of the compile
error with clang, see below.

>
> > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > What is 18446744073709551615? You may want to limit the length of this line
> > or checkpatch doesn't complain?
>
> yeah! I am not a clang user, and this must be some ugly error
> output. I don't think it makes sense to break it, though.

18446744073709551615 == ~0ull (see use in __BF_FIELD_CHECK).

>
> > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \

So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
also occurs here):

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \

So it goes through previous checks including the "mask is not constant"
check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
after most optimizations have run" so by that time both compilers (gcc and
clang) have figured out that even though _mask is coming in as function
argument it is really the constant below:

#define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

But it is not clear why clang chokes on this "type of reg too small for
mask" check (and gcc doesn't) since everything is u32.

It is for this reason I want someone from llvm to chime in.

> > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > >         __compiletime_assert(condition, msg, prefix, suffix)
> > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > >                 if (!(condition))                                       \
> > >
> > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 9e9781493025..782a621b1928 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > >
> > >  static void
> > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > -			  u32 field_msk, int nshift,
> > > -			  unsigned int scale_factor, long lval)
> > > +			  int nshift, unsigned int scale_factor, long lval)
> > >  {
> > >	u32 nval;
> > > -	u32 bits_to_clear;
> > > -	u32 bits_to_set;
> > >
> > >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> > >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > >
> > > -	bits_to_clear = field_msk;
> > > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > > -
> > >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > -					    bits_to_clear, bits_to_set);
> > > +					    PKG_PWR_LIM_1,
> > > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> >
> > I don't want to give up so easily. We might have future uses for the
> > function where we want field_msk to be passed into the function (rather
> > than set inside the function as in this patch).
> >
> > Do we understand what clang is complaining about? And why this compiles
> > with gcc?
>
> Because we are not compiling the builtin functions with gcc but
> gcc has support for them. The FIELD_PREP checks if the first
> parameter is a constant:
>
>	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
>
> where _mask was our field_mask, but we ignore it. Apparently
> clang doesn't.

So we have debunked this above.

> If we want to stick to gcc only, then I still think the patch is
> correct for two reasons:
>
>   1. it's cleaner
>   2. we would get on with the job and if one day we will decide
>      to suppport builtin functions in gcc as well, we will sleep
>      peacefully :)

I disagree with the patch even if we need to fix this in i915 (rather than
say change the headers or something in clang).

Note that hwm_field_scale_and_write() pairs with hwm_field_read_and_scale()
(they are basically a set/get pair) so it is desirable they have identical
arguments. This patch breaks that symmetry.

If we have to fix this in i915, I prefer the following patch (so just skip
the checks in FIELD_PREP):

@@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
        nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

        bits_to_clear = field_msk;
-       bits_to_set = FIELD_PREP(field_msk, nval);
+       bits_to_set = (nval << __bf_shf(field_msk)) & field_msk;

        hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,

But I'd wait to hear from clang/llvm folks first.

> > Copying llvm@lists.linux.dev too.
>
> maybe llvm folks have a better opinion.
>

Thanks.
--
Ashutosh

> > >  }
> > >
> > >  /*
> > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > >	case hwmon_power_max:
> > >		hwm_field_scale_and_write(ddat,
> > >					  hwmon->rg.pkg_rapl_limit,
> > > -					  PKG_PWR_LIM_1,
> > >					  hwmon->scl_shift_power,
> > >					  SF_POWER, val);
> > >		return 0;
> > > --
> > > 2.37.1
> > >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25 14:30   ` Jani Nikula
@ 2022-10-25 18:46     ` Dixit, Ashutosh
  0 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-25 18:46 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

On Tue, 25 Oct 2022 07:30:49 -0700, Jani Nikula wrote:
>
> On Tue, 25 Oct 2022, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Tue, 25 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
> >> If a non-constant variable is used as the first argument of the FIELD_PREP
> >> macro, a build error occurs when using the clang compiler.
> >>
> >> Fix the following build error used with clang compiler:
> >>
> >> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >>         bits_to_set = FIELD_PREP(field_msk, nval);
> >>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> >>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> >>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> >>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> >> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> >>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> >> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> >>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> >>         __compiletime_assert(condition, msg, prefix, suffix)
> >>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> >>                 if (!(condition))                                       \
> >>
> >> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> >> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> >> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> >>  1 file changed, 3 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> >> index 9e9781493025..782a621b1928 100644
> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >>
> >>  static void
> >>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >> -			  u32 field_msk, int nshift,
> >> -			  unsigned int scale_factor, long lval)
> >> +			  int nshift, unsigned int scale_factor, long lval)
> >>  {
> >>	u32 nval;
> >> -	u32 bits_to_clear;
> >> -	u32 bits_to_set;
> >>
> >>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> >>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >>
> >> -	bits_to_clear = field_msk;
> >> -	bits_to_set = FIELD_PREP(field_msk, nval);
> >
> > Please just switch to REG_FIELD_PREP() and it should be fine.
>
> Actually, probably not, but please switch to it anyway. ;)

This is what happens with REG_FIELD_PREP(), that is why we went ahead with
FIELD_PREP(). So REG_FIELD_PREP is not an option.

  CC [M]  drivers/gpu/drm/i915/i915_hwmon.o
In file included from ./include/linux/bits.h:22,
                 from ./include/linux/bitops.h:6,
                 from ./include/linux/hwmon.h:15,
                 from drivers/gpu/drm/i915/i915_hwmon.c:6:
drivers/gpu/drm/i915/i915_hwmon.c: In function ‘hwm_field_scale_and_write’:
./include/linux/build_bug.h:16:51: error: negative width in bit-field ‘<anonymous>’
   16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
      |                                                   ^
./drivers/gpu/drm/i915/i915_reg_defs.h:72:16: note: in expansion of macro ‘BUILD_BUG_ON_ZERO’
   72 |                BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) +             \
      |                ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/i915_hwmon.c:115:23: note: in expansion of macro ‘REG_FIELD_PREP’
  115 |         bits_to_set = REG_FIELD_PREP(field_msk, nval);
      |                       ^~~~~~~~~~~~~~
./include/linux/build_bug.h:16:51: error: bit-field ‘<anonymous>’ width not an integer constant
   16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
      |                                                   ^
./drivers/gpu/drm/i915/i915_reg_defs.h:73:16: note: in expansion of macro ‘BUILD_BUG_ON_ZERO’
   73 |                BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) +         \
      |                ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/i915_hwmon.c:115:23: note: in expansion of macro ‘REG_FIELD_PREP’
  115 |         bits_to_set = REG_FIELD_PREP(field_msk, nval);
      |                       ^~~~~~~~~~~~~~
./include/linux/build_bug.h:16:51: error: bit-field ‘<anonymous>’ width not an integer constant
   16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
      |                                                   ^
./drivers/gpu/drm/i915/i915_reg_defs.h:74:16: note: in expansion of macro ‘BUILD_BUG_ON_ZERO’
   74 |                BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << __bf_shf(__mask)))) + \
      |                ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/i915_hwmon.c:115:23: note: in expansion of macro ‘REG_FIELD_PREP’
  115 |         bits_to_set = REG_FIELD_PREP(field_msk, nval);
      |                       ^~~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:250: drivers/gpu/drm/i915/i915_hwmon.o] Error 1
make: *** [Makefile:1992: drivers/gpu/drm/i915] Error 2

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-25 18:45       ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-26  0:18         ` Andi Shyti
  -1 siblings, 0 replies; 47+ messages in thread
From: Andi Shyti @ 2022-10-26  0:18 UTC (permalink / raw)
  To: Dixit, Ashutosh
  Cc: Andi Shyti, Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm,
	Nick Desaulniers, linux-kernel

Hi Ashutosh,

> On Tue, 25 Oct 2022 02:25:06 -0700, Andi Shyti wrote:
> >
> > Hi Ashutosh,
> 
> Hi Andi :)
> 
> > > > If a non-constant variable is used as the first argument of the FIELD_PREP
> > > > macro, a build error occurs when using the clang compiler.
> 
> A "non-constant variable" does not seem to be the cause of the compile
> error with clang, see below.
> 
> >
> > > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> > >
> > > What is 18446744073709551615? You may want to limit the length of this line
> > > or checkpatch doesn't complain?
> >
> > yeah! I am not a clang user, and this must be some ugly error
> > output. I don't think it makes sense to break it, though.
> 
> 18446744073709551615 == ~0ull (see use in __BF_FIELD_CHECK).

I just wonder, then, where this number comes from, looks to me
like an ill formatted constant coming from the compiler
(definitely bigger than a ull).

> >
> > > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

I also thought that the compiler should have figured it out, but
then why we got that error, and I don't see how
"bf_cast_unsigned(_reg, ~0ull)" could fail.

> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> 
> It is for this reason I want someone from llvm to chime in.
> 
> > > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > > >         __compiletime_assert(condition, msg, prefix, suffix)
> > > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > > >                 if (!(condition))                                       \
> > > >
> > > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index 9e9781493025..782a621b1928 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > >
> > > >  static void
> > > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > > -			  u32 field_msk, int nshift,
> > > > -			  unsigned int scale_factor, long lval)
> > > > +			  int nshift, unsigned int scale_factor, long lval)
> > > >  {
> > > >	u32 nval;
> > > > -	u32 bits_to_clear;
> > > > -	u32 bits_to_set;
> > > >
> > > >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> > > >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > > >
> > > > -	bits_to_clear = field_msk;
> > > > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > > > -
> > > >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > > -					    bits_to_clear, bits_to_set);
> > > > +					    PKG_PWR_LIM_1,
> > > > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> > >
> > > I don't want to give up so easily. We might have future uses for the
> > > function where we want field_msk to be passed into the function (rather
> > > than set inside the function as in this patch).
> > >
> > > Do we understand what clang is complaining about? And why this compiles
> > > with gcc?
> >
> > Because we are not compiling the builtin functions with gcc but
> > gcc has support for them. The FIELD_PREP checks if the first
> > parameter is a constant:
> >
> >	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
> >
> > where _mask was our field_mask, but we ignore it. Apparently
> > clang doesn't.
> 
> So we have debunked this above.
> 
> > If we want to stick to gcc only, then I still think the patch is
> > correct for two reasons:
> >
> >   1. it's cleaner
> >   2. we would get on with the job and if one day we will decide
> >      to suppport builtin functions in gcc as well, we will sleep
> >      peacefully :)
> 
> I disagree with the patch even if we need to fix this in i915 (rather than
> say change the headers or something in clang).
> 
> Note that hwm_field_scale_and_write() pairs with hwm_field_read_and_scale()
> (they are basically a set/get pair) so it is desirable they have identical
> arguments. This patch breaks that symmetry.

OK, didn't see it! Makes sense.

> If we have to fix this in i915, I prefer the following patch (so just skip
> the checks in FIELD_PREP):
> 
> @@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> 
>         bits_to_clear = field_msk;
> -       bits_to_set = FIELD_PREP(field_msk, nval);
> +       bits_to_set = (nval << __bf_shf(field_msk)) & field_msk;
> 
>         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,

doesn't look pretty, though! :/

> But I'd wait to hear from clang/llvm folks first.

Yeah! Looking forward to getting some ideas :)

Thanks, Ashutosh!
Andi

> > > Copying llvm@lists.linux.dev too.
> >
> > maybe llvm folks have a better opinion.
> >
> 
> Thanks.
> --
> Ashutosh
> 
> > > >  }
> > > >
> > > >  /*
> > > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > > >	case hwmon_power_max:
> > > >		hwm_field_scale_and_write(ddat,
> > > >					  hwmon->rg.pkg_rapl_limit,
> > > > -					  PKG_PWR_LIM_1,
> > > >					  hwmon->scl_shift_power,
> > > >					  SF_POWER, val);
> > > >		return 0;
> > > > --
> > > > 2.37.1
> > > >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-26  0:18         ` Andi Shyti
  0 siblings, 0 replies; 47+ messages in thread
From: Andi Shyti @ 2022-10-26  0:18 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: intel-gfx, llvm, Nick Desaulniers, linux-kernel

Hi Ashutosh,

> On Tue, 25 Oct 2022 02:25:06 -0700, Andi Shyti wrote:
> >
> > Hi Ashutosh,
> 
> Hi Andi :)
> 
> > > > If a non-constant variable is used as the first argument of the FIELD_PREP
> > > > macro, a build error occurs when using the clang compiler.
> 
> A "non-constant variable" does not seem to be the cause of the compile
> error with clang, see below.
> 
> >
> > > > drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> > >
> > > What is 18446744073709551615? You may want to limit the length of this line
> > > or checkpatch doesn't complain?
> >
> > yeah! I am not a clang user, and this must be some ugly error
> > output. I don't think it makes sense to break it, though.
> 
> 18446744073709551615 == ~0ull (see use in __BF_FIELD_CHECK).

I just wonder, then, where this number comes from, looks to me
like an ill formatted constant coming from the compiler
(definitely bigger than a ull).

> >
> > > >         bits_to_set = FIELD_PREP(field_msk, nval);
> > > >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
> > > >                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

I also thought that the compiler should have figured it out, but
then why we got that error, and I don't see how
"bf_cast_unsigned(_reg, ~0ull)" could fail.

> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> 
> It is for this reason I want someone from llvm to chime in.
> 
> > > >                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > > > ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > > >                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
> > > >         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > > >         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
> > > >         __compiletime_assert(condition, msg, prefix, suffix)
> > > >         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
> > > >                 if (!(condition))                                       \
> > > >
> > > > Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > > Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
> > > >  1 file changed, 3 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index 9e9781493025..782a621b1928 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > >
> > > >  static void
> > > >  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > > > -			  u32 field_msk, int nshift,
> > > > -			  unsigned int scale_factor, long lval)
> > > > +			  int nshift, unsigned int scale_factor, long lval)
> > > >  {
> > > >	u32 nval;
> > > > -	u32 bits_to_clear;
> > > > -	u32 bits_to_set;
> > > >
> > > >	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> > > >	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> > > >
> > > > -	bits_to_clear = field_msk;
> > > > -	bits_to_set = FIELD_PREP(field_msk, nval);
> > > > -
> > > >	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> > > > -					    bits_to_clear, bits_to_set);
> > > > +					    PKG_PWR_LIM_1,
> > > > +					    FIELD_PREP(PKG_PWR_LIM_1, nval));
> > >
> > > I don't want to give up so easily. We might have future uses for the
> > > function where we want field_msk to be passed into the function (rather
> > > than set inside the function as in this patch).
> > >
> > > Do we understand what clang is complaining about? And why this compiles
> > > with gcc?
> >
> > Because we are not compiling the builtin functions with gcc but
> > gcc has support for them. The FIELD_PREP checks if the first
> > parameter is a constant:
> >
> >	BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),
> >
> > where _mask was our field_mask, but we ignore it. Apparently
> > clang doesn't.
> 
> So we have debunked this above.
> 
> > If we want to stick to gcc only, then I still think the patch is
> > correct for two reasons:
> >
> >   1. it's cleaner
> >   2. we would get on with the job and if one day we will decide
> >      to suppport builtin functions in gcc as well, we will sleep
> >      peacefully :)
> 
> I disagree with the patch even if we need to fix this in i915 (rather than
> say change the headers or something in clang).
> 
> Note that hwm_field_scale_and_write() pairs with hwm_field_read_and_scale()
> (they are basically a set/get pair) so it is desirable they have identical
> arguments. This patch breaks that symmetry.

OK, didn't see it! Makes sense.

> If we have to fix this in i915, I prefer the following patch (so just skip
> the checks in FIELD_PREP):
> 
> @@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> 
>         bits_to_clear = field_msk;
> -       bits_to_set = FIELD_PREP(field_msk, nval);
> +       bits_to_set = (nval << __bf_shf(field_msk)) & field_msk;
> 
>         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,

doesn't look pretty, though! :/

> But I'd wait to hear from clang/llvm folks first.

Yeah! Looking forward to getting some ideas :)

Thanks, Ashutosh!
Andi

> > > Copying llvm@lists.linux.dev too.
> >
> > maybe llvm folks have a better opinion.
> >
> 
> Thanks.
> --
> Ashutosh
> 
> > > >  }
> > > >
> > > >  /*
> > > > @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> > > >	case hwmon_power_max:
> > > >		hwm_field_scale_and_write(ddat,
> > > >					  hwmon->rg.pkg_rapl_limit,
> > > > -					  PKG_PWR_LIM_1,
> > > >					  hwmon->scl_shift_power,
> > > >					  SF_POWER, val);
> > > >		return 0;
> > > > --
> > > > 2.37.1
> > > >

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-26  0:18         ` [Intel-gfx] " Andi Shyti
@ 2022-10-27 16:35           ` Nick Desaulniers
  -1 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-27 16:35 UTC (permalink / raw)
  To: Gwan-gyeong Mun
  Cc: Dixit, Ashutosh, anshuman.gupta, intel-gfx, llvm, linux-kernel,
	Andi Shyti

On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
>
> Hi Ashutosh,
>
> > But I'd wait to hear from clang/llvm folks first.
>
> Yeah! Looking forward to getting some ideas :)

Gwan-gyeong, which tree and set of configs are necessary to reproduce
the observed warning?

Warnings are treated as errors, so I don't want this breaking our CI.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-27 16:35           ` Nick Desaulniers
  0 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-27 16:35 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx, llvm, linux-kernel

On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
>
> Hi Ashutosh,
>
> > But I'd wait to hear from clang/llvm folks first.
>
> Yeah! Looking forward to getting some ideas :)

Gwan-gyeong, which tree and set of configs are necessary to reproduce
the observed warning?

Warnings are treated as errors, so I don't want this breaking our CI.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-27 16:35           ` [Intel-gfx] " Nick Desaulniers
@ 2022-10-27 16:53             ` Dixit, Ashutosh
  -1 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-27 16:53 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm, linux-kernel,
	Andi Shyti

On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote:
>

Hi Nick,

> On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
> >
> > Hi Ashutosh,
> >
> > > But I'd wait to hear from clang/llvm folks first.
> >
> > Yeah! Looking forward to getting some ideas :)
>
> Gwan-gyeong, which tree and set of configs are necessary to reproduce
> the observed warning?
>
> Warnings are treated as errors, so I don't want this breaking our CI.

The following or equivalent should do it:

git clone https://anongit.freedesktop.org/git/drm/drm-tip
git checkout drm-tip

Kernel config:
CONFIG_DRM_I915=m
CONFIG_HWMON=y

Files:
drivers/gpu/drm/i915/i915_hwmon.c/.h

Thanks for taking a look.
--
Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-27 16:53             ` Dixit, Ashutosh
  0 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-27 16:53 UTC (permalink / raw)
  To: Nick Desaulniers; +Cc: intel-gfx, llvm, linux-kernel

On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote:
>

Hi Nick,

> On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
> >
> > Hi Ashutosh,
> >
> > > But I'd wait to hear from clang/llvm folks first.
> >
> > Yeah! Looking forward to getting some ideas :)
>
> Gwan-gyeong, which tree and set of configs are necessary to reproduce
> the observed warning?
>
> Warnings are treated as errors, so I don't want this breaking our CI.

The following or equivalent should do it:

git clone https://anongit.freedesktop.org/git/drm/drm-tip
git checkout drm-tip

Kernel config:
CONFIG_DRM_I915=m
CONFIG_HWMON=y

Files:
drivers/gpu/drm/i915/i915_hwmon.c/.h

Thanks for taking a look.
--
Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-27 16:53             ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-27 17:16               ` Nick Desaulniers
  -1 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-27 17:16 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: intel-gfx, llvm, linux-kernel

On Thu, Oct 27, 2022 at 9:53 AM Dixit, Ashutosh
<ashutosh.dixit@intel.com> wrote:
>
> On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote:
> >
>
> Hi Nick,
>
> > On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > > But I'd wait to hear from clang/llvm folks first.
> > >
> > > Yeah! Looking forward to getting some ideas :)
> >
> > Gwan-gyeong, which tree and set of configs are necessary to reproduce
> > the observed warning?
> >
> > Warnings are treated as errors, so I don't want this breaking our CI.
>
> The following or equivalent should do it:
>
> git clone https://anongit.freedesktop.org/git/drm/drm-tip
> git checkout drm-tip
>
> Kernel config:
> CONFIG_DRM_I915=m
> CONFIG_HWMON=y
>
> Files:
> drivers/gpu/drm/i915/i915_hwmon.c/.h
>
> Thanks for taking a look.

Thanks, I can repro now.

I haven't detangled the macro soup, but I noticed:

1. FIELD_PREP is defined in include/linux/bitfield.h which has the
following comment:
 18  * Mask must be a compilation time constant.

2. hwm_field_scale_and_write only has one callsite.

The following patch works:

```
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e9781493025..6ac29d90b92a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
i915_reg_t rgadr,

 static void
 hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         u32 field_msk, int nshift,
+                         int nshift,
                          unsigned int scale_factor, long lval)
 {
        u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
*ddat, i915_reg_t rgadr,
        /* Computation in 64-bits to avoid overflow. Round to nearest. */
        nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);

        hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                            bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
attr, int chan, long val)
        case hwmon_power_max:
                hwm_field_scale_and_write(ddat,
                                          hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                          hwmon->scl_shift_power,
                                          SF_POWER, val);
                return 0;
```
Though I'm not sure if you're planning to add further callsites of
hwm_field_scale_and_write with different field_masks?

Alternatively, (without the above diff),

```
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6f40f12bcf89 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -8,6 +8,7 @@
 #define _LINUX_BITFIELD_H

 #include <linux/build_bug.h>
+#include <linux/const.h>
 #include <asm/byteorder.h>

 /*
@@ -62,7 +63,7 @@

 #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
        ({                                                              \
-               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
+               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
                                 _pfx "mask is not constant");          \
                BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
                BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
```
will produce:
error: call to __compiletime_assert_407 declared with 'error'
attribute: FIELD_PREP: mask is not constant

I haven't tested if that change is also feasible (on top of fixing
this specific instance), but I think it might help avoid more of these
subtleties wrt. __builtin_constant_p that depende heavily on compiler,
compiler version, optimization level.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-27 17:16               ` Nick Desaulniers
  0 siblings, 0 replies; 47+ messages in thread
From: Nick Desaulniers @ 2022-10-27 17:16 UTC (permalink / raw)
  To: Dixit, Ashutosh
  Cc: Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm, linux-kernel,
	Andi Shyti

On Thu, Oct 27, 2022 at 9:53 AM Dixit, Ashutosh
<ashutosh.dixit@intel.com> wrote:
>
> On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote:
> >
>
> Hi Nick,
>
> > On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti <andi.shyti@linux.intel.com> wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > > But I'd wait to hear from clang/llvm folks first.
> > >
> > > Yeah! Looking forward to getting some ideas :)
> >
> > Gwan-gyeong, which tree and set of configs are necessary to reproduce
> > the observed warning?
> >
> > Warnings are treated as errors, so I don't want this breaking our CI.
>
> The following or equivalent should do it:
>
> git clone https://anongit.freedesktop.org/git/drm/drm-tip
> git checkout drm-tip
>
> Kernel config:
> CONFIG_DRM_I915=m
> CONFIG_HWMON=y
>
> Files:
> drivers/gpu/drm/i915/i915_hwmon.c/.h
>
> Thanks for taking a look.

Thanks, I can repro now.

I haven't detangled the macro soup, but I noticed:

1. FIELD_PREP is defined in include/linux/bitfield.h which has the
following comment:
 18  * Mask must be a compilation time constant.

2. hwm_field_scale_and_write only has one callsite.

The following patch works:

```
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e9781493025..6ac29d90b92a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
i915_reg_t rgadr,

 static void
 hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         u32 field_msk, int nshift,
+                         int nshift,
                          unsigned int scale_factor, long lval)
 {
        u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
*ddat, i915_reg_t rgadr,
        /* Computation in 64-bits to avoid overflow. Round to nearest. */
        nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);

        hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                            bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
attr, int chan, long val)
        case hwmon_power_max:
                hwm_field_scale_and_write(ddat,
                                          hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                          hwmon->scl_shift_power,
                                          SF_POWER, val);
                return 0;
```
Though I'm not sure if you're planning to add further callsites of
hwm_field_scale_and_write with different field_masks?

Alternatively, (without the above diff),

```
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6f40f12bcf89 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -8,6 +8,7 @@
 #define _LINUX_BITFIELD_H

 #include <linux/build_bug.h>
+#include <linux/const.h>
 #include <asm/byteorder.h>

 /*
@@ -62,7 +63,7 @@

 #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
        ({                                                              \
-               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
+               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
                                 _pfx "mask is not constant");          \
                BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
                BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
```
will produce:
error: call to __compiletime_assert_407 declared with 'error'
attribute: FIELD_PREP: mask is not constant

I haven't tested if that change is also feasible (on top of fixing
this specific instance), but I think it might help avoid more of these
subtleties wrt. __builtin_constant_p that depende heavily on compiler,
compiler version, optimization level.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (4 preceding siblings ...)
  2022-10-25 14:27 ` Jani Nikula
@ 2022-10-27 17:54 ` Patchwork
  2022-10-28  6:30 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev3) Patchwork
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-27 17:54 UTC (permalink / raw)
  To: Nick Desaulniers; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev2)
URL   : https://patchwork.freedesktop.org/series/110094/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/110094/revisions/2/mbox/ not applied
Applying: drm/i915/hwmon: Fix a build error used with clang compiler
error: git diff header lacks filename information when removing 1 leading pathname component (line 2)
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/hwmon: Fix a build error used with clang compiler
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".



^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-27 17:16               ` Nick Desaulniers
@ 2022-10-27 18:32                 ` Dixit, Ashutosh
  -1 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-27 18:32 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Gwan-gyeong Mun, anshuman.gupta, intel-gfx, llvm, linux-kernel,
	Andi Shyti

On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>

Hi Nick,

> Thanks, I can repro now.
>
> I haven't detangled the macro soup, but I noticed:
>
> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
> following comment:
>  18  * Mask must be a compilation time constant.

I had comments about this here:

https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/

The relevant part being:

---- {quote} ----
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \

So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
also occurs here):

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \

So it goes through previous checks including the "mask is not constant"
check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
after most optimizations have run" so by that time both compilers (gcc and
clang) have figured out that even though _mask is coming in as function
argument it is really the constant below:

#define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

But it is not clear why clang chokes on this "type of reg too small for
mask" check (and gcc doesn't) since everything is u32.
---- {end quote} ----

>
> 2. hwm_field_scale_and_write only has one callsite.
>
> The following patch works:

If we need to fix it at our end yes we can come up with one of these
patches. But we were hoping someone from clang/llvm can comment about the
"type of reg too small for mask" stuff. If this is something which needs to
be fixed in clang/llvm we probably don't want to hide the issue.

>
> ```
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..6ac29d90b92a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -                         u32 field_msk, int nshift,
> +                         int nshift,
>                           unsigned int scale_factor, long lval)
>  {
>         u32 nval;
> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
> *ddat, i915_reg_t rgadr,
>         /* Computation in 64-bits to avoid overflow. Round to nearest. */
>         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -       bits_to_clear = field_msk;
> -       bits_to_set = FIELD_PREP(field_msk, nval);
> +       bits_to_clear = PKG_PWR_LIM_1;
> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>
>         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>                                             bits_to_clear, bits_to_set);
> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
> attr, int chan, long val)
>         case hwmon_power_max:
>                 hwm_field_scale_and_write(ddat,
>                                           hwmon->rg.pkg_rapl_limit,
> -                                         PKG_PWR_LIM_1,
>                                           hwmon->scl_shift_power,
>                                           SF_POWER, val);
>                 return 0;
> ```
> Though I'm not sure if you're planning to add further callsites of
> hwm_field_scale_and_write with different field_masks?

I have reasons for keeping it this way, it's there in the link above if you
are interested.

>
> Alternatively, (without the above diff),
>
> ```
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index c9be1657f03d..6f40f12bcf89 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -8,6 +8,7 @@
>  #define _LINUX_BITFIELD_H
>
>  #include <linux/build_bug.h>
> +#include <linux/const.h>
>  #include <asm/byteorder.h>
>
>  /*
> @@ -62,7 +63,7 @@
>
>  #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>         ({                                                              \
> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>                                  _pfx "mask is not constant");          \
>                 BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>                 BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
> ```
> will produce:
> error: call to __compiletime_assert_407 declared with 'error'
> attribute: FIELD_PREP: mask is not constant
>
> I haven't tested if that change is also feasible (on top of fixing
> this specific instance), but I think it might help avoid more of these
> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
> compiler version, optimization level.

Not disagreeing, can do something here if needed.

Thanks.
--
Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-27 18:32                 ` Dixit, Ashutosh
  0 siblings, 0 replies; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-27 18:32 UTC (permalink / raw)
  To: Nick Desaulniers; +Cc: intel-gfx, llvm, linux-kernel

On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>

Hi Nick,

> Thanks, I can repro now.
>
> I haven't detangled the macro soup, but I noticed:
>
> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
> following comment:
>  18  * Mask must be a compilation time constant.

I had comments about this here:

https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/

The relevant part being:

---- {quote} ----
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> > >                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \

So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
also occurs here):

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \

So it goes through previous checks including the "mask is not constant"
check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
after most optimizations have run" so by that time both compilers (gcc and
clang) have figured out that even though _mask is coming in as function
argument it is really the constant below:

#define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)

But it is not clear why clang chokes on this "type of reg too small for
mask" check (and gcc doesn't) since everything is u32.
---- {end quote} ----

>
> 2. hwm_field_scale_and_write only has one callsite.
>
> The following patch works:

If we need to fix it at our end yes we can come up with one of these
patches. But we were hoping someone from clang/llvm can comment about the
"type of reg too small for mask" stuff. If this is something which needs to
be fixed in clang/llvm we probably don't want to hide the issue.

>
> ```
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..6ac29d90b92a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -                         u32 field_msk, int nshift,
> +                         int nshift,
>                           unsigned int scale_factor, long lval)
>  {
>         u32 nval;
> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
> *ddat, i915_reg_t rgadr,
>         /* Computation in 64-bits to avoid overflow. Round to nearest. */
>         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -       bits_to_clear = field_msk;
> -       bits_to_set = FIELD_PREP(field_msk, nval);
> +       bits_to_clear = PKG_PWR_LIM_1;
> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>
>         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>                                             bits_to_clear, bits_to_set);
> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
> attr, int chan, long val)
>         case hwmon_power_max:
>                 hwm_field_scale_and_write(ddat,
>                                           hwmon->rg.pkg_rapl_limit,
> -                                         PKG_PWR_LIM_1,
>                                           hwmon->scl_shift_power,
>                                           SF_POWER, val);
>                 return 0;
> ```
> Though I'm not sure if you're planning to add further callsites of
> hwm_field_scale_and_write with different field_masks?

I have reasons for keeping it this way, it's there in the link above if you
are interested.

>
> Alternatively, (without the above diff),
>
> ```
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index c9be1657f03d..6f40f12bcf89 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -8,6 +8,7 @@
>  #define _LINUX_BITFIELD_H
>
>  #include <linux/build_bug.h>
> +#include <linux/const.h>
>  #include <asm/byteorder.h>
>
>  /*
> @@ -62,7 +63,7 @@
>
>  #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>         ({                                                              \
> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>                                  _pfx "mask is not constant");          \
>                 BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>                 BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
> ```
> will produce:
> error: call to __compiletime_assert_407 declared with 'error'
> attribute: FIELD_PREP: mask is not constant
>
> I haven't tested if that change is also feasible (on top of fixing
> this specific instance), but I think it might help avoid more of these
> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
> compiler version, optimization level.

Not disagreeing, can do something here if needed.

Thanks.
--
Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-27 18:32                 ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-28  6:26                   ` Gwan-gyeong Mun
  -1 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-28  6:26 UTC (permalink / raw)
  To: Dixit, Ashutosh, Nick Desaulniers
  Cc: anshuman.gupta, intel-gfx, llvm, linux-kernel, Andi Shyti

Hi all,

I should have written the commit message more accurately, but it seems 
that it was written inaccurately.

If the FIELD_PREP macro is expanded, the following macros are used.

#define FIELD_PREP(_mask, _val)						\
	({								\
		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
	})


#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
	({								\
		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
				 _pfx "mask is not constant");		\
		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
				 _pfx "value too large for the field"); \
		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \
		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
					      (1ULL << __bf_shf(_mask))); \
	})

Among them, a build error is generated by the lower part of the 
__BF_FIELD_CHECK() macro.

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \


Here, if you apply an argument to this macro, it will look like the 
following.

__bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)

The result is always false because an unsigned int value of type 
field_msk is not always greater than the maximum value of unsigned long 
long .
So, a build error occurs due to the following part of the clang compiler 
option.

[-Werror,-Wtautological-constant-out-of-range-compare]

You can simply override this warning in Clang by adding the build option 
below, but this seems like a bad attempt

i915/Makefile
CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare

The easiest way to solve this is to use a constant value, not a 
variable, as an argument to FIELD_PREP.

And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
expression as the first argument, it cannot be changed with this macro 
alone in the existing code, it must be changed to input a constant value 
as shown below.

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 08c921421a5f..abb3a194c548 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,

  static void
  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         const u32 field_msk, int nshift,
+                         int nshift,
                           unsigned int scale_factor, long lval)
  {
         u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
         /* Computation in 64-bits to avoid overflow. Round to nearest. */
         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = REG_FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);

         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                             bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
int chan, long val)
         case hwmon_power_max:
                 hwm_field_scale_and_write(ddat,
                                           hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                           hwmon->scl_shift_power,
                                           SF_POWER, val);
                 return 0;



In addition, if there is no build problem regardless of the size of the 
type as the first argument in FIELD_PREP, it is possible through the 
following modification.
(Since this modification modifies include/linux/bitfield.h , I will send 
it as a separate patch.
   )

However, it seems that we need to have Jani's confirm whether it is okay 
to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
return type.

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6e96799b6f38 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -9,7 +9,7 @@

  #include <linux/build_bug.h>
  #include <asm/byteorder.h>
-
+#include <linux/overflow.h>
  /*
   * Bitfield access macros
   *
@@ -69,7 +69,7 @@
                                  ~((_mask) >> __bf_shf(_mask)) & (_val) 
: 0, \
                                  _pfx "value too large for the field"); \
                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
-                                __bf_cast_unsigned(_reg, ~0ull),       \
+                                __bf_cast_unsigned(_reg, 
type_max(__unsigned_scalar_typeof(_reg))),    \
                                  _pfx "type of reg too small for mask"); \
                 __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
                                               (1ULL << __bf_shf(_mask))); \
@@ -84,7 +84,7 @@
   */
  #define FIELD_MAX(_mask)                                               \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
                 (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
         })

@@ -97,7 +97,7 @@
   */
  #define FIELD_FIT(_mask, _val)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
                 !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
         })

@@ -111,7 +111,7 @@
   */
  #define FIELD_PREP(_mask, _val) 
          \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
                 ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
         })

@@ -125,7 +125,7 @@
   */
  #define FIELD_GET(_mask, _reg)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
+               __BF_FIELD_CHECK(_mask, _reg, 
type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
                 (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
         })


Br,

G.G.


On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>
> 
> Hi Nick,
> 
>> Thanks, I can repro now.
>>
>> I haven't detangled the macro soup, but I noticed:
>>
>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>> following comment:
>>   18  * Mask must be a compilation time constant.
> 
> I had comments about this here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> The relevant part being:
> 
> ---- {quote} ----
>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
> 
> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> ---- {end quote} ----
> 
>>
>> 2. hwm_field_scale_and_write only has one callsite.
>>
>> The following patch works:
> 
> If we need to fix it at our end yes we can come up with one of these
> patches. But we were hoping someone from clang/llvm can comment about the
> "type of reg too small for mask" stuff. If this is something which needs to
> be fixed in clang/llvm we probably don't want to hide the issue.
> 
>>
>> ```
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>> b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..6ac29d90b92a 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -                         u32 field_msk, int nshift,
>> +                         int nshift,
>>                            unsigned int scale_factor, long lval)
>>   {
>>          u32 nval;
>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>> *ddat, i915_reg_t rgadr,
>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -       bits_to_clear = field_msk;
>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>> +       bits_to_clear = PKG_PWR_LIM_1;
>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>
>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>                                              bits_to_clear, bits_to_set);
>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>> attr, int chan, long val)
>>          case hwmon_power_max:
>>                  hwm_field_scale_and_write(ddat,
>>                                            hwmon->rg.pkg_rapl_limit,
>> -                                         PKG_PWR_LIM_1,
>>                                            hwmon->scl_shift_power,
>>                                            SF_POWER, val);
>>                  return 0;
>> ```
>> Though I'm not sure if you're planning to add further callsites of
>> hwm_field_scale_and_write with different field_masks?
> 
> I have reasons for keeping it this way, it's there in the link above if you
> are interested.
> 
>>
>> Alternatively, (without the above diff),
>>
>> ```
>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>> index c9be1657f03d..6f40f12bcf89 100644
>> --- a/include/linux/bitfield.h
>> +++ b/include/linux/bitfield.h
>> @@ -8,6 +8,7 @@
>>   #define _LINUX_BITFIELD_H
>>
>>   #include <linux/build_bug.h>
>> +#include <linux/const.h>
>>   #include <asm/byteorder.h>
>>
>>   /*
>> @@ -62,7 +63,7 @@
>>
>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>          ({                                                              \
>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>                                   _pfx "mask is not constant");          \
>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>> ```
>> will produce:
>> error: call to __compiletime_assert_407 declared with 'error'
>> attribute: FIELD_PREP: mask is not constant
>>
>> I haven't tested if that change is also feasible (on top of fixing
>> this specific instance), but I think it might help avoid more of these
>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>> compiler version, optimization level.
> 
> Not disagreeing, can do something here if needed.
> 
> Thanks.
> --
> Ashutosh

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-28  6:26                   ` Gwan-gyeong Mun
  0 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-28  6:26 UTC (permalink / raw)
  To: Dixit, Ashutosh, Nick Desaulniers; +Cc: intel-gfx, llvm, linux-kernel

Hi all,

I should have written the commit message more accurately, but it seems 
that it was written inaccurately.

If the FIELD_PREP macro is expanded, the following macros are used.

#define FIELD_PREP(_mask, _val)						\
	({								\
		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
	})


#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
	({								\
		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
				 _pfx "mask is not constant");		\
		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
				 _pfx "value too large for the field"); \
		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \
		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
					      (1ULL << __bf_shf(_mask))); \
	})

Among them, a build error is generated by the lower part of the 
__BF_FIELD_CHECK() macro.

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \


Here, if you apply an argument to this macro, it will look like the 
following.

__bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)

The result is always false because an unsigned int value of type 
field_msk is not always greater than the maximum value of unsigned long 
long .
So, a build error occurs due to the following part of the clang compiler 
option.

[-Werror,-Wtautological-constant-out-of-range-compare]

You can simply override this warning in Clang by adding the build option 
below, but this seems like a bad attempt

i915/Makefile
CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare

The easiest way to solve this is to use a constant value, not a 
variable, as an argument to FIELD_PREP.

And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
expression as the first argument, it cannot be changed with this macro 
alone in the existing code, it must be changed to input a constant value 
as shown below.

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 08c921421a5f..abb3a194c548 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,

  static void
  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         const u32 field_msk, int nshift,
+                         int nshift,
                           unsigned int scale_factor, long lval)
  {
         u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
         /* Computation in 64-bits to avoid overflow. Round to nearest. */
         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = REG_FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);

         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                             bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
int chan, long val)
         case hwmon_power_max:
                 hwm_field_scale_and_write(ddat,
                                           hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                           hwmon->scl_shift_power,
                                           SF_POWER, val);
                 return 0;



In addition, if there is no build problem regardless of the size of the 
type as the first argument in FIELD_PREP, it is possible through the 
following modification.
(Since this modification modifies include/linux/bitfield.h , I will send 
it as a separate patch.
   )

However, it seems that we need to have Jani's confirm whether it is okay 
to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
return type.

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6e96799b6f38 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -9,7 +9,7 @@

  #include <linux/build_bug.h>
  #include <asm/byteorder.h>
-
+#include <linux/overflow.h>
  /*
   * Bitfield access macros
   *
@@ -69,7 +69,7 @@
                                  ~((_mask) >> __bf_shf(_mask)) & (_val) 
: 0, \
                                  _pfx "value too large for the field"); \
                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
-                                __bf_cast_unsigned(_reg, ~0ull),       \
+                                __bf_cast_unsigned(_reg, 
type_max(__unsigned_scalar_typeof(_reg))),    \
                                  _pfx "type of reg too small for mask"); \
                 __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
                                               (1ULL << __bf_shf(_mask))); \
@@ -84,7 +84,7 @@
   */
  #define FIELD_MAX(_mask)                                               \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
                 (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
         })

@@ -97,7 +97,7 @@
   */
  #define FIELD_FIT(_mask, _val)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
                 !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
         })

@@ -111,7 +111,7 @@
   */
  #define FIELD_PREP(_mask, _val) 
          \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
                 ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
         })

@@ -125,7 +125,7 @@
   */
  #define FIELD_GET(_mask, _reg)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
+               __BF_FIELD_CHECK(_mask, _reg, 
type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
                 (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
         })


Br,

G.G.


On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>
> 
> Hi Nick,
> 
>> Thanks, I can repro now.
>>
>> I haven't detangled the macro soup, but I noticed:
>>
>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>> following comment:
>>   18  * Mask must be a compilation time constant.
> 
> I had comments about this here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> The relevant part being:
> 
> ---- {quote} ----
>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
> 
> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> ---- {end quote} ----
> 
>>
>> 2. hwm_field_scale_and_write only has one callsite.
>>
>> The following patch works:
> 
> If we need to fix it at our end yes we can come up with one of these
> patches. But we were hoping someone from clang/llvm can comment about the
> "type of reg too small for mask" stuff. If this is something which needs to
> be fixed in clang/llvm we probably don't want to hide the issue.
> 
>>
>> ```
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>> b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..6ac29d90b92a 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -                         u32 field_msk, int nshift,
>> +                         int nshift,
>>                            unsigned int scale_factor, long lval)
>>   {
>>          u32 nval;
>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>> *ddat, i915_reg_t rgadr,
>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -       bits_to_clear = field_msk;
>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>> +       bits_to_clear = PKG_PWR_LIM_1;
>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>
>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>                                              bits_to_clear, bits_to_set);
>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>> attr, int chan, long val)
>>          case hwmon_power_max:
>>                  hwm_field_scale_and_write(ddat,
>>                                            hwmon->rg.pkg_rapl_limit,
>> -                                         PKG_PWR_LIM_1,
>>                                            hwmon->scl_shift_power,
>>                                            SF_POWER, val);
>>                  return 0;
>> ```
>> Though I'm not sure if you're planning to add further callsites of
>> hwm_field_scale_and_write with different field_masks?
> 
> I have reasons for keeping it this way, it's there in the link above if you
> are interested.
> 
>>
>> Alternatively, (without the above diff),
>>
>> ```
>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>> index c9be1657f03d..6f40f12bcf89 100644
>> --- a/include/linux/bitfield.h
>> +++ b/include/linux/bitfield.h
>> @@ -8,6 +8,7 @@
>>   #define _LINUX_BITFIELD_H
>>
>>   #include <linux/build_bug.h>
>> +#include <linux/const.h>
>>   #include <asm/byteorder.h>
>>
>>   /*
>> @@ -62,7 +63,7 @@
>>
>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>          ({                                                              \
>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>                                   _pfx "mask is not constant");          \
>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>> ```
>> will produce:
>> error: call to __compiletime_assert_407 declared with 'error'
>> attribute: FIELD_PREP: mask is not constant
>>
>> I haven't tested if that change is also feasible (on top of fixing
>> this specific instance), but I think it might help avoid more of these
>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>> compiler version, optimization level.
> 
> Not disagreeing, can do something here if needed.
> 
> Thanks.
> --
> Ashutosh

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev3)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (5 preceding siblings ...)
  2022-10-27 17:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2) Patchwork
@ 2022-10-28  6:30 ` Patchwork
  2022-10-28  6:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev4) Patchwork
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-28  6:30 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev3)
URL   : https://patchwork.freedesktop.org/series/110094/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/110094/revisions/3/mbox/ not applied
Applying: drm/i915/hwmon: Fix a build error used with clang compiler
error: git diff header lacks filename information when removing 1 leading pathname component (line 2)
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/hwmon: Fix a build error used with clang compiler
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".



^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-27 18:32                 ` [Intel-gfx] " Dixit, Ashutosh
@ 2022-10-28  6:43                   ` Gwan-gyeong Mun
  -1 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-28  6:43 UTC (permalink / raw)
  To: Dixit, Ashutosh, Nick Desaulniers; +Cc: intel-gfx, llvm, linux-kernel

Resend, because some content was accidentally omitted from the previous 
reply.
Please ignore the previous email.

Hi all,

I should have written the original commit message more accurately, but 
it seems that it was written inaccurately.

If the FIELD_PREP macro is expanded, the following macros are used.

#define FIELD_PREP(_mask, _val)						\
	({								\
		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
	})


#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
	({								\
		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
				 _pfx "mask is not constant");		\
		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
				 _pfx "value too large for the field"); \
		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \
		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
					      (1ULL << __bf_shf(_mask))); \
	})

Among them, a build error is generated by the lower part of the 
__BF_FIELD_CHECK() macro.

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \


Here, if you apply an argument to this macro, it will look like the 
following.

__bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)

The result is always false because an unsigned int value of type 
field_msk is not always greater than the maximum value of unsigned long 
long .
So, a build error occurs due to the following part of the clang compiler 
option.

[-Werror,-Wtautological-constant-out-of-range-compare]

You can simply override this warning in Clang by adding the build option 
below, but this seems like a bad attempt

i915/Makefile
CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare

The easiest way to solve this is to use a constant value, not a 
variable, as an argument to FIELD_PREP.

And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
expression as the first argument, it cannot be changed with this macro 
alone in the existing code, it must be changed to input a constant value 
as shown below.

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 08c921421a5f..abb3a194c548 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,

  static void
  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         const u32 field_msk, int nshift,
+                         int nshift,
                           unsigned int scale_factor, long lval)
  {
         u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
         /* Computation in 64-bits to avoid overflow. Round to nearest. */
         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = REG_FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);

         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                             bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
int chan, long val)
         case hwmon_power_max:
                 hwm_field_scale_and_write(ddat,
                                           hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                           hwmon->scl_shift_power,
                                           SF_POWER, val);
                 return 0;



In addition, if there is no build problem regardless of the size of the 
type as the first argument in FIELD_PREP, it is possible through the 
following modification.
(Since this modification modifies include/linux/bitfield.h , I will send 
it as a separate patch.
   )

However, it seems that we need to have Jani's confirm whether it is okay 
to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
return type in i915.

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6e96799b6f38 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -9,7 +9,7 @@

  #include <linux/build_bug.h>
  #include <asm/byteorder.h>
-
+#include <linux/overflow.h>
  /*
   * Bitfield access macros
   *
@@ -69,7 +69,7 @@
                                  ~((_mask) >> __bf_shf(_mask)) & (_val) 
: 0, \
                                  _pfx "value too large for the field"); \
                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
-                                __bf_cast_unsigned(_reg, ~0ull),       \
+                                __bf_cast_unsigned(_reg, 
type_max(__unsigned_scalar_typeof(_reg))),    \
                                  _pfx "type of reg too small for mask"); \
                 __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
                                               (1ULL << __bf_shf(_mask))); \
@@ -84,7 +84,7 @@
   */
  #define FIELD_MAX(_mask)                                               \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
                 (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
         })

@@ -97,7 +97,7 @@
   */
  #define FIELD_FIT(_mask, _val)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
                 !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
         })

@@ -111,7 +111,7 @@
   */
  #define FIELD_PREP(_mask, _val) 
          \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
                 ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
         })

@@ -125,7 +125,7 @@
   */
  #define FIELD_GET(_mask, _reg)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
+               __BF_FIELD_CHECK(_mask, _reg, 
type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
                 (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
         })


Br,

G.G.

On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>
> 
> Hi Nick,
> 
>> Thanks, I can repro now.
>>
>> I haven't detangled the macro soup, but I noticed:
>>
>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>> following comment:
>>   18  * Mask must be a compilation time constant.
> 
> I had comments about this here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> The relevant part being:
> 
> ---- {quote} ----
>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
> 
> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> ---- {end quote} ----
> 
>>
>> 2. hwm_field_scale_and_write only has one callsite.
>>
>> The following patch works:
> 
> If we need to fix it at our end yes we can come up with one of these
> patches. But we were hoping someone from clang/llvm can comment about the
> "type of reg too small for mask" stuff. If this is something which needs to
> be fixed in clang/llvm we probably don't want to hide the issue.
> 
>>
>> ```
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>> b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..6ac29d90b92a 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -                         u32 field_msk, int nshift,
>> +                         int nshift,
>>                            unsigned int scale_factor, long lval)
>>   {
>>          u32 nval;
>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>> *ddat, i915_reg_t rgadr,
>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -       bits_to_clear = field_msk;
>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>> +       bits_to_clear = PKG_PWR_LIM_1;
>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>
>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>                                              bits_to_clear, bits_to_set);
>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>> attr, int chan, long val)
>>          case hwmon_power_max:
>>                  hwm_field_scale_and_write(ddat,
>>                                            hwmon->rg.pkg_rapl_limit,
>> -                                         PKG_PWR_LIM_1,
>>                                            hwmon->scl_shift_power,
>>                                            SF_POWER, val);
>>                  return 0;
>> ```
>> Though I'm not sure if you're planning to add further callsites of
>> hwm_field_scale_and_write with different field_masks?
> 
> I have reasons for keeping it this way, it's there in the link above if you
> are interested.
> 
>>
>> Alternatively, (without the above diff),
>>
>> ```
>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>> index c9be1657f03d..6f40f12bcf89 100644
>> --- a/include/linux/bitfield.h
>> +++ b/include/linux/bitfield.h
>> @@ -8,6 +8,7 @@
>>   #define _LINUX_BITFIELD_H
>>
>>   #include <linux/build_bug.h>
>> +#include <linux/const.h>
>>   #include <asm/byteorder.h>
>>
>>   /*
>> @@ -62,7 +63,7 @@
>>
>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>          ({                                                              \
>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>                                   _pfx "mask is not constant");          \
>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>> ```
>> will produce:
>> error: call to __compiletime_assert_407 declared with 'error'
>> attribute: FIELD_PREP: mask is not constant
>>
>> I haven't tested if that change is also feasible (on top of fixing
>> this specific instance), but I think it might help avoid more of these
>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>> compiler version, optimization level.
> 
> Not disagreeing, can do something here if needed.
> 
> Thanks.
> --
> Ashutosh

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-28  6:43                   ` Gwan-gyeong Mun
  0 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-28  6:43 UTC (permalink / raw)
  To: Dixit, Ashutosh, Nick Desaulniers
  Cc: anshuman.gupta, intel-gfx, llvm, linux-kernel, Andi Shyti, Jani Nikula

Resend, because some content was accidentally omitted from the previous 
reply.
Please ignore the previous email.

Hi all,

I should have written the original commit message more accurately, but 
it seems that it was written inaccurately.

If the FIELD_PREP macro is expanded, the following macros are used.

#define FIELD_PREP(_mask, _val)						\
	({								\
		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
	})


#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
	({								\
		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
				 _pfx "mask is not constant");		\
		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
				 _pfx "value too large for the field"); \
		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \
		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
					      (1ULL << __bf_shf(_mask))); \
	})

Among them, a build error is generated by the lower part of the 
__BF_FIELD_CHECK() macro.

		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
				 __bf_cast_unsigned(_reg, ~0ull),	\
				 _pfx "type of reg too small for mask"); \


Here, if you apply an argument to this macro, it will look like the 
following.

__bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)

The result is always false because an unsigned int value of type 
field_msk is not always greater than the maximum value of unsigned long 
long .
So, a build error occurs due to the following part of the clang compiler 
option.

[-Werror,-Wtautological-constant-out-of-range-compare]

You can simply override this warning in Clang by adding the build option 
below, but this seems like a bad attempt

i915/Makefile
CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare

The easiest way to solve this is to use a constant value, not a 
variable, as an argument to FIELD_PREP.

And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
expression as the first argument, it cannot be changed with this macro 
alone in the existing code, it must be changed to input a constant value 
as shown below.

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 08c921421a5f..abb3a194c548 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,

  static void
  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-                         const u32 field_msk, int nshift,
+                         int nshift,
                           unsigned int scale_factor, long lval)
  {
         u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
         /* Computation in 64-bits to avoid overflow. Round to nearest. */
         nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

-       bits_to_clear = field_msk;
-       bits_to_set = REG_FIELD_PREP(field_msk, nval);
+       bits_to_clear = PKG_PWR_LIM_1;
+       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);

         hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
                                             bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
int chan, long val)
         case hwmon_power_max:
                 hwm_field_scale_and_write(ddat,
                                           hwmon->rg.pkg_rapl_limit,
-                                         PKG_PWR_LIM_1,
                                           hwmon->scl_shift_power,
                                           SF_POWER, val);
                 return 0;



In addition, if there is no build problem regardless of the size of the 
type as the first argument in FIELD_PREP, it is possible through the 
following modification.
(Since this modification modifies include/linux/bitfield.h , I will send 
it as a separate patch.
   )

However, it seems that we need to have Jani's confirm whether it is okay 
to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
return type in i915.

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6e96799b6f38 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -9,7 +9,7 @@

  #include <linux/build_bug.h>
  #include <asm/byteorder.h>
-
+#include <linux/overflow.h>
  /*
   * Bitfield access macros
   *
@@ -69,7 +69,7 @@
                                  ~((_mask) >> __bf_shf(_mask)) & (_val) 
: 0, \
                                  _pfx "value too large for the field"); \
                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
-                                __bf_cast_unsigned(_reg, ~0ull),       \
+                                __bf_cast_unsigned(_reg, 
type_max(__unsigned_scalar_typeof(_reg))),    \
                                  _pfx "type of reg too small for mask"); \
                 __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
                                               (1ULL << __bf_shf(_mask))); \
@@ -84,7 +84,7 @@
   */
  #define FIELD_MAX(_mask)                                               \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
                 (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
         })

@@ -97,7 +97,7 @@
   */
  #define FIELD_FIT(_mask, _val)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), 
type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
                 !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
         })

@@ -111,7 +111,7 @@
   */
  #define FIELD_PREP(_mask, _val) 
          \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
+               __BF_FIELD_CHECK(_mask, 
type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
                 ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
         })

@@ -125,7 +125,7 @@
   */
  #define FIELD_GET(_mask, _reg)                                         \
         ({                                                              \
-               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
+               __BF_FIELD_CHECK(_mask, _reg, 
type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
                 (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
         })


Br,

G.G.

On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>
> 
> Hi Nick,
> 
>> Thanks, I can repro now.
>>
>> I haven't detangled the macro soup, but I noticed:
>>
>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>> following comment:
>>   18  * Mask must be a compilation time constant.
> 
> I had comments about this here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> The relevant part being:
> 
> ---- {quote} ----
>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> 
> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> also occurs here):
> 
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 
> So it goes through previous checks including the "mask is not constant"
> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> after most optimizations have run" so by that time both compilers (gcc and
> clang) have figured out that even though _mask is coming in as function
> argument it is really the constant below:
> 
> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
> 
> But it is not clear why clang chokes on this "type of reg too small for
> mask" check (and gcc doesn't) since everything is u32.
> ---- {end quote} ----
> 
>>
>> 2. hwm_field_scale_and_write only has one callsite.
>>
>> The following patch works:
> 
> If we need to fix it at our end yes we can come up with one of these
> patches. But we were hoping someone from clang/llvm can comment about the
> "type of reg too small for mask" stuff. If this is something which needs to
> be fixed in clang/llvm we probably don't want to hide the issue.
> 
>>
>> ```
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>> b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..6ac29d90b92a 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -                         u32 field_msk, int nshift,
>> +                         int nshift,
>>                            unsigned int scale_factor, long lval)
>>   {
>>          u32 nval;
>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>> *ddat, i915_reg_t rgadr,
>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -       bits_to_clear = field_msk;
>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>> +       bits_to_clear = PKG_PWR_LIM_1;
>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>
>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>                                              bits_to_clear, bits_to_set);
>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>> attr, int chan, long val)
>>          case hwmon_power_max:
>>                  hwm_field_scale_and_write(ddat,
>>                                            hwmon->rg.pkg_rapl_limit,
>> -                                         PKG_PWR_LIM_1,
>>                                            hwmon->scl_shift_power,
>>                                            SF_POWER, val);
>>                  return 0;
>> ```
>> Though I'm not sure if you're planning to add further callsites of
>> hwm_field_scale_and_write with different field_masks?
> 
> I have reasons for keeping it this way, it's there in the link above if you
> are interested.
> 
>>
>> Alternatively, (without the above diff),
>>
>> ```
>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>> index c9be1657f03d..6f40f12bcf89 100644
>> --- a/include/linux/bitfield.h
>> +++ b/include/linux/bitfield.h
>> @@ -8,6 +8,7 @@
>>   #define _LINUX_BITFIELD_H
>>
>>   #include <linux/build_bug.h>
>> +#include <linux/const.h>
>>   #include <asm/byteorder.h>
>>
>>   /*
>> @@ -62,7 +63,7 @@
>>
>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>          ({                                                              \
>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>                                   _pfx "mask is not constant");          \
>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>> ```
>> will produce:
>> error: call to __compiletime_assert_407 declared with 'error'
>> attribute: FIELD_PREP: mask is not constant
>>
>> I haven't tested if that change is also feasible (on top of fixing
>> this specific instance), but I think it might help avoid more of these
>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>> compiler version, optimization level.
> 
> Not disagreeing, can do something here if needed.
> 
> Thanks.
> --
> Ashutosh

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev4)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (6 preceding siblings ...)
  2022-10-28  6:30 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev3) Patchwork
@ 2022-10-28  6:48 ` Patchwork
  2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-28  6:48 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev4)
URL   : https://patchwork.freedesktop.org/series/110094/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/110094/revisions/4/mbox/ not applied
Applying: drm/i915/hwmon: Fix a build error used with clang compiler
error: git diff header lacks filename information when removing 1 leading pathname component (line 2)
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/hwmon: Fix a build error used with clang compiler
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".



^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-28  6:43                   ` Gwan-gyeong Mun
@ 2022-10-28  8:46                     ` Jani Nikula
  -1 siblings, 0 replies; 47+ messages in thread
From: Jani Nikula @ 2022-10-28  8:46 UTC (permalink / raw)
  To: Gwan-gyeong Mun, Dixit, Ashutosh, Nick Desaulniers
  Cc: anshuman.gupta, intel-gfx, llvm, linux-kernel, Andi Shyti

On Fri, 28 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
> Resend, because some content was accidentally omitted from the previous 
> reply.
> Please ignore the previous email.
>
> Hi all,
>
> I should have written the original commit message more accurately, but 
> it seems that it was written inaccurately.
>
> If the FIELD_PREP macro is expanded, the following macros are used.
>
> #define FIELD_PREP(_mask, _val)						\
> 	({								\
> 		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
> 		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
> 	})
>
>
> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
> 	({								\
> 		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
> 				 _pfx "mask is not constant");		\
> 		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
> 		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
> 				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
> 				 _pfx "value too large for the field"); \
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
> 					      (1ULL << __bf_shf(_mask))); \
> 	})
>
> Among them, a build error is generated by the lower part of the 
> __BF_FIELD_CHECK() macro.
>
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
>
>
> Here, if you apply an argument to this macro, it will look like the 
> following.
>
> __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
>
> The result is always false because an unsigned int value of type 
> field_msk is not always greater than the maximum value of unsigned long 
> long .
> So, a build error occurs due to the following part of the clang compiler 
> option.
>
> [-Werror,-Wtautological-constant-out-of-range-compare]
>
> You can simply override this warning in Clang by adding the build option 
> below, but this seems like a bad attempt
>
> i915/Makefile
> CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
>
> The easiest way to solve this is to use a constant value, not a 
> variable, as an argument to FIELD_PREP.
>
> And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
> expression as the first argument, it cannot be changed with this macro 
> alone in the existing code, it must be changed to input a constant value 
> as shown below.

We've added REG_FIELD_PREP() precisely to avoid the problems with the
types and ranges, as we want it to operate on u32. It also uses
__is_constexpr() to avoid dependencies on compiler implementation and
optimizations.

Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
interface if needed.

BR,
Jani.




>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 08c921421a5f..abb3a194c548 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
> i915_reg_t rgadr,
>
>   static void
>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -                         const u32 field_msk, int nshift,
> +                         int nshift,
>                            unsigned int scale_factor, long lval)
>   {
>          u32 nval;
> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
> i915_reg_t rgadr,
>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -       bits_to_clear = field_msk;
> -       bits_to_set = REG_FIELD_PREP(field_msk, nval);
> +       bits_to_clear = PKG_PWR_LIM_1;
> +       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
>
>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>                                              bits_to_clear, bits_to_set);
> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
> int chan, long val)
>          case hwmon_power_max:
>                  hwm_field_scale_and_write(ddat,
>                                            hwmon->rg.pkg_rapl_limit,
> -                                         PKG_PWR_LIM_1,
>                                            hwmon->scl_shift_power,
>                                            SF_POWER, val);
>                  return 0;
>
>
>
> In addition, if there is no build problem regardless of the size of the 
> type as the first argument in FIELD_PREP, it is possible through the 
> following modification.
> (Since this modification modifies include/linux/bitfield.h , I will send 
> it as a separate patch.
>    )
>
> However, it seems that we need to have Jani's confirm whether it is okay 
> to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
> return type in i915.
>
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index c9be1657f03d..6e96799b6f38 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -9,7 +9,7 @@
>
>   #include <linux/build_bug.h>
>   #include <asm/byteorder.h>
> -
> +#include <linux/overflow.h>
>   /*
>    * Bitfield access macros
>    *
> @@ -69,7 +69,7 @@
>                                   ~((_mask) >> __bf_shf(_mask)) & (_val) 
> : 0, \
>                                   _pfx "value too large for the field"); \
>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> -                                __bf_cast_unsigned(_reg, ~0ull),       \
> +                                __bf_cast_unsigned(_reg, 
> type_max(__unsigned_scalar_typeof(_reg))),    \
>                                   _pfx "type of reg too small for mask"); \
>                  __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>                                                (1ULL << __bf_shf(_mask))); \
> @@ -84,7 +84,7 @@
>    */
>   #define FIELD_MAX(_mask)                                               \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), 
> type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
>                  (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
>          })
>
> @@ -97,7 +97,7 @@
>    */
>   #define FIELD_FIT(_mask, _val)                                         \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), 
> type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
>                  !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
>          })
>
> @@ -111,7 +111,7 @@
>    */
>   #define FIELD_PREP(_mask, _val) 
>           \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
>                  ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>          })
>
> @@ -125,7 +125,7 @@
>    */
>   #define FIELD_GET(_mask, _reg)                                         \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
> +               __BF_FIELD_CHECK(_mask, _reg, 
> type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
>                  (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
>          })
>
>
> Br,
>
> G.G.
>
> On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
>> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>>
>> 
>> Hi Nick,
>> 
>>> Thanks, I can repro now.
>>>
>>> I haven't detangled the macro soup, but I noticed:
>>>
>>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>>> following comment:
>>>   18  * Mask must be a compilation time constant.
>> 
>> I had comments about this here:
>> 
>> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
>> 
>> The relevant part being:
>> 
>> ---- {quote} ----
>>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>> 
>> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
>> also occurs here):
>> 
>> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
>> 				 __bf_cast_unsigned(_reg, ~0ull),	\
>> 				 _pfx "type of reg too small for mask"); \
>> 
>> So it goes through previous checks including the "mask is not constant"
>> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
>> after most optimizations have run" so by that time both compilers (gcc and
>> clang) have figured out that even though _mask is coming in as function
>> argument it is really the constant below:
>> 
>> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
>> 
>> But it is not clear why clang chokes on this "type of reg too small for
>> mask" check (and gcc doesn't) since everything is u32.
>> ---- {end quote} ----
>> 
>>>
>>> 2. hwm_field_scale_and_write only has one callsite.
>>>
>>> The following patch works:
>> 
>> If we need to fix it at our end yes we can come up with one of these
>> patches. But we were hoping someone from clang/llvm can comment about the
>> "type of reg too small for mask" stuff. If this is something which needs to
>> be fixed in clang/llvm we probably don't want to hide the issue.
>> 
>>>
>>> ```
>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>> index 9e9781493025..6ac29d90b92a 100644
>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>
>>>   static void
>>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>> -                         u32 field_msk, int nshift,
>>> +                         int nshift,
>>>                            unsigned int scale_factor, long lval)
>>>   {
>>>          u32 nval;
>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>>> *ddat, i915_reg_t rgadr,
>>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>
>>> -       bits_to_clear = field_msk;
>>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>
>>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>                                              bits_to_clear, bits_to_set);
>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>>> attr, int chan, long val)
>>>          case hwmon_power_max:
>>>                  hwm_field_scale_and_write(ddat,
>>>                                            hwmon->rg.pkg_rapl_limit,
>>> -                                         PKG_PWR_LIM_1,
>>>                                            hwmon->scl_shift_power,
>>>                                            SF_POWER, val);
>>>                  return 0;
>>> ```
>>> Though I'm not sure if you're planning to add further callsites of
>>> hwm_field_scale_and_write with different field_masks?
>> 
>> I have reasons for keeping it this way, it's there in the link above if you
>> are interested.
>> 
>>>
>>> Alternatively, (without the above diff),
>>>
>>> ```
>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>> index c9be1657f03d..6f40f12bcf89 100644
>>> --- a/include/linux/bitfield.h
>>> +++ b/include/linux/bitfield.h
>>> @@ -8,6 +8,7 @@
>>>   #define _LINUX_BITFIELD_H
>>>
>>>   #include <linux/build_bug.h>
>>> +#include <linux/const.h>
>>>   #include <asm/byteorder.h>
>>>
>>>   /*
>>> @@ -62,7 +63,7 @@
>>>
>>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>>          ({                                                              \
>>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>>                                   _pfx "mask is not constant");          \
>>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>> ```
>>> will produce:
>>> error: call to __compiletime_assert_407 declared with 'error'
>>> attribute: FIELD_PREP: mask is not constant
>>>
>>> I haven't tested if that change is also feasible (on top of fixing
>>> this specific instance), but I think it might help avoid more of these
>>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>>> compiler version, optimization level.
>> 
>> Not disagreeing, can do something here if needed.
>> 
>> Thanks.
>> --
>> Ashutosh

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-10-28  8:46                     ` Jani Nikula
  0 siblings, 0 replies; 47+ messages in thread
From: Jani Nikula @ 2022-10-28  8:46 UTC (permalink / raw)
  To: Gwan-gyeong Mun, Dixit, Ashutosh, Nick Desaulniers
  Cc: intel-gfx, llvm, linux-kernel

On Fri, 28 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
> Resend, because some content was accidentally omitted from the previous 
> reply.
> Please ignore the previous email.
>
> Hi all,
>
> I should have written the original commit message more accurately, but 
> it seems that it was written inaccurately.
>
> If the FIELD_PREP macro is expanded, the following macros are used.
>
> #define FIELD_PREP(_mask, _val)						\
> 	({								\
> 		__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");	\
> 		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
> 	})
>
>
> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)			\
> 	({								\
> 		BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),		\
> 				 _pfx "mask is not constant");		\
> 		BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");	\
> 		BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?		\
> 				 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
> 				 _pfx "value too large for the field"); \
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
> 		__BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +			\
> 					      (1ULL << __bf_shf(_mask))); \
> 	})
>
> Among them, a build error is generated by the lower part of the 
> __BF_FIELD_CHECK() macro.
>
> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
> 				 __bf_cast_unsigned(_reg, ~0ull),	\
> 				 _pfx "type of reg too small for mask"); \
>
>
> Here, if you apply an argument to this macro, it will look like the 
> following.
>
> __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
>
> The result is always false because an unsigned int value of type 
> field_msk is not always greater than the maximum value of unsigned long 
> long .
> So, a build error occurs due to the following part of the clang compiler 
> option.
>
> [-Werror,-Wtautological-constant-out-of-range-compare]
>
> You can simply override this warning in Clang by adding the build option 
> below, but this seems like a bad attempt
>
> i915/Makefile
> CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
>
> The easiest way to solve this is to use a constant value, not a 
> variable, as an argument to FIELD_PREP.
>
> And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
> expression as the first argument, it cannot be changed with this macro 
> alone in the existing code, it must be changed to input a constant value 
> as shown below.

We've added REG_FIELD_PREP() precisely to avoid the problems with the
types and ranges, as we want it to operate on u32. It also uses
__is_constexpr() to avoid dependencies on compiler implementation and
optimizations.

Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
interface if needed.

BR,
Jani.




>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 08c921421a5f..abb3a194c548 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
> i915_reg_t rgadr,
>
>   static void
>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -                         const u32 field_msk, int nshift,
> +                         int nshift,
>                            unsigned int scale_factor, long lval)
>   {
>          u32 nval;
> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
> i915_reg_t rgadr,
>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -       bits_to_clear = field_msk;
> -       bits_to_set = REG_FIELD_PREP(field_msk, nval);
> +       bits_to_clear = PKG_PWR_LIM_1;
> +       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
>
>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>                                              bits_to_clear, bits_to_set);
> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
> int chan, long val)
>          case hwmon_power_max:
>                  hwm_field_scale_and_write(ddat,
>                                            hwmon->rg.pkg_rapl_limit,
> -                                         PKG_PWR_LIM_1,
>                                            hwmon->scl_shift_power,
>                                            SF_POWER, val);
>                  return 0;
>
>
>
> In addition, if there is no build problem regardless of the size of the 
> type as the first argument in FIELD_PREP, it is possible through the 
> following modification.
> (Since this modification modifies include/linux/bitfield.h , I will send 
> it as a separate patch.
>    )
>
> However, it seems that we need to have Jani's confirm whether it is okay 
> to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
> return type in i915.
>
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index c9be1657f03d..6e96799b6f38 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -9,7 +9,7 @@
>
>   #include <linux/build_bug.h>
>   #include <asm/byteorder.h>
> -
> +#include <linux/overflow.h>
>   /*
>    * Bitfield access macros
>    *
> @@ -69,7 +69,7 @@
>                                   ~((_mask) >> __bf_shf(_mask)) & (_val) 
> : 0, \
>                                   _pfx "value too large for the field"); \
>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> -                                __bf_cast_unsigned(_reg, ~0ull),       \
> +                                __bf_cast_unsigned(_reg, 
> type_max(__unsigned_scalar_typeof(_reg))),    \
>                                   _pfx "type of reg too small for mask"); \
>                  __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>                                                (1ULL << __bf_shf(_mask))); \
> @@ -84,7 +84,7 @@
>    */
>   #define FIELD_MAX(_mask)                                               \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), 
> type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
>                  (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
>          })
>
> @@ -97,7 +97,7 @@
>    */
>   #define FIELD_FIT(_mask, _val)                                         \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), 
> type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
>                  !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
>          })
>
> @@ -111,7 +111,7 @@
>    */
>   #define FIELD_PREP(_mask, _val) 
>           \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> +               __BF_FIELD_CHECK(_mask, 
> type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
>                  ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>          })
>
> @@ -125,7 +125,7 @@
>    */
>   #define FIELD_GET(_mask, _reg)                                         \
>          ({                                                              \
> -               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
> +               __BF_FIELD_CHECK(_mask, _reg, 
> type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
>                  (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
>          })
>
>
> Br,
>
> G.G.
>
> On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
>> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>>
>> 
>> Hi Nick,
>> 
>>> Thanks, I can repro now.
>>>
>>> I haven't detangled the macro soup, but I noticed:
>>>
>>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>>> following comment:
>>>   18  * Mask must be a compilation time constant.
>> 
>> I had comments about this here:
>> 
>> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
>> 
>> The relevant part being:
>> 
>> ---- {quote} ----
>>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>> 
>> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
>> also occurs here):
>> 
>> 		BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >	\
>> 				 __bf_cast_unsigned(_reg, ~0ull),	\
>> 				 _pfx "type of reg too small for mask"); \
>> 
>> So it goes through previous checks including the "mask is not constant"
>> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
>> after most optimizations have run" so by that time both compilers (gcc and
>> clang) have figured out that even though _mask is coming in as function
>> argument it is really the constant below:
>> 
>> #define   PKG_PWR_LIM_1		REG_GENMASK(14, 0)
>> 
>> But it is not clear why clang chokes on this "type of reg too small for
>> mask" check (and gcc doesn't) since everything is u32.
>> ---- {end quote} ----
>> 
>>>
>>> 2. hwm_field_scale_and_write only has one callsite.
>>>
>>> The following patch works:
>> 
>> If we need to fix it at our end yes we can come up with one of these
>> patches. But we were hoping someone from clang/llvm can comment about the
>> "type of reg too small for mask" stuff. If this is something which needs to
>> be fixed in clang/llvm we probably don't want to hide the issue.
>> 
>>>
>>> ```
>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>> index 9e9781493025..6ac29d90b92a 100644
>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>
>>>   static void
>>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>> -                         u32 field_msk, int nshift,
>>> +                         int nshift,
>>>                            unsigned int scale_factor, long lval)
>>>   {
>>>          u32 nval;
>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>>> *ddat, i915_reg_t rgadr,
>>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>
>>> -       bits_to_clear = field_msk;
>>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>
>>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>                                              bits_to_clear, bits_to_set);
>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>>> attr, int chan, long val)
>>>          case hwmon_power_max:
>>>                  hwm_field_scale_and_write(ddat,
>>>                                            hwmon->rg.pkg_rapl_limit,
>>> -                                         PKG_PWR_LIM_1,
>>>                                            hwmon->scl_shift_power,
>>>                                            SF_POWER, val);
>>>                  return 0;
>>> ```
>>> Though I'm not sure if you're planning to add further callsites of
>>> hwm_field_scale_and_write with different field_masks?
>> 
>> I have reasons for keeping it this way, it's there in the link above if you
>> are interested.
>> 
>>>
>>> Alternatively, (without the above diff),
>>>
>>> ```
>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>> index c9be1657f03d..6f40f12bcf89 100644
>>> --- a/include/linux/bitfield.h
>>> +++ b/include/linux/bitfield.h
>>> @@ -8,6 +8,7 @@
>>>   #define _LINUX_BITFIELD_H
>>>
>>>   #include <linux/build_bug.h>
>>> +#include <linux/const.h>
>>>   #include <asm/byteorder.h>
>>>
>>>   /*
>>> @@ -62,7 +63,7 @@
>>>
>>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>>          ({                                                              \
>>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>>                                   _pfx "mask is not constant");          \
>>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>> ```
>>> will produce:
>>> error: call to __compiletime_assert_407 declared with 'error'
>>> attribute: FIELD_PREP: mask is not constant
>>>
>>> I haven't tested if that change is also feasible (on top of fixing
>>> this specific instance), but I think it might help avoid more of these
>>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>>> compiler version, optimization level.
>> 
>> Not disagreeing, can do something here if needed.
>> 
>> Thanks.
>> --
>> Ashutosh

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (7 preceding siblings ...)
  2022-10-28  6:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev4) Patchwork
@ 2022-10-29  4:42 ` Gwan-gyeong Mun
  2022-10-31  5:19   ` Dixit, Ashutosh
  2022-11-02  7:12   ` Dixit, Ashutosh
  2022-10-29  5:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler (rev5) Patchwork
                   ` (2 subsequent siblings)
  11 siblings, 2 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-29  4:42 UTC (permalink / raw)
  To: andi.shyti; +Cc: intel-gfx

Use REG_FIELD_PREP() and a constant value for hwm_field_scale_and_write()

If the first argument of FIELD_PREP() is not a compile-time constant value
or unsigned long long type, this routine of the __BF_FIELD_CHECK() macro
used internally by the FIELD_PREP() macro always returns false.

 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >      \
                  __bf_cast_unsigned(_reg, ~0ull),        \
                  _pfx "type of reg too small for mask"); \

And it returns a build error by the option among the clang
compilation options. [-Werror,-Wtautological-constant-out-of-range-compare]

Reported build error while using clang compiler:

drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
        bits_to_set = FIELD_PREP(field_msk, nval);
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
                __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
                                    ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
        __compiletime_assert(condition, msg, prefix, suffix)
        ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
                if (!(condition))                                       \

v2: Use REG_FIELD_PREP() macro instead of FIELD_PREP() (Jani)

Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
---
 drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e9781493025..c588a17f97e9 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
 
 static void
 hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
-			  u32 field_msk, int nshift,
-			  unsigned int scale_factor, long lval)
+			  int nshift, unsigned int scale_factor, long lval)
 {
 	u32 nval;
-	u32 bits_to_clear;
-	u32 bits_to_set;
 
 	/* Computation in 64-bits to avoid overflow. Round to nearest. */
 	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
 
-	bits_to_clear = field_msk;
-	bits_to_set = FIELD_PREP(field_msk, nval);
-
 	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
-					    bits_to_clear, bits_to_set);
+					    PKG_PWR_LIM_1,
+					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
 }
 
 /*
@@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
 	case hwmon_power_max:
 		hwm_field_scale_and_write(ddat,
 					  hwmon->rg.pkg_rapl_limit,
-					  PKG_PWR_LIM_1,
 					  hwmon->scl_shift_power,
 					  SF_POWER, val);
 		return 0;
-- 
2.37.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (8 preceding siblings ...)
  2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
@ 2022-10-29  5:00 ` Patchwork
  2022-10-29  5:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
  2022-10-29 15:32 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-29  5:00 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
URL   : https://patchwork.freedesktop.org/series/110094/
State : warning

== Summary ==

Error: dim checkpatch failed
1fa009971802 drm/i915/hwmon: Fix a build error used with clang compiler
-:33: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#33: 
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

total: 0 errors, 1 warnings, 0 checks, 31 lines checked



^ permalink raw reply	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (9 preceding siblings ...)
  2022-10-29  5:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler (rev5) Patchwork
@ 2022-10-29  5:32 ` Patchwork
  2022-10-29 15:32 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-29  5:32 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 6182 bytes --]

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
URL   : https://patchwork.freedesktop.org/series/110094/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12318 -> Patchwork_110094v5
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/index.html

Participating hosts (39 -> 38)
------------------------------

  Additional (1): fi-snb-2520m 
  Missing    (2): fi-ctg-p8600 fi-icl-u2 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_110094v5:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@requests:
    - {bat-dg2-11}:       [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/bat-dg2-11/igt@i915_selftest@live@requests.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/bat-dg2-11/igt@i915_selftest@live@requests.html

  
Known issues
------------

  Here are the changes found in Patchwork_110094v5 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-hsw-g3258:       NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-hsw-g3258/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-hsw-4770:        NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-hsw-4770/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-snb-2520m:       NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-snb-2520m/igt@kms_chamelium@hdmi-crc-fast.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-snb-2520m:       NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-snb-2520m/igt@prime_vgem@basic-fence-flip.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0@smem:
    - {bat-adlm-1}:       [DMESG-WARN][7] ([i915#2867]) -> [PASS][8] +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/bat-adlm-1/igt@gem_exec_suspend@basic-s0@smem.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/bat-adlm-1/igt@gem_exec_suspend@basic-s0@smem.html

  * igt@i915_selftest@live@gt_pm:
    - {bat-rpls-2}:       [DMESG-FAIL][9] ([i915#4258]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
    - fi-hsw-4770:        [INCOMPLETE][11] ([i915#4785]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
    - fi-hsw-g3258:       [INCOMPLETE][13] ([i915#3303] / [i915#4785]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/fi-hsw-g3258/igt@i915_selftest@live@hangcheck.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/fi-hsw-g3258/igt@i915_selftest@live@hangcheck.html

  * igt@i915_selftest@live@migrate:
    - {bat-adlp-6}:       [INCOMPLETE][15] ([i915#7348]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/bat-adlp-6/igt@i915_selftest@live@migrate.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/bat-adlp-6/igt@i915_selftest@live@migrate.html

  * igt@i915_selftest@live@reset:
    - {bat-rpls-1}:       [DMESG-FAIL][17] ([i915#4983]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/bat-rpls-1/igt@i915_selftest@live@reset.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/bat-rpls-1/igt@i915_selftest@live@reset.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5537]: https://gitlab.freedesktop.org/drm/intel/issues/5537
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
  [i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348


Build changes
-------------

  * Linux: CI_DRM_12318 -> Patchwork_110094v5

  CI-20190529: 20190529
  CI_DRM_12318: 70b4045a34cc86a3be64f0c184378a0e1400c062 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7030: 79f028ce7a0e5003e108055e25f0333e14fd1aca @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110094v5: 70b4045a34cc86a3be64f0c184378a0e1400c062 @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

d731c0bb3deb drm/i915/hwmon: Fix a build error used with clang compiler

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/index.html

[-- Attachment #2: Type: text/html, Size: 6911 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
  2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
                   ` (10 preceding siblings ...)
  2022-10-29  5:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2022-10-29 15:32 ` Patchwork
  11 siblings, 0 replies; 47+ messages in thread
From: Patchwork @ 2022-10-29 15:32 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 23116 bytes --]

== Series Details ==

Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev5)
URL   : https://patchwork.freedesktop.org/series/110094/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12318_full -> Patchwork_110094v5_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_110094v5_full:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_hangman@engine-engine-error@vcs1:
    - {shard-dg1}:        [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-dg1-19/igt@i915_hangman@engine-engine-error@vcs1.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-dg1-19/igt@i915_hangman@engine-engine-error@vcs1.html

  
Known issues
------------

  Here are the changes found in Patchwork_110094v5_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_fair@basic-none@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][3] ([i915#2842])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@gem_exec_fair@basic-none@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         [PASS][5] -> [SKIP][6] ([i915#2190])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-tglb5/igt@gem_huc_copy@huc-copy.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb6/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
    - shard-skl:          NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl1/igt@gem_lmem_swapping@heavy-multi.html

  * igt@gem_lmem_swapping@verify-random-ccs:
    - shard-glk:          NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@gem_lmem_swapping@verify-random-ccs.html

  * igt@gem_pxp@create-regular-context-2:
    - shard-tglb:         NOTRUN -> [SKIP][9] ([i915#4270])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb3/igt@gem_pxp@create-regular-context-2.html

  * igt@gem_softpin@evict-single-offset:
    - shard-tglb:         [PASS][10] -> [FAIL][11] ([i915#4171])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-tglb6/igt@gem_softpin@evict-single-offset.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb1/igt@gem_softpin@evict-single-offset.html

  * igt@i915_suspend@forcewake:
    - shard-apl:          [PASS][12] -> [DMESG-WARN][13] ([i915#180])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-apl7/igt@i915_suspend@forcewake.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl6/igt@i915_suspend@forcewake.html

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
    - shard-glk:          NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +1 similar issue
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_cdclk@mode-transition:
    - shard-glk:          NOTRUN -> [SKIP][15] ([fdo#109271]) +52 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_cdclk@mode-transition.html

  * igt@kms_chamelium@dp-hpd-storm:
    - shard-skl:          NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +1 similar issue
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl1/igt@kms_chamelium@dp-hpd-storm.html

  * igt@kms_color_chamelium@ctm-max:
    - shard-glk:          NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_color_chamelium@ctm-max.html

  * igt@kms_cursor_crc@cursor-random-max-size:
    - shard-skl:          NOTRUN -> [SKIP][18] ([fdo#109271]) +41 similar issues
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl1/igt@kms_cursor_crc@cursor-random-max-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
    - shard-skl:          [PASS][19] -> [FAIL][20] ([i915#2346])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-glk:          NOTRUN -> [FAIL][21] ([i915#4767])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:
    - shard-glk:          NOTRUN -> [FAIL][22] ([i915#79])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1.html

  * igt@kms_flip@flip-vs-expired-vblank@c-dp1:
    - shard-apl:          [PASS][23] -> [FAIL][24] ([i915#79])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-apl6/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl2/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
    - shard-skl:          [PASS][25] -> [FAIL][26] ([i915#2122])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling@pipe-a-default-mode:
    - shard-iclb:         NOTRUN -> [SKIP][27] ([i915#3555]) +2 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling@pipe-a-default-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-default-mode:
    - shard-iclb:         NOTRUN -> [SKIP][28] ([i915#2672]) +5 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-default-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode:
    - shard-iclb:         NOTRUN -> [SKIP][29] ([i915#2587] / [i915#2672]) +3 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb5/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode:
    - shard-iclb:         NOTRUN -> [SKIP][30] ([i915#2672] / [i915#3555])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-cpu:
    - shard-tglb:         NOTRUN -> [SKIP][31] ([fdo#109280] / [fdo#111825]) +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-render:
    - shard-apl:          NOTRUN -> [SKIP][32] ([fdo#109271])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl6/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@psr-rgb565-draw-blt:
    - shard-skl:          [PASS][33] -> [DMESG-WARN][34] ([i915#1982])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl6/igt@kms_frontbuffer_tracking@psr-rgb565-draw-blt.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl4/igt@kms_frontbuffer_tracking@psr-rgb565-draw-blt.html

  * igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-b-hdmi-a-2:
    - shard-glk:          NOTRUN -> [FAIL][35] ([i915#4573]) +2 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-b-hdmi-a-2.html

  * igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1:
    - shard-iclb:         [PASS][36] -> [SKIP][37] ([i915#5176]) +4 similar issues
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb8/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-edp-1.html

  * igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1:
    - shard-iclb:         [PASS][38] -> [SKIP][39] ([i915#5235]) +2 similar issues
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb8/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html

  * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf:
    - shard-glk:          NOTRUN -> [SKIP][40] ([fdo#109271] / [i915#658]) +1 similar issue
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area:
    - shard-skl:          NOTRUN -> [SKIP][41] ([fdo#109271] / [i915#658]) +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl1/igt@kms_psr2_sf@plane-move-sf-dmg-area.html

  * igt@kms_psr2_su@frontbuffer-xrgb8888:
    - shard-iclb:         NOTRUN -> [SKIP][42] ([fdo#109642] / [fdo#111068] / [i915#658]) +1 similar issue
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb5/igt@kms_psr2_su@frontbuffer-xrgb8888.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [PASS][43] -> [SKIP][44] ([fdo#109441]) +1 similar issue
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@perf@blocking:
    - shard-skl:          [PASS][45] -> [FAIL][46] ([i915#1542])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl6/igt@perf@blocking.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl10/igt@perf@blocking.html

  * igt@sysfs_clients@split-10:
    - shard-glk:          NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#2994])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@sysfs_clients@split-10.html

  
#### Possible fixes ####

  * igt@gem_exec_fair@basic-none-solo@rcs0:
    - shard-apl:          [FAIL][48] ([i915#2842]) -> [PASS][49]
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-apl8/igt@gem_exec_fair@basic-none-solo@rcs0.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl6/igt@gem_exec_fair@basic-none-solo@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-priority-all:
    - shard-tglb:         [DMESG-WARN][50] -> [PASS][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-tglb8/igt@gem_exec_whisper@basic-contexts-priority-all.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb3/igt@gem_exec_whisper@basic-contexts-priority-all.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          [DMESG-WARN][52] ([i915#180]) -> [PASS][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl6/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_concurrent@pipe-c@edp-1:
    - shard-tglb:         [INCOMPLETE][54] -> [PASS][55]
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-tglb8/igt@kms_concurrent@pipe-c@edp-1.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb3/igt@kms_concurrent@pipe-c@edp-1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
    - shard-iclb:         [DMESG-WARN][56] ([i915#2867]) -> [PASS][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb1/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb6/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html

  * igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1:
    - shard-skl:          [FAIL][58] ([i915#2122]) -> [PASS][59] +1 similar issue
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl10/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html

  * igt@kms_psr@psr2_sprite_mmap_cpu:
    - shard-iclb:         [SKIP][60] ([fdo#109441]) -> [PASS][61] +2 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_cpu.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
    - shard-skl:          [INCOMPLETE][62] -> [PASS][63]
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-skl10/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-skl1/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html

  * igt@kms_vblank@pipe-b-wait-busy-hang:
    - shard-snb:          [SKIP][64] ([fdo#109271]) -> [PASS][65]
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-snb4/igt@kms_vblank@pipe-b-wait-busy-hang.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-snb6/igt@kms_vblank@pipe-b-wait-busy-hang.html

  * igt@perf_pmu@busy-hang@vcs0:
    - shard-glk:          [DMESG-WARN][66] ([i915#118]) -> [PASS][67]
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-glk5/igt@perf_pmu@busy-hang@vcs0.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk5/igt@perf_pmu@busy-hang@vcs0.html

  
#### Warnings ####

  * igt@gem_pwrite@basic-exhaustion:
    - shard-apl:          [INCOMPLETE][68] ([i915#7248]) -> [WARN][69] ([i915#2658])
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-apl2/igt@gem_pwrite@basic-exhaustion.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-apl3/igt@gem_pwrite@basic-exhaustion.html
    - shard-tglb:         [INCOMPLETE][70] ([i915#7248]) -> [WARN][71] ([i915#2658])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-tglb5/igt@gem_pwrite@basic-exhaustion.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-tglb3/igt@gem_pwrite@basic-exhaustion.html
    - shard-glk:          [WARN][72] ([i915#2658]) -> [INCOMPLETE][73] ([i915#7248])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-glk7/igt@gem_pwrite@basic-exhaustion.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-glk2/igt@gem_pwrite@basic-exhaustion.html

  * igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
    - shard-iclb:         [SKIP][74] ([i915#658]) -> [SKIP][75] ([i915#2920])
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb8/igt@kms_psr2_sf@overlay-plane-move-continuous-sf.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_psr2_sf@overlay-plane-move-continuous-sf.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area:
    - shard-iclb:         [SKIP][76] ([i915#2920]) -> [SKIP][77] ([fdo#111068] / [i915#658]) +1 similar issue
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb5/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area:
    - shard-iclb:         [SKIP][78] ([fdo#111068] / [i915#658]) -> [SKIP][79] ([i915#2920]) +1 similar issue
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12318/shard-iclb8/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#1902]: https://gitlab.freedesktop.org/drm/intel/issues/1902
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
  [i915#2436]: https://gitlab.freedesktop.org/drm/intel/issues/2436
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
  [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3323]: https://gitlab.freedesktop.org/drm/intel/issues/3323
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
  [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4171]: https://gitlab.freedesktop.org/drm/intel/issues/4171
  [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
  [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
  [i915#4573]: https://gitlab.freedesktop.org/drm/intel/issues/4573
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4767]: https://gitlab.freedesktop.org/drm/intel/issues/4767
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#6230]: https://gitlab.freedesktop.org/drm/intel/issues/6230
  [i915#6335]: https://gitlab.freedesktop.org/drm/intel/issues/6335
  [i915#6412]: https://gitlab.freedesktop.org/drm/intel/issues/6412
  [i915#6433]: https://gitlab.freedesktop.org/drm/intel/issues/6433
  [i915#6524]: https://gitlab.freedesktop.org/drm/intel/issues/6524
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#6768]: https://gitlab.freedesktop.org/drm/intel/issues/6768
  [i915#7052]: https://gitlab.freedesktop.org/drm/intel/issues/7052
  [i915#7248]: https://gitlab.freedesktop.org/drm/intel/issues/7248
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79


Build changes
-------------

  * Linux: CI_DRM_12318 -> Patchwork_110094v5

  CI-20190529: 20190529
  CI_DRM_12318: 70b4045a34cc86a3be64f0c184378a0e1400c062 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7030: 79f028ce7a0e5003e108055e25f0333e14fd1aca @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110094v5: 70b4045a34cc86a3be64f0c184378a0e1400c062 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110094v5/index.html

[-- Attachment #2: Type: text/html, Size: 24786 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
@ 2022-10-31  5:19   ` Dixit, Ashutosh
  2022-10-31  6:37     ` Gwan-gyeong Mun
  2022-11-02  7:12   ` Dixit, Ashutosh
  1 sibling, 1 reply; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-31  5:19 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..c588a17f97e9 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>
>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> -
>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));

I registered my objection to this patch already here:

https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/

the crux of which is "hwm_field_scale_and_write() pairs with
hwm_field_read_and_scale() (they are basically a set/get pair) so it is
desirable they have identical arguments. This patch breaks that symmetry".

We can merge this patch now but the moment a second caller of
hwm_field_scale_and_write arrives this patch will need to be reverted.

I have also posted my preferred way (as I previously indiecated) of fixing
this issue here (if this needs to be fixed in i915):

https://patchwork.freedesktop.org/series/110301/

IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
here the mask comes in as a function argument whereas REG_FIELD_PREP and
FIELD_PREP require that mask to be a compile time constant.

Thanks.
--
Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-31  5:19   ` Dixit, Ashutosh
@ 2022-10-31  6:37     ` Gwan-gyeong Mun
  2022-10-31 17:31       ` Dixit, Ashutosh
  0 siblings, 1 reply; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-10-31  6:37 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: intel-gfx



On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
> On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..c588a17f97e9 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -			  u32 field_msk, int nshift,
>> -			  unsigned int scale_factor, long lval)
>> +			  int nshift, unsigned int scale_factor, long lval)
>>   {
>> 	u32 nval;
>> -	u32 bits_to_clear;
>> -	u32 bits_to_set;
>>
>> 	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>> 	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -	bits_to_clear = field_msk;
>> -	bits_to_set = FIELD_PREP(field_msk, nval);
>> -
>> 	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> -					    bits_to_clear, bits_to_set);
>> +					    PKG_PWR_LIM_1,
>> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
> 
> I registered my objection to this patch already here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> the crux of which is "hwm_field_scale_and_write() pairs with
> hwm_field_read_and_scale() (they are basically a set/get pair) so it is
> desirable they have identical arguments. This patch breaks that symmetry".
> 
> We can merge this patch now but the moment a second caller of
> hwm_field_scale_and_write arrives this patch will need to be reverted.
> 
> I have also posted my preferred way (as I previously indiecated) of fixing
> this issue here (if this needs to be fixed in i915):
> 
> https://patchwork.freedesktop.org/series/110301/
> 
The given link (https://patchwork.freedesktop.org/series/110301/) is an 
inline function that reduces the checks of REG_FIELD_PREP() and pursues 
the same functionality.
It's not a good idea to add and use duplicate new inline functions with 
reduced functionality under different names.

+/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
+static u32 hwm_field_prep(u32 mask, u32 val)
+{
+	return (val << __bf_shf(mask)) & mask;
+}
+
  static void
  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
  				    i915_reg_t reg, u32 clear, u32 set)
@@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
  	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

  	bits_to_clear = field_msk;
-	bits_to_set = FIELD_PREP(field_msk, nval);
+	bits_to_set = hwm_field_prep(field_msk, nval);

  	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
  					    bits_to_clear, bits_to_set);


The patch 
(https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5) 
that fixed the build error in a simplified form was added as there is 
only one place that calls the hwm_field_scale_and_write() function at 
this time.

If more places that use the hwm_field_scale_and_write() function are 
added in the future, how about changing the interface that calls this 
function as Jani previously suggested?

Br,
G.G.

> IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
> here the mask comes in as a function argument whereas REG_FIELD_PREP and
> FIELD_PREP require that mask to be a compile time constant.
> 
> Thanks.
> --
> Ashutosh

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-31  6:37     ` Gwan-gyeong Mun
@ 2022-10-31 17:31       ` Dixit, Ashutosh
  2022-11-01 10:35         ` Jani Nikula
  0 siblings, 1 reply; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-10-31 17:31 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

On Sun, 30 Oct 2022 23:37:59 -0700, Gwan-gyeong Mun wrote:
>

Hi GG,

> On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
> > On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> >> index 9e9781493025..c588a17f97e9 100644
> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >>
> >>   static void
> >>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >> -			  u32 field_msk, int nshift,
> >> -			  unsigned int scale_factor, long lval)
> >> +			  int nshift, unsigned int scale_factor, long lval)
> >>   {
> >>	u32 nval;
> >> -	u32 bits_to_clear;
> >> -	u32 bits_to_set;
> >>
> >>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
> >>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >>
> >> -	bits_to_clear = field_msk;
> >> -	bits_to_set = FIELD_PREP(field_msk, nval);
> >> -
> >>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> >> -					    bits_to_clear, bits_to_set);
> >> +					    PKG_PWR_LIM_1,
> >> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
> >
> > I registered my objection to this patch already here:
> >
> > https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> >
> > the crux of which is "hwm_field_scale_and_write() pairs with
> > hwm_field_read_and_scale() (they are basically a set/get pair) so it is
> > desirable they have identical arguments. This patch breaks that symmetry".
> >
> > We can merge this patch now but the moment a second caller of
> > hwm_field_scale_and_write arrives this patch will need to be reverted.
> >
> > I have also posted my preferred way (as I previously indiecated) of fixing
> > this issue here (if this needs to be fixed in i915):
> >
> > https://patchwork.freedesktop.org/series/110301/
> >
> The given link (https://patchwork.freedesktop.org/series/110301/) is an
> inline function that reduces the checks of REG_FIELD_PREP() and pursues the
> same functionality.
> It's not a good idea to add and use duplicate new inline functions with
> reduced functionality under different names.

See if you like v2 better :-)

> +/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
> +static u32 hwm_field_prep(u32 mask, u32 val)
> +{
> +	return (val << __bf_shf(mask)) & mask;
> +}
> +
>  static void
>  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
>				    i915_reg_t reg, u32 clear, u32 set)
> @@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
>	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> +	bits_to_set = hwm_field_prep(field_msk, nval);
>
>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>					    bits_to_clear, bits_to_set);
>
>
> The patch
> (https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5) that
> fixed the build error in a simplified form was added as there is only one
> place that calls the hwm_field_scale_and_write() function at this time.
>
> If more places that use the hwm_field_scale_and_write() function are added
> in the future, how about changing the interface that calls this function as
> Jani previously suggested?

Sorry, which interface change which Jani suggested are you referring to? I
don't recall seeing anything but maybe I am mistaken.

Thanks.
--
Ashutosh

> > IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
> > here the mask comes in as a function argument whereas REG_FIELD_PREP and
> > FIELD_PREP require that mask to be a compile time constant.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-31 17:31       ` Dixit, Ashutosh
@ 2022-11-01 10:35         ` Jani Nikula
  0 siblings, 0 replies; 47+ messages in thread
From: Jani Nikula @ 2022-11-01 10:35 UTC (permalink / raw)
  To: Dixit, Ashutosh, Gwan-gyeong Mun; +Cc: intel-gfx

On Mon, 31 Oct 2022, "Dixit, Ashutosh" <ashutosh.dixit@intel.com> wrote:
> On Sun, 30 Oct 2022 23:37:59 -0700, Gwan-gyeong Mun wrote:
>>
>
> Hi GG,
>
>> On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
>> > On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
>> >> index 9e9781493025..c588a17f97e9 100644
>> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> >> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> >>
>> >>   static void
>> >>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> >> -			  u32 field_msk, int nshift,
>> >> -			  unsigned int scale_factor, long lval)
>> >> +			  int nshift, unsigned int scale_factor, long lval)
>> >>   {
>> >>	u32 nval;
>> >> -	u32 bits_to_clear;
>> >> -	u32 bits_to_set;
>> >>
>> >>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>> >>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>> >>
>> >> -	bits_to_clear = field_msk;
>> >> -	bits_to_set = FIELD_PREP(field_msk, nval);
>> >> -
>> >>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> >> -					    bits_to_clear, bits_to_set);
>> >> +					    PKG_PWR_LIM_1,
>> >> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
>> >
>> > I registered my objection to this patch already here:
>> >
>> > https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
>> >
>> > the crux of which is "hwm_field_scale_and_write() pairs with
>> > hwm_field_read_and_scale() (they are basically a set/get pair) so it is
>> > desirable they have identical arguments. This patch breaks that symmetry".
>> >
>> > We can merge this patch now but the moment a second caller of
>> > hwm_field_scale_and_write arrives this patch will need to be reverted.
>> >
>> > I have also posted my preferred way (as I previously indiecated) of fixing
>> > this issue here (if this needs to be fixed in i915):
>> >
>> > https://patchwork.freedesktop.org/series/110301/
>> >
>> The given link (https://patchwork.freedesktop.org/series/110301/) is an
>> inline function that reduces the checks of REG_FIELD_PREP() and pursues the
>> same functionality.
>> It's not a good idea to add and use duplicate new inline functions with
>> reduced functionality under different names.
>
> See if you like v2 better :-)
>
>> +/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
>> +static u32 hwm_field_prep(u32 mask, u32 val)
>> +{
>> +	return (val << __bf_shf(mask)) & mask;
>> +}
>> +
>>  static void
>>  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
>>				    i915_reg_t reg, u32 clear, u32 set)
>> @@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>>	bits_to_clear = field_msk;
>> -	bits_to_set = FIELD_PREP(field_msk, nval);
>> +	bits_to_set = hwm_field_prep(field_msk, nval);
>>
>>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>					    bits_to_clear, bits_to_set);
>>
>>
>> The patch
>> (https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5) that
>> fixed the build error in a simplified form was added as there is only one
>> place that calls the hwm_field_scale_and_write() function at this time.
>>
>> If more places that use the hwm_field_scale_and_write() function are added
>> in the future, how about changing the interface that calls this function as
>> Jani previously suggested?
>
> Sorry, which interface change which Jani suggested are you referring to? I
> don't recall seeing anything but maybe I am mistaken.

Maybe it was in another context, but this looks like the interfaces are
built a bit too much on the registers. There are chains of single-use
functions that scale and lock and read/write register fields. And it's
all based on the assumption that any given value maps to a single
bitfield in a single register and can be handled with a single read or
rmw, and it falls part otherwise.

I think the registers should be abstracted at the lowest level,
completely, not brought in top down as register addresses and masks. For
inspiration, maybe look at intel_backlight.c.

So here, you'd have hwm_read/hwm_write levels completely agnostic about
all the details, just muxing to different items.

The hwm_*_read/hwm_*_write would operate in a domain that handles all
generic i915 stuff, but still would not know anything about registers or
scaling. And then you'd have the lowest, platform specific level that
you'd call via platform specific function pointers. They would be passed
and return values in the right scale (maybe using common helpers).

You would *not* have or initialize hwmon->rg register file. At all. The
platform specific functions would handle the correct registers inline,
directly.

To recap, the platform specific abstraction should be the platform
specific function pointers, like literally everywhere in the driver,
*not* platform specific register initializations.


BR,
Jani.




>
> Thanks.
> --
> Ashutosh
>
>> > IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
>> > here the mask comes in as a function argument whereas REG_FIELD_PREP and
>> > FIELD_PREP require that mask to be a compile time constant.

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-28  8:46                     ` [Intel-gfx] " Jani Nikula
  (?)
@ 2022-11-02  6:32                     ` Joonas Lahtinen
  2022-11-02 10:41                         ` Gwan-gyeong Mun
  -1 siblings, 1 reply; 47+ messages in thread
From: Joonas Lahtinen @ 2022-11-02  6:32 UTC (permalink / raw)
  To: Dixit, Ashutosh, Gwan-gyeong Mun, Jani Nikula, Nick Desaulniers
  Cc: intel-gfx, llvm, linux-kernel

Quoting Jani Nikula (2022-10-28 11:46:21)
> On Fri, 28 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
> > Resend, because some content was accidentally omitted from the previous 
> > reply.
> > Please ignore the previous email.
> >
> > Hi all,
> >
> > I should have written the original commit message more accurately, but 
> > it seems that it was written inaccurately.
> >
> > If the FIELD_PREP macro is expanded, the following macros are used.
> >
> > #define FIELD_PREP(_mask, _val)                                               \
> >       ({                                                              \
> >               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> >               ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
> >       })
> >
> >
> > #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                     \
> >       ({                                                              \
> >               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
> >                                _pfx "mask is not constant");          \
> >               BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
> >               BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
> >                                ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
> >                                _pfx "value too large for the field"); \
> >               BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >                                __bf_cast_unsigned(_reg, ~0ull),       \
> >                                _pfx "type of reg too small for mask"); \
> >               __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
> >                                             (1ULL << __bf_shf(_mask))); \
> >       })
> >
> > Among them, a build error is generated by the lower part of the 
> > __BF_FIELD_CHECK() macro.
> >
> >               BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >                                __bf_cast_unsigned(_reg, ~0ull),       \
> >                                _pfx "type of reg too small for mask"); \
> >
> >
> > Here, if you apply an argument to this macro, it will look like the 
> > following.
> >
> > __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
> >
> > The result is always false because an unsigned int value of type 
> > field_msk is not always greater than the maximum value of unsigned long 
> > long .
> > So, a build error occurs due to the following part of the clang compiler 
> > option.
> >
> > [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > You can simply override this warning in Clang by adding the build option 
> > below, but this seems like a bad attempt
> >
> > i915/Makefile
> > CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
> >
> > The easiest way to solve this is to use a constant value, not a 
> > variable, as an argument to FIELD_PREP.
> >
> > And since the REG_FIELD_PREP() macro suggested by Jani requires a const 
> > expression as the first argument, it cannot be changed with this macro 
> > alone in the existing code, it must be changed to input a constant value 
> > as shown below.
> 
> We've added REG_FIELD_PREP() precisely to avoid the problems with the
> types and ranges, as we want it to operate on u32. It also uses
> __is_constexpr() to avoid dependencies on compiler implementation and
> optimizations.
> 
> Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
> interface if needed.

Ashutosh and GG, can we get a fix for this merged ASAP. It's currently
blocking the drm-intel-gt-next pull request.

Regards, Joonas

> 
> BR,
> Jani.
> 
> 
> 
> 
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 08c921421a5f..abb3a194c548 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
> > i915_reg_t rgadr,
> >
> >   static void
> >   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> > -                         const u32 field_msk, int nshift,
> > +                         int nshift,
> >                            unsigned int scale_factor, long lval)
> >   {
> >          u32 nval;
> > @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
> > i915_reg_t rgadr,
> >          /* Computation in 64-bits to avoid overflow. Round to nearest. */
> >          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >
> > -       bits_to_clear = field_msk;
> > -       bits_to_set = REG_FIELD_PREP(field_msk, nval);
> > +       bits_to_clear = PKG_PWR_LIM_1;
> > +       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
> >
> >          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> >                                              bits_to_clear, bits_to_set);
> > @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, 
> > int chan, long val)
> >          case hwmon_power_max:
> >                  hwm_field_scale_and_write(ddat,
> >                                            hwmon->rg.pkg_rapl_limit,
> > -                                         PKG_PWR_LIM_1,
> >                                            hwmon->scl_shift_power,
> >                                            SF_POWER, val);
> >                  return 0;
> >
> >
> >
> > In addition, if there is no build problem regardless of the size of the 
> > type as the first argument in FIELD_PREP, it is possible through the 
> > following modification.
> > (Since this modification modifies include/linux/bitfield.h , I will send 
> > it as a separate patch.
> >    )
> >
> > However, it seems that we need to have Jani's confirm whether it is okay 
> > to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32 
> > return type in i915.
> >
> > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > index c9be1657f03d..6e96799b6f38 100644
> > --- a/include/linux/bitfield.h
> > +++ b/include/linux/bitfield.h
> > @@ -9,7 +9,7 @@
> >
> >   #include <linux/build_bug.h>
> >   #include <asm/byteorder.h>
> > -
> > +#include <linux/overflow.h>
> >   /*
> >    * Bitfield access macros
> >    *
> > @@ -69,7 +69,7 @@
> >                                   ~((_mask) >> __bf_shf(_mask)) & (_val) 
> > : 0, \
> >                                   _pfx "value too large for the field"); \
> >                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> > -                                __bf_cast_unsigned(_reg, ~0ull),       \
> > +                                __bf_cast_unsigned(_reg, 
> > type_max(__unsigned_scalar_typeof(_reg))),    \
> >                                   _pfx "type of reg too small for mask"); \
> >                  __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
> >                                                (1ULL << __bf_shf(_mask))); \
> > @@ -84,7 +84,7 @@
> >    */
> >   #define FIELD_MAX(_mask)                                               \
> >          ({                                                              \
> > -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
> > +               __BF_FIELD_CHECK(_mask, 
> > type_min(__unsigned_scalar_typeof(_mask)), 
> > type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
> >                  (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
> >          })
> >
> > @@ -97,7 +97,7 @@
> >    */
> >   #define FIELD_FIT(_mask, _val)                                         \
> >          ({                                                              \
> > -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
> > +               __BF_FIELD_CHECK(_mask, 
> > type_min(__unsigned_scalar_typeof(_mask)), 
> > type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
> >                  !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
> >          })
> >
> > @@ -111,7 +111,7 @@
> >    */
> >   #define FIELD_PREP(_mask, _val) 
> >           \
> >          ({                                                              \
> > -               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
> > +               __BF_FIELD_CHECK(_mask, 
> > type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
> >                  ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
> >          })
> >
> > @@ -125,7 +125,7 @@
> >    */
> >   #define FIELD_GET(_mask, _reg)                                         \
> >          ({                                                              \
> > -               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
> > +               __BF_FIELD_CHECK(_mask, _reg, 
> > type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
> >                  (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
> >          })
> >
> >
> > Br,
> >
> > G.G.
> >
> > On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
> >> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
> >>>
> >> 
> >> Hi Nick,
> >> 
> >>> Thanks, I can repro now.
> >>>
> >>> I haven't detangled the macro soup, but I noticed:
> >>>
> >>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
> >>> following comment:
> >>>   18  * Mask must be a compilation time constant.
> >> 
> >> I had comments about this here:
> >> 
> >> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> >> 
> >> The relevant part being:
> >> 
> >> ---- {quote} ----
> >>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
> >>>>>                  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >> 
> >> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
> >> also occurs here):
> >> 
> >>              BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
> >>                               __bf_cast_unsigned(_reg, ~0ull),       \
> >>                               _pfx "type of reg too small for mask"); \
> >> 
> >> So it goes through previous checks including the "mask is not constant"
> >> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
> >> after most optimizations have run" so by that time both compilers (gcc and
> >> clang) have figured out that even though _mask is coming in as function
> >> argument it is really the constant below:
> >> 
> >> #define   PKG_PWR_LIM_1              REG_GENMASK(14, 0)
> >> 
> >> But it is not clear why clang chokes on this "type of reg too small for
> >> mask" check (and gcc doesn't) since everything is u32.
> >> ---- {end quote} ----
> >> 
> >>>
> >>> 2. hwm_field_scale_and_write only has one callsite.
> >>>
> >>> The following patch works:
> >> 
> >> If we need to fix it at our end yes we can come up with one of these
> >> patches. But we were hoping someone from clang/llvm can comment about the
> >> "type of reg too small for mask" stuff. If this is something which needs to
> >> be fixed in clang/llvm we probably don't want to hide the issue.
> >> 
> >>>
> >>> ```
> >>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> >>> b/drivers/gpu/drm/i915/i915_hwmon.c
> >>> index 9e9781493025..6ac29d90b92a 100644
> >>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> >>> i915_reg_t rgadr,
> >>>
> >>>   static void
> >>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >>> -                         u32 field_msk, int nshift,
> >>> +                         int nshift,
> >>>                            unsigned int scale_factor, long lval)
> >>>   {
> >>>          u32 nval;
> >>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
> >>> *ddat, i915_reg_t rgadr,
> >>>          /* Computation in 64-bits to avoid overflow. Round to nearest. */
> >>>          nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >>>
> >>> -       bits_to_clear = field_msk;
> >>> -       bits_to_set = FIELD_PREP(field_msk, nval);
> >>> +       bits_to_clear = PKG_PWR_LIM_1;
> >>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
> >>>
> >>>          hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> >>>                                              bits_to_clear, bits_to_set);
> >>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
> >>> attr, int chan, long val)
> >>>          case hwmon_power_max:
> >>>                  hwm_field_scale_and_write(ddat,
> >>>                                            hwmon->rg.pkg_rapl_limit,
> >>> -                                         PKG_PWR_LIM_1,
> >>>                                            hwmon->scl_shift_power,
> >>>                                            SF_POWER, val);
> >>>                  return 0;
> >>> ```
> >>> Though I'm not sure if you're planning to add further callsites of
> >>> hwm_field_scale_and_write with different field_masks?
> >> 
> >> I have reasons for keeping it this way, it's there in the link above if you
> >> are interested.
> >> 
> >>>
> >>> Alternatively, (without the above diff),
> >>>
> >>> ```
> >>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> >>> index c9be1657f03d..6f40f12bcf89 100644
> >>> --- a/include/linux/bitfield.h
> >>> +++ b/include/linux/bitfield.h
> >>> @@ -8,6 +8,7 @@
> >>>   #define _LINUX_BITFIELD_H
> >>>
> >>>   #include <linux/build_bug.h>
> >>> +#include <linux/const.h>
> >>>   #include <asm/byteorder.h>
> >>>
> >>>   /*
> >>> @@ -62,7 +63,7 @@
> >>>
> >>>   #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
> >>>          ({                                                              \
> >>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
> >>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
> >>>                                   _pfx "mask is not constant");          \
> >>>                  BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
> >>>                  BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
> >>> ```
> >>> will produce:
> >>> error: call to __compiletime_assert_407 declared with 'error'
> >>> attribute: FIELD_PREP: mask is not constant
> >>>
> >>> I haven't tested if that change is also feasible (on top of fixing
> >>> this specific instance), but I think it might help avoid more of these
> >>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
> >>> compiler version, optimization level.
> >> 
> >> Not disagreeing, can do something here if needed.
> >> 
> >> Thanks.
> >> --
> >> Ashutosh
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
  2022-10-31  5:19   ` Dixit, Ashutosh
@ 2022-11-02  7:12   ` Dixit, Ashutosh
  2022-11-02  8:50     ` Jani Nikula
  1 sibling, 1 reply; 47+ messages in thread
From: Dixit, Ashutosh @ 2022-11-02  7:12 UTC (permalink / raw)
  To: Gwan-gyeong Mun; +Cc: intel-gfx

On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>
> Use REG_FIELD_PREP() and a constant value for hwm_field_scale_and_write()

R-b'ing this so that this can get merged since this compile break is
blocking drm-intel-gt-next pull request:

Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>

> If the first argument of FIELD_PREP() is not a compile-time constant value
> or unsigned long long type, this routine of the __BF_FIELD_CHECK() macro
> used internally by the FIELD_PREP() macro always returns false.
>
>  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >      \
>                   __bf_cast_unsigned(_reg, ~0ull),        \
>                   _pfx "type of reg too small for mask"); \
>
> And it returns a build error by the option among the clang
> compilation options. [-Werror,-Wtautological-constant-out-of-range-compare]
>
> Reported build error while using clang compiler:
>
> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>         bits_to_set = FIELD_PREP(field_msk, nval);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>         __compiletime_assert(condition, msg, prefix, suffix)
>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>                 if (!(condition))                                       \
>
> v2: Use REG_FIELD_PREP() macro instead of FIELD_PREP() (Jani)
>
> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..c588a17f97e9 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>
>  static void
>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> -			  u32 field_msk, int nshift,
> -			  unsigned int scale_factor, long lval)
> +			  int nshift, unsigned int scale_factor, long lval)
>  {
>	u32 nval;
> -	u32 bits_to_clear;
> -	u32 bits_to_set;
>
>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> -	bits_to_clear = field_msk;
> -	bits_to_set = FIELD_PREP(field_msk, nval);
> -
>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> -					    bits_to_clear, bits_to_set);
> +					    PKG_PWR_LIM_1,
> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
>  }
>
>  /*
> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>	case hwmon_power_max:
>		hwm_field_scale_and_write(ddat,
>					  hwmon->rg.pkg_rapl_limit,
> -					  PKG_PWR_LIM_1,
>					  hwmon->scl_shift_power,
>					  SF_POWER, val);
>		return 0;
> --
> 2.37.1
>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-11-02  7:12   ` Dixit, Ashutosh
@ 2022-11-02  8:50     ` Jani Nikula
  0 siblings, 0 replies; 47+ messages in thread
From: Jani Nikula @ 2022-11-02  8:50 UTC (permalink / raw)
  To: Dixit, Ashutosh, Gwan-gyeong Mun; +Cc: intel-gfx

On Wed, 02 Nov 2022, "Dixit, Ashutosh" <ashutosh.dixit@intel.com> wrote:
> On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>>
>> Use REG_FIELD_PREP() and a constant value for hwm_field_scale_and_write()
>
> R-b'ing this so that this can get merged since this compile break is
> blocking drm-intel-gt-next pull request:
>
> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>

Acked-by: Jani Nikula <jani.nikula@intel.com>

on this one as the stopgap measure.

>
>> If the first argument of FIELD_PREP() is not a compile-time constant value
>> or unsigned long long type, this routine of the __BF_FIELD_CHECK() macro
>> used internally by the FIELD_PREP() macro always returns false.
>>
>>  BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >      \
>>                   __bf_cast_unsigned(_reg, ~0ull),        \
>>                   _pfx "type of reg too small for mask"); \
>>
>> And it returns a build error by the option among the clang
>> compilation options. [-Werror,-Wtautological-constant-out-of-range-compare]
>>
>> Reported build error while using clang compiler:
>>
>> drivers/gpu/drm/i915/i915_hwmon.c:115:16: error: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((field_msk), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: (unsigned long long)0, default: (field_msk)))' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>>         bits_to_set = FIELD_PREP(field_msk, nval);
>>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
>>                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>                 BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
>> ./include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
>>                                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
>> ./include/linux/compiler_types.h:357:22: note: expanded from macro 'compiletime_assert'
>>         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/compiler_types.h:345:23: note: expanded from macro '_compiletime_assert'
>>         __compiletime_assert(condition, msg, prefix, suffix)
>>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/compiler_types.h:337:9: note: expanded from macro '__compiletime_assert'
>>                 if (!(condition))                                       \
>>
>> v2: Use REG_FIELD_PREP() macro instead of FIELD_PREP() (Jani)
>>
>> Fixes: 99f55efb7911 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
>> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
>> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_hwmon.c | 12 +++---------
>>  1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..c588a17f97e9 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>
>>  static void
>>  hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -			  u32 field_msk, int nshift,
>> -			  unsigned int scale_factor, long lval)
>> +			  int nshift, unsigned int scale_factor, long lval)
>>  {
>>	u32 nval;
>> -	u32 bits_to_clear;
>> -	u32 bits_to_set;
>>
>>	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>>	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -	bits_to_clear = field_msk;
>> -	bits_to_set = FIELD_PREP(field_msk, nval);
>> -
>>	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> -					    bits_to_clear, bits_to_set);
>> +					    PKG_PWR_LIM_1,
>> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
>>  }
>>
>>  /*
>> @@ -406,7 +401,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
>>	case hwmon_power_max:
>>		hwm_field_scale_and_write(ddat,
>>					  hwmon->rg.pkg_rapl_limit,
>> -					  PKG_PWR_LIM_1,
>>					  hwmon->scl_shift_power,
>>					  SF_POWER, val);
>>		return 0;
>> --
>> 2.37.1
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
  2022-11-02  6:32                     ` Joonas Lahtinen
@ 2022-11-02 10:41                         ` Gwan-gyeong Mun
  0 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-11-02 10:41 UTC (permalink / raw)
  To: Joonas Lahtinen, Dixit, Ashutosh, Jani Nikula, Nick Desaulniers
  Cc: intel-gfx, llvm, linux-kernel



On 11/2/22 8:32 AM, Joonas Lahtinen wrote:
> Quoting Jani Nikula (2022-10-28 11:46:21)
>> On Fri, 28 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
>>> Resend, because some content was accidentally omitted from the previous
>>> reply.
>>> Please ignore the previous email.
>>>
>>> Hi all,
>>>
>>> I should have written the original commit message more accurately, but
>>> it seems that it was written inaccurately.
>>>
>>> If the FIELD_PREP macro is expanded, the following macros are used.
>>>
>>> #define FIELD_PREP(_mask, _val)                                               \
>>>        ({                                                              \
>>>                __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>>                ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>>>        })
>>>
>>>
>>> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                     \
>>>        ({                                                              \
>>>                BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>>                                 _pfx "mask is not constant");          \
>>>                BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>                BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>>                                 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
>>>                                 _pfx "value too large for the field"); \
>>>                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>                                 __bf_cast_unsigned(_reg, ~0ull),       \
>>>                                 _pfx "type of reg too small for mask"); \
>>>                __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>>>                                              (1ULL << __bf_shf(_mask))); \
>>>        })
>>>
>>> Among them, a build error is generated by the lower part of the
>>> __BF_FIELD_CHECK() macro.
>>>
>>>                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>                                 __bf_cast_unsigned(_reg, ~0ull),       \
>>>                                 _pfx "type of reg too small for mask"); \
>>>
>>>
>>> Here, if you apply an argument to this macro, it will look like the
>>> following.
>>>
>>> __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
>>>
>>> The result is always false because an unsigned int value of type
>>> field_msk is not always greater than the maximum value of unsigned long
>>> long .
>>> So, a build error occurs due to the following part of the clang compiler
>>> option.
>>>
>>> [-Werror,-Wtautological-constant-out-of-range-compare]
>>>
>>> You can simply override this warning in Clang by adding the build option
>>> below, but this seems like a bad attempt
>>>
>>> i915/Makefile
>>> CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
>>>
>>> The easiest way to solve this is to use a constant value, not a
>>> variable, as an argument to FIELD_PREP.
>>>
>>> And since the REG_FIELD_PREP() macro suggested by Jani requires a const
>>> expression as the first argument, it cannot be changed with this macro
>>> alone in the existing code, it must be changed to input a constant value
>>> as shown below.
>>
>> We've added REG_FIELD_PREP() precisely to avoid the problems with the
>> types and ranges, as we want it to operate on u32. It also uses
>> __is_constexpr() to avoid dependencies on compiler implementation and
>> optimizations.
>>
>> Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
>> interface if needed.
> 
> Ashutosh and GG, can we get a fix for this merged ASAP. It's currently
> blocking the drm-intel-gt-next pull request.
> 
> Regards, Joonas
> 
Hi Joonas,
As a workaround patch, this patch[1] was reviewed by Ashutoshr and acked 
by Jani.

[1] https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5


Br,

G.G.
>>
>> BR,
>> Jani.
>>
>>
>>
>>
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>> index 08c921421a5f..abb3a194c548 100644
>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>
>>>    static void
>>>    hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>> -                         const u32 field_msk, int nshift,
>>> +                         int nshift,
>>>                             unsigned int scale_factor, long lval)
>>>    {
>>>           u32 nval;
>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>           /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>           nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>
>>> -       bits_to_clear = field_msk;
>>> -       bits_to_set = REG_FIELD_PREP(field_msk, nval);
>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>> +       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>
>>>           hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>                                               bits_to_clear, bits_to_set);
>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr,
>>> int chan, long val)
>>>           case hwmon_power_max:
>>>                   hwm_field_scale_and_write(ddat,
>>>                                             hwmon->rg.pkg_rapl_limit,
>>> -                                         PKG_PWR_LIM_1,
>>>                                             hwmon->scl_shift_power,
>>>                                             SF_POWER, val);
>>>                   return 0;
>>>
>>>
>>>
>>> In addition, if there is no build problem regardless of the size of the
>>> type as the first argument in FIELD_PREP, it is possible through the
>>> following modification.
>>> (Since this modification modifies include/linux/bitfield.h , I will send
>>> it as a separate patch.
>>>     )
>>>
>>> However, it seems that we need to have Jani's confirm whether it is okay
>>> to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32
>>> return type in i915.
>>>
>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>> index c9be1657f03d..6e96799b6f38 100644
>>> --- a/include/linux/bitfield.h
>>> +++ b/include/linux/bitfield.h
>>> @@ -9,7 +9,7 @@
>>>
>>>    #include <linux/build_bug.h>
>>>    #include <asm/byteorder.h>
>>> -
>>> +#include <linux/overflow.h>
>>>    /*
>>>     * Bitfield access macros
>>>     *
>>> @@ -69,7 +69,7 @@
>>>                                    ~((_mask) >> __bf_shf(_mask)) & (_val)
>>> : 0, \
>>>                                    _pfx "value too large for the field"); \
>>>                   BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>> -                                __bf_cast_unsigned(_reg, ~0ull),       \
>>> +                                __bf_cast_unsigned(_reg,
>>> type_max(__unsigned_scalar_typeof(_reg))),    \
>>>                                    _pfx "type of reg too small for mask"); \
>>>                   __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>>>                                                 (1ULL << __bf_shf(_mask))); \
>>> @@ -84,7 +84,7 @@
>>>     */
>>>    #define FIELD_MAX(_mask)                                               \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)),
>>> type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
>>>                   (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
>>>           })
>>>
>>> @@ -97,7 +97,7 @@
>>>     */
>>>    #define FIELD_FIT(_mask, _val)                                         \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)),
>>> type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
>>>                   !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
>>>           })
>>>
>>> @@ -111,7 +111,7 @@
>>>     */
>>>    #define FIELD_PREP(_mask, _val)
>>>            \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
>>>                   ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>>>           })
>>>
>>> @@ -125,7 +125,7 @@
>>>     */
>>>    #define FIELD_GET(_mask, _reg)                                         \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
>>> +               __BF_FIELD_CHECK(_mask, _reg,
>>> type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
>>>                   (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
>>>           })
>>>
>>>
>>> Br,
>>>
>>> G.G.
>>>
>>> On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
>>>> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>>>>
>>>>
>>>> Hi Nick,
>>>>
>>>>> Thanks, I can repro now.
>>>>>
>>>>> I haven't detangled the macro soup, but I noticed:
>>>>>
>>>>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>>>>> following comment:
>>>>>    18  * Mask must be a compilation time constant.
>>>>
>>>> I had comments about this here:
>>>>
>>>> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
>>>>
>>>> The relevant part being:
>>>>
>>>> ---- {quote} ----
>>>>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>>>>                   BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>>
>>>> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
>>>> also occurs here):
>>>>
>>>>               BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>>                                __bf_cast_unsigned(_reg, ~0ull),       \
>>>>                                _pfx "type of reg too small for mask"); \
>>>>
>>>> So it goes through previous checks including the "mask is not constant"
>>>> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
>>>> after most optimizations have run" so by that time both compilers (gcc and
>>>> clang) have figured out that even though _mask is coming in as function
>>>> argument it is really the constant below:
>>>>
>>>> #define   PKG_PWR_LIM_1              REG_GENMASK(14, 0)
>>>>
>>>> But it is not clear why clang chokes on this "type of reg too small for
>>>> mask" check (and gcc doesn't) since everything is u32.
>>>> ---- {end quote} ----
>>>>
>>>>>
>>>>> 2. hwm_field_scale_and_write only has one callsite.
>>>>>
>>>>> The following patch works:
>>>>
>>>> If we need to fix it at our end yes we can come up with one of these
>>>> patches. But we were hoping someone from clang/llvm can comment about the
>>>> "type of reg too small for mask" stuff. If this is something which needs to
>>>> be fixed in clang/llvm we probably don't want to hide the issue.
>>>>
>>>>>
>>>>> ```
>>>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> index 9e9781493025..6ac29d90b92a 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>>>> i915_reg_t rgadr,
>>>>>
>>>>>    static void
>>>>>    hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>>>> -                         u32 field_msk, int nshift,
>>>>> +                         int nshift,
>>>>>                             unsigned int scale_factor, long lval)
>>>>>    {
>>>>>           u32 nval;
>>>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>>>>> *ddat, i915_reg_t rgadr,
>>>>>           /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>>>           nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>>>
>>>>> -       bits_to_clear = field_msk;
>>>>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>>>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>>>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>>>
>>>>>           hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>>>                                               bits_to_clear, bits_to_set);
>>>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>>>>> attr, int chan, long val)
>>>>>           case hwmon_power_max:
>>>>>                   hwm_field_scale_and_write(ddat,
>>>>>                                             hwmon->rg.pkg_rapl_limit,
>>>>> -                                         PKG_PWR_LIM_1,
>>>>>                                             hwmon->scl_shift_power,
>>>>>                                             SF_POWER, val);
>>>>>                   return 0;
>>>>> ```
>>>>> Though I'm not sure if you're planning to add further callsites of
>>>>> hwm_field_scale_and_write with different field_masks?
>>>>
>>>> I have reasons for keeping it this way, it's there in the link above if you
>>>> are interested.
>>>>
>>>>>
>>>>> Alternatively, (without the above diff),
>>>>>
>>>>> ```
>>>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>>>> index c9be1657f03d..6f40f12bcf89 100644
>>>>> --- a/include/linux/bitfield.h
>>>>> +++ b/include/linux/bitfield.h
>>>>> @@ -8,6 +8,7 @@
>>>>>    #define _LINUX_BITFIELD_H
>>>>>
>>>>>    #include <linux/build_bug.h>
>>>>> +#include <linux/const.h>
>>>>>    #include <asm/byteorder.h>
>>>>>
>>>>>    /*
>>>>> @@ -62,7 +63,7 @@
>>>>>
>>>>>    #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>>>>           ({                                                              \
>>>>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>>>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>>>>                                    _pfx "mask is not constant");          \
>>>>>                   BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>>>                   BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>>>> ```
>>>>> will produce:
>>>>> error: call to __compiletime_assert_407 declared with 'error'
>>>>> attribute: FIELD_PREP: mask is not constant
>>>>>
>>>>> I haven't tested if that change is also feasible (on top of fixing
>>>>> this specific instance), but I think it might help avoid more of these
>>>>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>>>>> compiler version, optimization level.
>>>>
>>>> Not disagreeing, can do something here if needed.
>>>>
>>>> Thanks.
>>>> --
>>>> Ashutosh
>>
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
@ 2022-11-02 10:41                         ` Gwan-gyeong Mun
  0 siblings, 0 replies; 47+ messages in thread
From: Gwan-gyeong Mun @ 2022-11-02 10:41 UTC (permalink / raw)
  To: Joonas Lahtinen, Dixit, Ashutosh, Jani Nikula, Nick Desaulniers
  Cc: intel-gfx, llvm, linux-kernel



On 11/2/22 8:32 AM, Joonas Lahtinen wrote:
> Quoting Jani Nikula (2022-10-28 11:46:21)
>> On Fri, 28 Oct 2022, Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> wrote:
>>> Resend, because some content was accidentally omitted from the previous
>>> reply.
>>> Please ignore the previous email.
>>>
>>> Hi all,
>>>
>>> I should have written the original commit message more accurately, but
>>> it seems that it was written inaccurately.
>>>
>>> If the FIELD_PREP macro is expanded, the following macros are used.
>>>
>>> #define FIELD_PREP(_mask, _val)                                               \
>>>        ({                                                              \
>>>                __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>>                ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>>>        })
>>>
>>>
>>> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                     \
>>>        ({                                                              \
>>>                BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>>                                 _pfx "mask is not constant");          \
>>>                BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>                BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>>                                 ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
>>>                                 _pfx "value too large for the field"); \
>>>                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>                                 __bf_cast_unsigned(_reg, ~0ull),       \
>>>                                 _pfx "type of reg too small for mask"); \
>>>                __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>>>                                              (1ULL << __bf_shf(_mask))); \
>>>        })
>>>
>>> Among them, a build error is generated by the lower part of the
>>> __BF_FIELD_CHECK() macro.
>>>
>>>                BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>                                 __bf_cast_unsigned(_reg, ~0ull),       \
>>>                                 _pfx "type of reg too small for mask"); \
>>>
>>>
>>> Here, if you apply an argument to this macro, it will look like the
>>> following.
>>>
>>> __bf_cast_unsigned(field_msk, field_msk) > __bf_cast_unsigned(0ULL, ~0ull)
>>>
>>> The result is always false because an unsigned int value of type
>>> field_msk is not always greater than the maximum value of unsigned long
>>> long .
>>> So, a build error occurs due to the following part of the clang compiler
>>> option.
>>>
>>> [-Werror,-Wtautological-constant-out-of-range-compare]
>>>
>>> You can simply override this warning in Clang by adding the build option
>>> below, but this seems like a bad attempt
>>>
>>> i915/Makefile
>>> CFLAGS_i915_hwmon.o += -Wno-tautological-constant-out-of-range-compare
>>>
>>> The easiest way to solve this is to use a constant value, not a
>>> variable, as an argument to FIELD_PREP.
>>>
>>> And since the REG_FIELD_PREP() macro suggested by Jani requires a const
>>> expression as the first argument, it cannot be changed with this macro
>>> alone in the existing code, it must be changed to input a constant value
>>> as shown below.
>>
>> We've added REG_FIELD_PREP() precisely to avoid the problems with the
>> types and ranges, as we want it to operate on u32. It also uses
>> __is_constexpr() to avoid dependencies on compiler implementation and
>> optimizations.
>>
>> Please use REG_FIELD_PREP() and a constant value. Maybe rethink the
>> interface if needed.
> 
> Ashutosh and GG, can we get a fix for this merged ASAP. It's currently
> blocking the drm-intel-gt-next pull request.
> 
> Regards, Joonas
> 
Hi Joonas,
As a workaround patch, this patch[1] was reviewed by Ashutoshr and acked 
by Jani.

[1] https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5


Br,

G.G.
>>
>> BR,
>> Jani.
>>
>>
>>
>>
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>> index 08c921421a5f..abb3a194c548 100644
>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>
>>>    static void
>>>    hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>> -                         const u32 field_msk, int nshift,
>>> +                         int nshift,
>>>                             unsigned int scale_factor, long lval)
>>>    {
>>>           u32 nval;
>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
>>> i915_reg_t rgadr,
>>>           /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>           nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>
>>> -       bits_to_clear = field_msk;
>>> -       bits_to_set = REG_FIELD_PREP(field_msk, nval);
>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>> +       bits_to_set = REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>
>>>           hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>                                               bits_to_clear, bits_to_set);
>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr,
>>> int chan, long val)
>>>           case hwmon_power_max:
>>>                   hwm_field_scale_and_write(ddat,
>>>                                             hwmon->rg.pkg_rapl_limit,
>>> -                                         PKG_PWR_LIM_1,
>>>                                             hwmon->scl_shift_power,
>>>                                             SF_POWER, val);
>>>                   return 0;
>>>
>>>
>>>
>>> In addition, if there is no build problem regardless of the size of the
>>> type as the first argument in FIELD_PREP, it is possible through the
>>> following modification.
>>> (Since this modification modifies include/linux/bitfield.h , I will send
>>> it as a separate patch.
>>>     )
>>>
>>> However, it seems that we need to have Jani's confirm whether it is okay
>>> to use FIELD_PREP() instead of REG_FIELD_PREP() which is forced to u32
>>> return type in i915.
>>>
>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>> index c9be1657f03d..6e96799b6f38 100644
>>> --- a/include/linux/bitfield.h
>>> +++ b/include/linux/bitfield.h
>>> @@ -9,7 +9,7 @@
>>>
>>>    #include <linux/build_bug.h>
>>>    #include <asm/byteorder.h>
>>> -
>>> +#include <linux/overflow.h>
>>>    /*
>>>     * Bitfield access macros
>>>     *
>>> @@ -69,7 +69,7 @@
>>>                                    ~((_mask) >> __bf_shf(_mask)) & (_val)
>>> : 0, \
>>>                                    _pfx "value too large for the field"); \
>>>                   BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>> -                                __bf_cast_unsigned(_reg, ~0ull),       \
>>> +                                __bf_cast_unsigned(_reg,
>>> type_max(__unsigned_scalar_typeof(_reg))),    \
>>>                                    _pfx "type of reg too small for mask"); \
>>>                   __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) +                 \
>>>                                                 (1ULL << __bf_shf(_mask))); \
>>> @@ -84,7 +84,7 @@
>>>     */
>>>    #define FIELD_MAX(_mask)                                               \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_MAX: ");     \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)),
>>> type_min(__unsigned_scalar_typeof(_mask)), "FIELD_MAX: ");   \
>>>                   (typeof(_mask))((_mask) >> __bf_shf(_mask));            \
>>>           })
>>>
>>> @@ -97,7 +97,7 @@
>>>     */
>>>    #define FIELD_FIT(_mask, _val)                                         \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, 0ULL, "FIELD_FIT: ");     \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)),
>>> type_min(__unsigned_scalar_typeof(_val)), "FIELD_FIT: ");    \
>>>                   !((((typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \
>>>           })
>>>
>>> @@ -111,7 +111,7 @@
>>>     */
>>>    #define FIELD_PREP(_mask, _val)
>>>            \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
>>> +               __BF_FIELD_CHECK(_mask,
>>> type_min(__unsigned_scalar_typeof(_mask)), _val, "FIELD_PREP: ");       \
>>>                   ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);   \
>>>           })
>>>
>>> @@ -125,7 +125,7 @@
>>>     */
>>>    #define FIELD_GET(_mask, _reg)                                         \
>>>           ({                                                              \
>>> -               __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: ");       \
>>> +               __BF_FIELD_CHECK(_mask, _reg,
>>> type_min(__unsigned_scalar_typeof(_reg)), "FIELD_GET: "); \
>>>                   (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
>>>           })
>>>
>>>
>>> Br,
>>>
>>> G.G.
>>>
>>> On 10/27/22 9:32 PM, Dixit, Ashutosh wrote:
>>>> On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>>>>>
>>>>
>>>> Hi Nick,
>>>>
>>>>> Thanks, I can repro now.
>>>>>
>>>>> I haven't detangled the macro soup, but I noticed:
>>>>>
>>>>> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
>>>>> following comment:
>>>>>    18  * Mask must be a compilation time constant.
>>>>
>>>> I had comments about this here:
>>>>
>>>> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
>>>>
>>>> The relevant part being:
>>>>
>>>> ---- {quote} ----
>>>>>>> ./include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
>>>>>>>                   BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>>
>>>> So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
>>>> also occurs here):
>>>>
>>>>               BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) >     \
>>>>                                __bf_cast_unsigned(_reg, ~0ull),       \
>>>>                                _pfx "type of reg too small for mask"); \
>>>>
>>>> So it goes through previous checks including the "mask is not constant"
>>>> check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
>>>> after most optimizations have run" so by that time both compilers (gcc and
>>>> clang) have figured out that even though _mask is coming in as function
>>>> argument it is really the constant below:
>>>>
>>>> #define   PKG_PWR_LIM_1              REG_GENMASK(14, 0)
>>>>
>>>> But it is not clear why clang chokes on this "type of reg too small for
>>>> mask" check (and gcc doesn't) since everything is u32.
>>>> ---- {end quote} ----
>>>>
>>>>>
>>>>> 2. hwm_field_scale_and_write only has one callsite.
>>>>>
>>>>> The following patch works:
>>>>
>>>> If we need to fix it at our end yes we can come up with one of these
>>>> patches. But we were hoping someone from clang/llvm can comment about the
>>>> "type of reg too small for mask" stuff. If this is something which needs to
>>>> be fixed in clang/llvm we probably don't want to hide the issue.
>>>>
>>>>>
>>>>> ```
>>>>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> b/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> index 9e9781493025..6ac29d90b92a 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>>>>> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
>>>>> i915_reg_t rgadr,
>>>>>
>>>>>    static void
>>>>>    hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>>>> -                         u32 field_msk, int nshift,
>>>>> +                         int nshift,
>>>>>                             unsigned int scale_factor, long lval)
>>>>>    {
>>>>>           u32 nval;
>>>>> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
>>>>> *ddat, i915_reg_t rgadr,
>>>>>           /* Computation in 64-bits to avoid overflow. Round to nearest. */
>>>>>           nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>>>>
>>>>> -       bits_to_clear = field_msk;
>>>>> -       bits_to_set = FIELD_PREP(field_msk, nval);
>>>>> +       bits_to_clear = PKG_PWR_LIM_1;
>>>>> +       bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>>>>>
>>>>>           hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>>>>                                               bits_to_clear, bits_to_set);
>>>>> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
>>>>> attr, int chan, long val)
>>>>>           case hwmon_power_max:
>>>>>                   hwm_field_scale_and_write(ddat,
>>>>>                                             hwmon->rg.pkg_rapl_limit,
>>>>> -                                         PKG_PWR_LIM_1,
>>>>>                                             hwmon->scl_shift_power,
>>>>>                                             SF_POWER, val);
>>>>>                   return 0;
>>>>> ```
>>>>> Though I'm not sure if you're planning to add further callsites of
>>>>> hwm_field_scale_and_write with different field_masks?
>>>>
>>>> I have reasons for keeping it this way, it's there in the link above if you
>>>> are interested.
>>>>
>>>>>
>>>>> Alternatively, (without the above diff),
>>>>>
>>>>> ```
>>>>> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
>>>>> index c9be1657f03d..6f40f12bcf89 100644
>>>>> --- a/include/linux/bitfield.h
>>>>> +++ b/include/linux/bitfield.h
>>>>> @@ -8,6 +8,7 @@
>>>>>    #define _LINUX_BITFIELD_H
>>>>>
>>>>>    #include <linux/build_bug.h>
>>>>> +#include <linux/const.h>
>>>>>    #include <asm/byteorder.h>
>>>>>
>>>>>    /*
>>>>> @@ -62,7 +63,7 @@
>>>>>
>>>>>    #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx)                      \
>>>>>           ({                                                              \
>>>>> -               BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),          \
>>>>> +               BUILD_BUG_ON_MSG(!__is_constexpr(_mask),                \
>>>>>                                    _pfx "mask is not constant");          \
>>>>>                   BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");    \
>>>>>                   BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ?           \
>>>>> ```
>>>>> will produce:
>>>>> error: call to __compiletime_assert_407 declared with 'error'
>>>>> attribute: FIELD_PREP: mask is not constant
>>>>>
>>>>> I haven't tested if that change is also feasible (on top of fixing
>>>>> this specific instance), but I think it might help avoid more of these
>>>>> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
>>>>> compiler version, optimization level.
>>>>
>>>> Not disagreeing, can do something here if needed.
>>>>
>>>> Thanks.
>>>> --
>>>> Ashutosh
>>
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 47+ messages in thread

end of thread, other threads:[~2022-11-02 10:42 UTC | newest]

Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
2022-10-25  1:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-10-25  1:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-10-25  3:14 ` [PATCH] " Dixit, Ashutosh
2022-10-25  3:14   ` [Intel-gfx] " Dixit, Ashutosh
2022-10-25  9:25   ` Andi Shyti
2022-10-25  9:25     ` Andi Shyti
2022-10-25 16:46     ` Nick Desaulniers
2022-10-25 16:46       ` [Intel-gfx] " Nick Desaulniers
2022-10-25 18:45     ` Dixit, Ashutosh
2022-10-25 18:45       ` [Intel-gfx] " Dixit, Ashutosh
2022-10-26  0:18       ` Andi Shyti
2022-10-26  0:18         ` [Intel-gfx] " Andi Shyti
2022-10-27 16:35         ` Nick Desaulniers
2022-10-27 16:35           ` [Intel-gfx] " Nick Desaulniers
2022-10-27 16:53           ` Dixit, Ashutosh
2022-10-27 16:53             ` [Intel-gfx] " Dixit, Ashutosh
2022-10-27 17:16             ` Nick Desaulniers
2022-10-27 17:16               ` Nick Desaulniers
2022-10-27 18:32               ` Dixit, Ashutosh
2022-10-27 18:32                 ` [Intel-gfx] " Dixit, Ashutosh
2022-10-28  6:26                 ` Gwan-gyeong Mun
2022-10-28  6:26                   ` [Intel-gfx] " Gwan-gyeong Mun
2022-10-28  6:43                 ` Gwan-gyeong Mun
2022-10-28  6:43                   ` Gwan-gyeong Mun
2022-10-28  8:46                   ` Jani Nikula
2022-10-28  8:46                     ` [Intel-gfx] " Jani Nikula
2022-11-02  6:32                     ` Joonas Lahtinen
2022-11-02 10:41                       ` Gwan-gyeong Mun
2022-11-02 10:41                         ` Gwan-gyeong Mun
2022-10-25  9:15 ` Andi Shyti
2022-10-25 14:27 ` Jani Nikula
2022-10-25 14:30   ` Jani Nikula
2022-10-25 18:46     ` Dixit, Ashutosh
2022-10-27 17:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2) Patchwork
2022-10-28  6:30 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev3) Patchwork
2022-10-28  6:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev4) Patchwork
2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
2022-10-31  5:19   ` Dixit, Ashutosh
2022-10-31  6:37     ` Gwan-gyeong Mun
2022-10-31 17:31       ` Dixit, Ashutosh
2022-11-01 10:35         ` Jani Nikula
2022-11-02  7:12   ` Dixit, Ashutosh
2022-11-02  8:50     ` Jani Nikula
2022-10-29  5:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler (rev5) Patchwork
2022-10-29  5:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-29 15:32 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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.