From patchwork Sat Apr 6 01:38:53 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 161898 Delivered-To: patch@linaro.org Received: by 2002:a02:c6d8:0:0:0:0:0 with SMTP id r24csp1113132jan; Fri, 5 Apr 2019 18:38:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEVJR3PDNAHJ+ZRHFu8CPvcItPgWs7oqfkp+Ec/WBuaMnVvhKuj7TQu1tZjurkQqCBFvsE X-Received: by 2002:a65:6148:: with SMTP id o8mr15542060pgv.153.1554514737807; Fri, 05 Apr 2019 18:38:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554514737; cv=none; d=google.com; s=arc-20160816; b=jmX6mR15mgFndxkvJuTeEY20+kDRwsySyf4rxuD24UIPFafYP5qQGxHX5q/ENmD6Xl wdO4v7P/TOxAixEpVdtioloR9zMg8rehuIgRkP9ofFLlJrjgGQ7NH8z89O5kDNjVBQCU uc8YljCp7nOMR0xxj81U1Y6iQY5x7o6GqgRHGgkWOJLsWX+244pajq7TnXp6Tppz6enl 85OfgLu7tp1SCoDDn+MzaoLC75uUTyeiJ6n+151S4yyVKa8qoxJuqAb7TpNFAqBw6y7N JWjudWHzQFkdJ5/Rqh9+cff83jAIVRmX6OHiwHbsAgb+sW27r+mrSRxce/vdCWlvp4si UI4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:subject:to:from :date; bh=Vlv530gXpmrv0gY6mKIriUr8z2kN7SwYBWzuHYGpZuU=; b=PfE/oyJpRiWY20OuDH93WYqsoT549E1ZJ0KFgsRJ75QoUvywWRbLjSmfuT35UDa/rs kdoAqUppSxuK7c6GdFrWBcvj8BQkw0vclWDb0lBwTk60l7q0Sg5fSZDRpVK08MZXc7oO e34GM7Hnn72gEGnSOY187BWLlHdXPEIBmoWR+VQjx6OJ/zQk25AUxm1zfwxfRYPjYGDJ FiP+gcaZfuHVcqGrBh6H/sjc7VcKpA4c+fiIYBADM+KBFxUEGdFk7Hey93308zEKIjj1 a3Bv9dwoVIASS+YynC4nUdPP/oqDuuIn94m8bExi1pSfpCc2uMDAeUfEO11vNhKiF8ga Rl+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si20572671pfj.17.2019.04.05.18.38.57; Fri, 05 Apr 2019 18:38:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726532AbfDFBi5 (ORCPT + 14 others); Fri, 5 Apr 2019 21:38:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:40992 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725973AbfDFBi5 (ORCPT ); Fri, 5 Apr 2019 21:38:57 -0400 Received: from localhost.localdomain (c-73-223-200-170.hsd1.ca.comcast.net [73.223.200.170]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 71A2E263F; Sat, 6 Apr 2019 01:38:55 +0000 (UTC) Date: Fri, 05 Apr 2019 18:38:53 -0700 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, arnd@arndb.de, mm-commits@vger.kernel.org, ndesaulniers@google.com, qiang.zhao@nxp.com, stable@vger.kernel.org, torvalds@linux-foundation.org, yalin.wang@sonymobile.com Subject: [patch 03/14] include/linux/bitrev.h: fix constant bitrev Message-ID: <20190406013853.y1FS0oWC0%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Arnd Bergmann Subject: include/linux/bitrev.h: fix constant bitrev clang points out with hundreds of warnings that the bitrev macros have a problem with constant input: drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] u8 crc = bitrev8(data->val_status & 0x0F); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8' __constant_bitrev8(__x) : \ ~~~~~~~~~~~~~~~~~~~^~~~ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8' u8 __x = x; \ ~~~ ^ Both the bitrev and the __constant_bitrev macros use an internal variable named __x, which goes horribly wrong when passing one to the other. The obvious fix is to rename one of the variables, so this adds an extra '_'. It seems we got away with this because - there are only a few drivers using bitrev macros - usually there are no constant arguments to those - when they are constant, they tend to be either 0 or (unsigned)-1 (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and give the correct result by pure chance. In fact, the only driver that I could find that gets different results with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver for fairly rare hardware (adding the maintainer to Cc for testing). Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction") Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers Cc: Zhao Qiang Cc: Yalin Wang Cc: Signed-off-by: Andrew Morton --- include/linux/bitrev.h | 46 +++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 23 deletions(-) --- a/include/linux/bitrev.h~bitrev-fix-constant-bitrev +++ a/include/linux/bitrev.h @@ -34,41 +34,41 @@ static inline u32 __bitrev32(u32 x) #define __constant_bitrev32(x) \ ({ \ - u32 __x = x; \ - __x = (__x >> 16) | (__x << 16); \ - __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = (___x >> 16) | (___x << 16); \ + ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev16(x) \ ({ \ - u16 __x = x; \ - __x = (__x >> 8) | (__x << 8); \ - __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \ - __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \ - __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \ - __x; \ + u16 ___x = x; \ + ___x = (___x >> 8) | (___x << 8); \ + ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \ + ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \ + ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \ + ___x; \ }) #define __constant_bitrev8x4(x) \ ({ \ - u32 __x = x; \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev8(x) \ ({ \ - u8 __x = x; \ - __x = (__x >> 4) | (__x << 4); \ - __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \ - __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \ - __x; \ + u8 ___x = x; \ + ___x = (___x >> 4) | (___x << 4); \ + ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \ + ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \ + ___x; \ }) #define bitrev32(x) \