CHECK: Macro argument reuse

CHECK: Macro argument reuse

[Hegbeli, Ciprian]

Hi,

The driver I'm working on has channels which can be configured similarly but with small changes. In order to simplify the code, I used macros with arguments for the parts that are different.
Unfortunately this leads to warnings during the checkpatch with --strict .

CHECK: Macro argument reuse 'num' - possible side-effects?
+#define ADE9078_POWER_FACTOR_CHANNEL(num, name) {		\
+	.type = IIO_POWER,						\
+	.channel = num,							\
+	.address = ADE9078_ADDR_ADJUST(ADE9078_REG_APF, num),	\
+	.extend_name = name "_factor",				\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |		\
+			             BIT(IIO_CHAN_INFO_SCALE),		\
+	.scan_index = -1						\
+}

Is there any way to fix this warning without adding more arguments?
In this case, can it be ignored?

Regards,
Ciprian

Re: CHECK: Macro argument reuse

[Jonathan Cameron]

On Wed, 2 Feb 2022 10:48:51 +0000
"Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com> wrote:

> Hi,
> 
> The driver I'm working on has channels which can be configured similarly but with small changes. In order to simplify the code, I used macros with arguments for the parts that are different.
> Unfortunately this leads to warnings during the checkpatch with --strict .
> 
> CHECK: Macro argument reuse 'num' - possible side-effects?
> +#define ADE9078_POWER_FACTOR_CHANNEL(num, name) {		\
> +	.type = IIO_POWER,						\
> +	.channel = num,							\
> +	.address = ADE9078_ADDR_ADJUST(ADE9078_REG_APF, num),	\
> +	.extend_name = name "_factor",				\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |		\
> +			             BIT(IIO_CHAN_INFO_SCALE),		\
> +	.scan_index = -1						\
> +}
> 
> Is there any way to fix this warning without adding more arguments?
> In this case, can it be ignored?

It's a request to 'CHECK' that it looks right, not a warning or error
because it may well be fine.  In this case, I'd hope it's fine
as long as you are only passing constant values in for num.
So check what it asks you to check and if it's fine ignore the message.

Jonathan
> 
> Regards,
> Ciprian
>