lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5797d1aff9034476afa6827af2bfbce7@AcuMS.aculab.com>
Date:   Mon, 20 Dec 2021 14:00:40 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Joe Perches' <joe@...ches.com>,
        Anders Roxell <anders.roxell@...aro.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "woojung.huh@...rochip.com" <woojung.huh@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "clang-built-linux@...glegroups.com" 
        <clang-built-linux@...glegroups.com>,
        "ulli.kroll@...glemail.com" <ulli.kroll@...glemail.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "amitkarwar@...il.com" <amitkarwar@...il.com>,
        "nishants@...vell.com" <nishants@...vell.com>,
        "gbhat@...vell.com" <gbhat@...vell.com>,
        "huxinming820@...il.com" <huxinming820@...il.com>,
        "kvalo@...eaurora.org" <kvalo@...eaurora.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
        "nathan@...nel.org" <nathan@...nel.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        Andy Lavr <andy.lavr@...il.com>
Subject: RE: [PATCH 4.19 3/6] mwifiex: Remove unnecessary braces from
 HostCmd_SET_SEQ_NO_BSS_INFO

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@...il.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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ