Re: [PATCH] ath9k: use proper statements in conditionals - Toke Høiland-Jørgensen

From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
	Kalle Valo <kvalo@kernel.org>,
	Pavel Skripkin <paskripkin@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-wireless@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath9k: use proper statements in conditionals
Date: Fri, 16 Dec 2022 15:33:07 +0100	[thread overview]
Message-ID: <87fsdfbeqk.fsf@toke.dk> (raw)
In-Reply-To: <486f9bc9-408f-4c29-b675-cbd61673f58c@app.fastmail.com>

"Arnd Bergmann" <arnd@arndb.de> writes:

> On Thu, Dec 15, 2022, at 18:16, Toke Høiland-Jørgensen wrote:
>>> index 30f0765fb9fd..237f4ec2cffd 100644
>>> --- a/drivers/net/wireless/ath/ath9k/htc.h
>>> +++ b/drivers/net/wireless/ath/ath9k/htc.h
>>> @@ -327,9 +327,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct sk_buff *skb)
>>>  }
>>>  
>>>  #ifdef CONFIG_ATH9K_HTC_DEBUGFS
>>> -#define __STAT_SAFE(hif_dev, expr)	((hif_dev)->htc_handle->drv_priv ? (expr) : 0)
>>> -#define CAB_STAT_INC(priv)		((priv)->debug.tx_stats.cab_queued++)
>>> -#define TX_QSTAT_INC(priv, q)		((priv)->debug.tx_stats.queue_stats[q]++)
>>> +#define __STAT_SAFE(hif_dev, expr)	do { ((hif_dev)->htc_handle->drv_priv ? (expr) : 0); } while (0)
>>> +#define CAB_STAT_INC(priv)		do { ((priv)->debug.tx_stats.cab_queued++); } while (0)
>>> +#define TX_QSTAT_INC(priv, q)		do { ((priv)->debug.tx_stats.queue_stats[q]++); } while (0)
>>
>> Hmm, is it really necessary to wrap these in do/while constructs? AFAICT
>> they're all simple statements already?
>
> It's generally safer to do the same thing on both side of the #ifdef.
>
> The "do { } while (0)" is an empty statement that is needed to fix
> the bug on the #else side. The expressions you have on the #ifdef
> side can be used as values, and wrapping them in do{}while(0)
> turns them into statements (without a value) as well, so fewer
> things can go wrong when you only test one side.

Alright, makes sense; thanks for explaining!

> I suppose the best solution would be to just use inline functions
> for all of them and get rid of the macros.

Let's merge this patch to fix the bug, and if someone wants to follow up
with a conversion to inline functions, that would be awesome, of course :)

-Toke