linux-stable

mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-08-27 19:29:37 +00:00

History

Nathan Chancellor 86ded7a6cf staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn() commit `502408a61f` upstream. A new warning in clang points out a place in this file where a bitwise OR is being used with boolean expressions: In file included from drivers/staging/wlan-ng/prism2usb.c:2: drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: warning: use of bitwise '\|' with boolean operands [-Wbitwise-instead-of-logical] ((test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) && ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: note: cast one or both operands to int to silence this warning 1 warning generated. The comment explains that short circuiting here is undesirable, as the calls to test_and_{clear,set}_bit() need to happen for both sides of the expression. Clang's suggestion would work to silence the warning but the readability of the expression would suffer even more. To clean up the warning and make the block more readable, use a variable for each side of the bitwise expression. Link: https://github.com/ClangBuiltLinux/linux/issues/1478 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211014215703.3705371-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>		2022-01-16 09:15:39 +01:00
..
cfg80211.c
hfa384x.h
hfa384x_usb.c	staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn()	2022-01-16 09:15:39 +01:00
Kconfig
Makefile
p80211conv.c
p80211conv.h
p80211hdr.h
p80211ioctl.h
p80211metadef.h
p80211metastruct.h
p80211mgmt.h
p80211msg.h
p80211netdev.c
p80211netdev.h
p80211req.c
p80211req.h
p80211types.h
p80211wep.c
prism2fw.c
prism2mgmt.c
prism2mgmt.h
prism2mib.c
prism2sta.c
prism2usb.c
README

README

TODO:
	- checkpatch.pl cleanups
	- sparse warnings
	- move to use the in-kernel wireless stack

Please send any patches or complaints about this driver to Greg
Kroah-Hartman <greg@kroah.com> and don't bother the upstream wireless
kernel developers about it, they want nothing to do with it.