summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorColin Ian King <colin.king@canonical.com>2021-02-25 18:32:41 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-05-14 09:44:28 +0200
commitaf5a87a1d41339d8bac1a2fcb3106c3ba11a7f6d (patch)
tree2c08f34f8c62ced5ad6bc1396cca12f0cbd4da9c /arch
parent53ada35f2ecc125860a7d76bdded6bf336583774 (diff)
downloadlinux-stable-af5a87a1d41339d8bac1a2fcb3106c3ba11a7f6d.tar.gz
linux-stable-af5a87a1d41339d8bac1a2fcb3106c3ba11a7f6d.tar.bz2
linux-stable-af5a87a1d41339d8bac1a2fcb3106c3ba11a7f6d.zip
mt7601u: fix always true expression
[ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ] Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix. Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration. Addresses-Coverity: ("Logical vs. bitwise operator") Fixes: c869f77d6abb ("add mt7601u driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Jakub Kicinski <kubakici@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210225183241.1002129-1-colin.king@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions