From: Joe Perches
Sent: 20 December 2021 12:13
On Fri, 2021-12-17 at 15:41 +0100, Anders Roxell wrote:
From: Nathan Chancellor natechancellor@gmail.com
commit 6a953dc4dbd1c7057fb765a24f37a5e953c85fb0 upstream.
A new warning in clang points out when macro expansion might result in a GNU C statement expression. There is an instance of this in the mwifiex driver:
drivers/net/wireless/marvell/mwifiex/cmdevt.c:217:34: warning: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Wcompound-token-split-by-macro] host_cmd->seq_num = cpu_to_le16(HostCmd_SET_SEQ_NO_BSS_INFO ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[]
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
[]
@@ -512,10 +512,10 @@ enum mwifiex_channel_flags {
#define RF_ANTENNA_AUTO 0xFFFF
-#define HostCmd_SET_SEQ_NO_BSS_INFO(seq, num, type) { \
- (((seq) & 0x00ff) | \
(((num) & 0x000f) << 8)) | \- (((type) & 0x000f) << 12); }
+#define HostCmd_SET_SEQ_NO_BSS_INFO(seq, num, type) \
- ((((seq) & 0x00ff) | \
(((num) & 0x000f) << 8)) | \- (((type) & 0x000f) << 12))
Perhaps this would be better as a static inline
static inline u16 HostCmd_SET_SEQ_NO_BSS_INFO(u16 seq, u8 num, u8 type) { return (type & 0x000f) << 12 | (num & 0x000f) << 8 | (seq & 0x00ff); }
Just writing in on one line helps readability! It is also used exactly twice, both with a cpu_to_le16(). I wonder how well the compiler handles that on BE? The #define is more likely to be handled better.
I've only made a cursory glance at the code, but I get splitting host_cmd->seq_num into two u8 fields would give better code!
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)