Re: [PATCH v1] reset: intel: fix a compile warning about REG_OFFSET redefined

[Philipp Zabel]

Hi Dejin,

On Thu, 2020-06-04 at 23:30 +0800, Dejin Zheng wrote:
> kernel test robot reports a compile warning about REG_OFFSET redefined
> in the reset-intel-gw.c after merging commit e44ab4e14d6f4 ("regmap:
> Simplify implementation of the regmap_read_poll_timeout() macro"). the
> warning is like that:
> 
> drivers/reset/reset-intel-gw.c:18:0: warning: "REG_OFFSET" redefined
>  #define REG_OFFSET GENMASK(31, 16)
> 
> In file included from ./arch/arm/mach-ixp4xx/include/mach/hardware.h:30:0,
>                  from ./arch/arm/mach-ixp4xx/include/mach/io.h:15,
>                  from ./arch/arm/include/asm/io.h:198,
>                  from ./include/linux/io.h:13,
>                  from ./include/linux/iopoll.h:14,
>                  from ./include/linux/regmap.h:20,
>                  from drivers/reset/reset-intel-gw.c:12:
> ./arch/arm/mach-ixp4xx/include/mach/platform.h:25:0: note: this is the location of the previous definition
>  #define REG_OFFSET 3
> 
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Fixes: e44ab4e14d6f4 ("regmap: Simplify implementation of the regmap_read_poll_timeout() macro")

Hm, shouldn't this rather be:

Fixes: c9aef213e38c ("reset: intel: Add system reset controller driver")

even though e44ab4e14d6f4 triggered the issue by including iopoll.h?

> Signed-off-by: Dejin Zheng <zhengdejin5@xxxxxxxxx>
> ---
>  drivers/reset/reset-intel-gw.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/reset/reset-intel-gw.c b/drivers/reset/reset-intel-gw.c
> index 854238444616..5cfb4892b399 100644
> --- a/drivers/reset/reset-intel-gw.c
> +++ b/drivers/reset/reset-intel-gw.c
> @@ -15,7 +15,7 @@
>  #define RCU_RST_STAT	0x0024
>  #define RCU_RST_REQ	0x0048
>  
> -#define REG_OFFSET	GENMASK(31, 16)
> +#define REG_OFFSET_MASK	GENMASK(31, 16)
>  #define BIT_OFFSET	GENMASK(15, 8)
>  #define STAT_BIT_OFFSET	GENMASK(7, 0)

Could you add the _MASK suffix to BIT_OFFSET and STAT_BIT_OFFSET as
well, for consistency?

regards
Philipp