From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Jeff Johnson <quic_jjohnson@quicinc.com>,
Pavel Skripkin <paskripkin@gmail.com>,
ath9k-devel@qca.qualcomm.com, kvalo@kernel.org,
davem@davemloft.net, kuba@kernel.org, linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] ath9k: htc: clean up *STAT_* macros
Date: Tue, 08 Feb 2022 16:32:13 +0100 [thread overview]
Message-ID: <87ee4d9xxe.fsf@toke.dk> (raw)
In-Reply-To: <258ac12b-9ca3-9b24-30df-148f9df51582@quicinc.com>
Jeff Johnson <quic_jjohnson@quicinc.com> writes:
> On 2/7/2022 12:24 PM, Pavel Skripkin wrote:
>> I've changed *STAT_* macros a bit in previous patch and I seems like
>> they become really unreadable. Align these macros definitions to make
>> code cleaner.
>>
>> Also fixed following checkpatch warning
>>
>> ERROR: Macros with complex values should be enclosed in parentheses
>>
>> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
>> ---
>>
>> Changes since v2:
>> - My send-email script forgot, that mailing lists exist.
>> Added back all related lists
>> - Fixed checkpatch warning
>>
>> Changes since v1:
>> - Added this patch
>>
>> ---
>> drivers/net/wireless/ath/ath9k/htc.h | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
>> index 141642e5e00d..b4755e21a501 100644
>> --- a/drivers/net/wireless/ath/ath9k/htc.h
>> +++ b/drivers/net/wireless/ath/ath9k/htc.h
>> @@ -327,14 +327,14 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct sk_buff *skb)
>> }
>>
>> #ifdef CONFIG_ATH9K_HTC_DEBUGFS
>> -#define __STAT_SAVE(expr) (hif_dev->htc_handle->drv_priv ? (expr) : 0)
>> -#define TX_STAT_INC(c) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.tx_stats.c++)
>> -#define TX_STAT_ADD(c, a) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.tx_stats.c += a)
>> -#define RX_STAT_INC(c) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.skbrx_stats.c++)
>> -#define RX_STAT_ADD(c, a) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.skbrx_stats.c += a)
>> -#define CAB_STAT_INC priv->debug.tx_stats.cab_queued++
>> -
>> -#define TX_QSTAT_INC(q) (priv->debug.tx_stats.queue_stats[q]++)
>> +#define __STAT_SAVE(expr) (hif_dev->htc_handle->drv_priv ? (expr) : 0)
>> +#define TX_STAT_INC(c) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.tx_stats.c++)
>> +#define TX_STAT_ADD(c, a) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.tx_stats.c += a)
>> +#define RX_STAT_INC(c) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.skbrx_stats.c++)
>> +#define RX_STAT_ADD(c, a) __STAT_SAVE(hif_dev->htc_handle->drv_priv->debug.skbrx_stats.c += a)
>> +#define CAB_STAT_INC (priv->debug.tx_stats.cab_queued++)
>> +
>> +#define TX_QSTAT_INC(q) (priv->debug.tx_stats.queue_stats[q]++)
>>
>> void ath9k_htc_err_stat_rx(struct ath9k_htc_priv *priv,
>> struct ath_rx_status *rs);
>
> It seems that these macros (both the original and the new) aren't
> following the guidance from the Coding Style which tells us under
> "Things to avoid when using macros" that we should avoid "macros that
> depend on having a local variable with a magic name". Wouldn't these
> macros be "better" is they included the hif_dev/priv as arguments rather
> than being "magic"?
Hmm, yeah, that's a good point; looks like the non-HTC ath9k stats
macros have already been converted to take the container as a parameter,
so taking this opportunity to fix these macros is not a bad idea. While
we're at it, let's switch to the do{} while(0) syntax the other macros
are using instead of that weird usage of ?:. And there's not really any
reason for the duplication between ADD/INC either. So I'm thinking
something like:
#define __STAT_SAVE(_priv, _member, _n) do { if (_priv) (_priv)->_member += (_n); } while(0)
#define TX_STAT_ADD(_priv, _c, _a) __STAT_SAVE(_priv, debug.tx_stats._c, _a)
#define TX_STAT_INC(_priv, _c) TX_STAT_ADD(_priv, _c, 1)
[... etc ...]
-Toke
next prev parent reply other threads:[~2022-02-08 15:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 20:24 [PATCH v3 1/2] ath9k: fix use-after-free in ath9k_hif_usb_rx_cb Pavel Skripkin
2022-02-07 20:24 ` [PATCH v3 2/2] ath9k: htc: clean up *STAT_* macros Pavel Skripkin
2022-02-07 21:24 ` Jeff Johnson
2022-02-08 15:32 ` Toke Høiland-Jørgensen [this message]
2022-02-08 15:49 ` Pavel Skripkin
2022-02-08 14:47 ` [PATCH v3 1/2] ath9k: fix use-after-free in ath9k_hif_usb_rx_cb Toke Høiland-Jørgensen
2022-02-08 15:48 ` Pavel Skripkin
2022-05-02 6:10 ` Tetsuo Handa
2022-05-05 19:09 ` Pavel Skripkin
2022-05-05 23:31 ` Tetsuo Handa
2022-05-10 19:26 ` Pavel Skripkin
2022-05-11 4:50 ` Kalle Valo
2022-05-11 9:53 ` Toke Høiland-Jørgensen
2022-05-11 9:59 ` Kalle Valo
2022-05-12 12:49 ` Toke Høiland-Jørgensen
2022-05-12 12:55 ` Pavel Skripkin
2022-05-12 13:48 ` Toke Høiland-Jørgensen
2022-05-12 16:05 ` Jeff Johnson
2022-05-12 16:09 ` Pavel Skripkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee4d9xxe.fsf@toke.dk \
--to=toke@toke.dk \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=paskripkin@gmail.com \
--cc=quic_jjohnson@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).