| Message ID | Y1vZXUi0Bjiub8HZ@ubunlion |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp835656wru;
Fri, 28 Oct 2022 06:36:39 -0700 (PDT)
X-Google-Smtp-Source:
AMsMyM7PaGuvvevlwMZKQcAmY7HPwofEru7CWlquLBtecrurJEASGEo8BCxsKR/imupl9MUNGwlU
X-Received: by 2002:a63:2c8:0:b0:46e:9da9:8083 with SMTP id
191-20020a6302c8000000b0046e9da98083mr36576248pgc.186.1666964198995;
Fri, 28 Oct 2022 06:36:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1666964198; cv=none;
d=google.com; s=arc-20160816;
b=icwQ4p8VL1TDmOofvw/JPuZGwOG4XTh3Jfpeo7LpfWgaSp3kdTKYga3cU9vLx8P2If
GFkQNJChW8Y3qawVlEiIbZYZyYB/gneHfFPqYCItfw/SEJoYB2jeC3X+E+Ct0MApekx1
/JfytY8LuRfeUGpmPunoRE4U+eM2AEQnQ66Kgtn0KxmdO5znWleWbyvZqe/Yd4hkSKcC
qtFrsTYjQPeVMsMYKJkuhhO6/ZG9zJumTeOo6b2vVOS9zgKnOhGXddWpgAF+UcC7+WCB
SM1ImCwXenIXzZ/3kSOdQyJO6oBupbptP8O3mwffnWgEEmYoL2R95zlO+v9m/zicAoZX
/yiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-disposition:mime-version:message-id
:subject:to:from:date:dkim-signature;
bh=b8fMrZCovOvFP8BqzGtNjmTS24CKg/OaZJYL0rVR0AQ=;
b=f861gAuMcNlR4uR5xj8Leq5EHje602S9vmdDSynBZ+nkM7H4osaA7vpftVzE8eAXjE
syXtxN95/Xb+5OlenMmSI4UCjzb71kFEsBMjCKgXUfKrFhaz7+R6mf+rY0NVfTvPR7Ng
BCZvhzX/B2yUmo1GW/HK3eLvI7ko9IDaXcH4gw9tegWQqVS9GN3V13DvbvV7FFmHEMk9
DhizgWqt8BL058eJKWimMItod0R+HuPYdqjUbCNXxj1cGTh6It+/ohH+hTNC8RvSvt+X
i/SM9lXQN5WWWJ9a+OqbctxIS4qt6y6JCv8YztOjKQzyJxytXKlsetIfSVHA94n3Z7rK
KZ4A==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=fail header.i=@mailo.com header.s=mailo header.b=naGIr9mb;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
u185-20020a6385c2000000b0045fc63bf52csi4617690pgd.764.2022.10.28.06.36.24;
Fri, 28 Oct 2022 06:36:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
dkim=fail header.i=@mailo.com header.s=mailo header.b=naGIr9mb;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S230486AbiJ1Nai (ORCPT <rfc822;chrisfriedt@gmail.com>
+ 99 others); Fri, 28 Oct 2022 09:30:38 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50506 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S230477AbiJ1Na2 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 28 Oct 2022 09:30:28 -0400
Received: from msg-2.mailo.com (msg-2.mailo.com [213.182.54.12])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8FC5481C6
for <linux-kernel@vger.kernel.org>;
Fri, 28 Oct 2022 06:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo;
t=1666963811; bh=yl2gtCFcrA+y8ipJCReQCBstnVYp6kw9Oo6TOGLDu48=;
h=X-EA-Auth:Date:From:To:Subject:Message-ID:MIME-Version:
Content-Type;
b=naGIr9mbGwyhwpjYrv2t87fqffgj1mwZ+5/C4r80b/7MimJ/diBBIj6EkUnpiJmEJ
SqFheASo9qXA6Udz4amUxh6XyhqOT0H4SoiBLAbW+ORLUkVGTuQqpHpcnLaVc1hHx8
6huRGOoIvDEfZVfgB1N24jlGlvzir8u96F1Kjaf0=
Received: by b-6.in.mailobj.net [192.168.90.16] with ESMTP
via [213.182.55.206]
Fri, 28 Oct 2022 15:30:11 +0200 (CEST)
X-EA-Auth:
DIZOiORP0IjVZ8/XwaxKMK586tsbAVcXFYeycjJhdSHO7JpUY2oJpHSxW2jTyOzoxV7UlsyKto2JDACDDTO8hWRBMP/V0mK3
Date: Fri, 28 Oct 2022 19:00:05 +0530
From: Deepak R Varma <drv@mailo.com>
To: outreachy@lists.linux.dev,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH] staging: fbtft: Use ARRAY_SIZE() to get argument count
Message-ID: <Y1vZXUi0Bjiub8HZ@ubunlion>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS
autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1747938651855426852?=
X-GMAIL-MSGID: =?utf-8?q?1747938651855426852?=
|
| Series |
staging: fbtft: Use ARRAY_SIZE() to get argument count
|
|
Commit Message
Deepak R Varma
Oct. 28, 2022, 1:30 p.m. UTC
The ARRAY_SIZE(foo) macro should be preferred over sizeof operator
based computation such as sizeof(foo)/sizeof(foo[0]) for finding
number of elements in an array. Issue identified using coccicheck.
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
drivers/staging/fbtft/fbtft.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.34.1
Comments
Hi Deepak,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Deepak-R-Varma/staging-fbtft-Use-ARRAY_SIZE-to-get-argument-count/20221028-213204
patch link: https://lore.kernel.org/r/Y1vZXUi0Bjiub8HZ%40ubunlion
patch subject: [PATCH] staging: fbtft: Use ARRAY_SIZE() to get argument count
config: arm-randconfig-r004-20221029
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 791a7ae1ba3efd6bca96338e10ffde557ba83920)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# https://github.com/intel-lab-lkp/linux/commit/74374d9d2a2d6066b94d64aa44e9a1b24c854c4e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Deepak-R-Varma/staging-fbtft-Use-ARRAY_SIZE-to-get-argument-count/20221028-213204
git checkout 74374d9d2a2d6066b94d64aa44e9a1b24c854c4e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash drivers/staging/fbtft/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-core.c:206:15: error: initializer element is not a compile-time constant
(xs >> 8) & 0xFF, xs & 0xFF, (xe >> 8) & 0xFF, xe & 0xFF);
~~~~~~~~~~^~~~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fbtft-core.c:209:15: error: initializer element is not a compile-time constant
(ys >> 8) & 0xFF, ys & 0xFF, (ye >> 8) & 0xFF, ye & 0xFF);
~~~~~~~~~~^~~~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fbtft-core.c:330:6: warning: variable 'count' set but not used [-Wunused-but-set-variable]
int count = 0;
^
1 warning and 2 errors generated.
--
>> drivers/staging/fbtft/fb_bd663474.c:110:26: error: initializer element is not a compile-time constant
write_reg(par, 0x0200, xs);
^~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_bd663474.c:111:26: error: initializer element is not a compile-time constant
write_reg(par, 0x0201, ys);
^~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_bd663474.c:114:36: error: initializer element is not a compile-time constant
write_reg(par, 0x0200, WIDTH - 1 - xs);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
~~~~~~~~^~~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
~~~~~~~~~~~~~~~~^~~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_bd663474.c:115:37: error: initializer element is not a compile-time constant
write_reg(par, 0x0201, HEIGHT - 1 - ys);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
~~~~~~~~^~~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
~~~~~~~~~~~~~~~~^~~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_bd663474.c:118:36: error: initializer element is not a compile-time constant
write_reg(par, 0x0200, WIDTH - 1 - ys);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
~~~~~~~~^~~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
~~~~~~~~~~~~~~~~^~~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
--
>> drivers/staging/fbtft/fb_hx8353d.c:67:26: error: initializer element is not a compile-time constant
write_reg(par, 0x2a, xs >> 8, xs & 0xff, xe >> 8, xe & 0xff);
~~~^~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8353d.c:70:26: error: initializer element is not a compile-time constant
write_reg(par, 0x2b, ys >> 8, ys & 0xff, ye >> 8, ye & 0xff);
~~~^~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8353d.c:92:6: error: initializer element is not a compile-time constant
mx | my | (par->bgr << 3));
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fb_hx8353d.c:77:12: note: expanded from macro 'mx'
#define mx BIT(6)
^
include/vdso/bits.h:7:19: note: expanded from macro 'BIT'
#define BIT(nr) (UL(1) << (nr))
^
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
~~~~~~~~^~~~~~~~~~~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8353d.c:96:6: error: initializer element is not a compile-time constant
my | mv | (par->bgr << 3));
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fb_hx8353d.c:76:12: note: expanded from macro 'my'
#define my BIT(7)
^
include/vdso/bits.h:7:19: note: expanded from macro 'BIT'
#define BIT(nr) (UL(1) << (nr))
^
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
~~~~~~~~^~~~~~~~~~~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8353d.c:100:15: error: initializer element is not a compile-time constant
par->bgr << 3);
~~~~~~~~~^~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
--
>> drivers/staging/fbtft/fb_hx8357d.c:135:8: error: initializer element is not a compile-time constant
xs >> 8, xs & 0xff, /* XSTART */
~~~^~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8357d.c:139:8: error: initializer element is not a compile-time constant
ys >> 8, ys & 0xff, /* YSTART */
~~~^~~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
drivers/staging/fbtft/fb_hx8357d.c:174:44: error: initializer element is not a compile-time constant
write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, val);
^~~
drivers/staging/fbtft/fbtft.h:237:47: note: expanded from macro 'write_reg'
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
^~~~~~~~~~~
drivers/staging/fbtft/fbtft.h:234:44: note: expanded from macro 'NUMARGS'
#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ }))
^~~~~~~~~~~
include/linux/kernel.h:55:75: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
include/linux/compiler.h:232:59: note: expanded from macro '__must_be_array'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/compiler_types.h:298:63: note: expanded from macro '__same_type'
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
^
include/linux/build_bug.h:16:62: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
3 errors generated.
..
vim +206 drivers/staging/fbtft/fbtft-core.c
c296d5f9957c03 Thomas Petazzoni 2014-12-31 201
ed2084360d040a Krzysztof Adamski 2015-01-22 202 static void fbtft_set_addr_win(struct fbtft_par *par, int xs, int ys, int xe,
ed2084360d040a Krzysztof Adamski 2015-01-22 203 int ye)
c296d5f9957c03 Thomas Petazzoni 2014-12-31 204 {
a79cb3901ee3e0 Priit Laes 2015-12-20 205 write_reg(par, MIPI_DCS_SET_COLUMN_ADDRESS,
c296d5f9957c03 Thomas Petazzoni 2014-12-31 @206 (xs >> 8) & 0xFF, xs & 0xFF, (xe >> 8) & 0xFF, xe & 0xFF);
c296d5f9957c03 Thomas Petazzoni 2014-12-31 207
a79cb3901ee3e0 Priit Laes 2015-12-20 208 write_reg(par, MIPI_DCS_SET_PAGE_ADDRESS,
c296d5f9957c03 Thomas Petazzoni 2014-12-31 209 (ys >> 8) & 0xFF, ys & 0xFF, (ye >> 8) & 0xFF, ye & 0xFF);
c296d5f9957c03 Thomas Petazzoni 2014-12-31 210
a79cb3901ee3e0 Priit Laes 2015-12-20 211 write_reg(par, MIPI_DCS_WRITE_MEMORY_START);
c296d5f9957c03 Thomas Petazzoni 2014-12-31 212 }
c296d5f9957c03 Thomas Petazzoni 2014-12-31 213
On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > number of elements in an array. Issue identified using coccicheck. > > Signed-off-by: Deepak R Varma <drv@mailo.com> > --- > drivers/staging/fbtft/fbtft.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > index 2c2b5f1c1df3..5506a473be91 100644 > --- a/drivers/staging/fbtft/fbtft.h > +++ b/drivers/staging/fbtft/fbtft.h > @@ -231,7 +231,7 @@ struct fbtft_par { > bool polarity; > }; > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) Please please please test-build your patches before sending them out. To not do so just wastes reviewer resources :( thanks, greg k-h
On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > number of elements in an array. Issue identified using coccicheck. > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > --- > > drivers/staging/fbtft/fbtft.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > index 2c2b5f1c1df3..5506a473be91 100644 > > --- a/drivers/staging/fbtft/fbtft.h > > +++ b/drivers/staging/fbtft/fbtft.h > > @@ -231,7 +231,7 @@ struct fbtft_par { > > bool polarity; > > }; > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > Please please please test-build your patches before sending them out. > To not do so just wastes reviewer resources :( Hello Greg, I did build the .ko files by making the driver/staging/fbtft/ path. I verified .o and .ko files were built. I did a make clean just now and was again able to rebuild without any errors. Please see the attached log file. Is there something wrong with the way I am firing the build? Thank you, ./drv > > thanks, > > greg k-h drv@ubunlion:~/git/kernels/staging$ git show HEAD commit d7f07b9179428a4b84bcb7a90574edcea8c37fc4 (HEAD -> cocci-patches) Author: Deepak R Varma <drv@mailo.com> Date: Fri Oct 28 18:40:54 2022 +0530 staging: fbtft: Use ARRAY_SIZE() to get argument count The ARRAY_SIZE(foo) macro should be preferred over sizeof operator based computation such as sizeof(foo)/sizeof(foo[0]) for finding number of elements in an array. Issue identified using coccicheck. Signed-off-by: Deepak R Varma <drv@mailo.com> diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h index 2c2b5f1c1df3..5506a473be91 100644 --- a/drivers/staging/fbtft/fbtft.h +++ b/drivers/staging/fbtft/fbtft.h @@ -231,7 +231,7 @@ struct fbtft_par { bool polarity; }; -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) #define write_reg(par, ...) \ ((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__)) drv@ubunlion:~/git/kernels/staging$ make M=drivers/staging/fbtft/ drv@ubunlion:~/git/kernels/staging$ make M=drivers/staging/fbtft/ clean CLEAN drivers/staging/fbtft/Module.symvers drv@ubunlion:~/git/kernels/staging$ make M=drivers/staging/fbtft/ CC [M] drivers/staging/fbtft/fbtft-core.o CC [M] drivers/staging/fbtft/fbtft-sysfs.o CC [M] drivers/staging/fbtft/fbtft-bus.o CC [M] drivers/staging/fbtft/fbtft-io.o LD [M] drivers/staging/fbtft/fbtft.o CC [M] drivers/staging/fbtft/fb_agm1264k-fl.o CC [M] drivers/staging/fbtft/fb_bd663474.o CC [M] drivers/staging/fbtft/fb_hx8340bn.o CC [M] drivers/staging/fbtft/fb_hx8347d.o CC [M] drivers/staging/fbtft/fb_hx8353d.o CC [M] drivers/staging/fbtft/fb_hx8357d.o CC [M] drivers/staging/fbtft/fb_ili9163.o CC [M] drivers/staging/fbtft/fb_ili9320.o CC [M] drivers/staging/fbtft/fb_ili9325.o CC [M] drivers/staging/fbtft/fb_ili9340.o CC [M] drivers/staging/fbtft/fb_ili9341.o CC [M] drivers/staging/fbtft/fb_ili9481.o CC [M] drivers/staging/fbtft/fb_ili9486.o CC [M] drivers/staging/fbtft/fb_pcd8544.o CC [M] drivers/staging/fbtft/fb_ra8875.o CC [M] drivers/staging/fbtft/fb_s6d02a1.o CC [M] drivers/staging/fbtft/fb_s6d1121.o CC [M] drivers/staging/fbtft/fb_seps525.o CC [M] drivers/staging/fbtft/fb_sh1106.o CC [M] drivers/staging/fbtft/fb_ssd1289.o CC [M] drivers/staging/fbtft/fb_ssd1305.o CC [M] drivers/staging/fbtft/fb_ssd1306.o CC [M] drivers/staging/fbtft/fb_ssd1325.o CC [M] drivers/staging/fbtft/fb_ssd1331.o CC [M] drivers/staging/fbtft/fb_ssd1351.o CC [M] drivers/staging/fbtft/fb_st7735r.o CC [M] drivers/staging/fbtft/fb_st7789v.o CC [M] drivers/staging/fbtft/fb_tinylcd.o CC [M] drivers/staging/fbtft/fb_tls8204.o CC [M] drivers/staging/fbtft/fb_uc1611.o CC [M] drivers/staging/fbtft/fb_uc1701.o CC [M] drivers/staging/fbtft/fb_upd161704.o MODPOST drivers/staging/fbtft/Module.symvers CC [M] drivers/staging/fbtft/fb_agm1264k-fl.mod.o LD [M] drivers/staging/fbtft/fb_agm1264k-fl.ko BTF [M] drivers/staging/fbtft/fb_agm1264k-fl.ko Skipping BTF generation for drivers/staging/fbtft/fb_agm1264k-fl.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_bd663474.mod.o LD [M] drivers/staging/fbtft/fb_bd663474.ko BTF [M] drivers/staging/fbtft/fb_bd663474.ko Skipping BTF generation for drivers/staging/fbtft/fb_bd663474.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_hx8340bn.mod.o LD [M] drivers/staging/fbtft/fb_hx8340bn.ko BTF [M] drivers/staging/fbtft/fb_hx8340bn.ko Skipping BTF generation for drivers/staging/fbtft/fb_hx8340bn.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_hx8347d.mod.o LD [M] drivers/staging/fbtft/fb_hx8347d.ko BTF [M] drivers/staging/fbtft/fb_hx8347d.ko Skipping BTF generation for drivers/staging/fbtft/fb_hx8347d.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_hx8353d.mod.o LD [M] drivers/staging/fbtft/fb_hx8353d.ko BTF [M] drivers/staging/fbtft/fb_hx8353d.ko Skipping BTF generation for drivers/staging/fbtft/fb_hx8353d.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_hx8357d.mod.o LD [M] drivers/staging/fbtft/fb_hx8357d.ko BTF [M] drivers/staging/fbtft/fb_hx8357d.ko Skipping BTF generation for drivers/staging/fbtft/fb_hx8357d.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9163.mod.o LD [M] drivers/staging/fbtft/fb_ili9163.ko BTF [M] drivers/staging/fbtft/fb_ili9163.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9163.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9320.mod.o LD [M] drivers/staging/fbtft/fb_ili9320.ko BTF [M] drivers/staging/fbtft/fb_ili9320.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9320.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9325.mod.o LD [M] drivers/staging/fbtft/fb_ili9325.ko BTF [M] drivers/staging/fbtft/fb_ili9325.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9325.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9340.mod.o LD [M] drivers/staging/fbtft/fb_ili9340.ko BTF [M] drivers/staging/fbtft/fb_ili9340.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9340.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9341.mod.o LD [M] drivers/staging/fbtft/fb_ili9341.ko BTF [M] drivers/staging/fbtft/fb_ili9341.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9341.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9481.mod.o LD [M] drivers/staging/fbtft/fb_ili9481.ko BTF [M] drivers/staging/fbtft/fb_ili9481.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9481.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ili9486.mod.o LD [M] drivers/staging/fbtft/fb_ili9486.ko BTF [M] drivers/staging/fbtft/fb_ili9486.ko Skipping BTF generation for drivers/staging/fbtft/fb_ili9486.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_pcd8544.mod.o LD [M] drivers/staging/fbtft/fb_pcd8544.ko BTF [M] drivers/staging/fbtft/fb_pcd8544.ko Skipping BTF generation for drivers/staging/fbtft/fb_pcd8544.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ra8875.mod.o LD [M] drivers/staging/fbtft/fb_ra8875.ko BTF [M] drivers/staging/fbtft/fb_ra8875.ko Skipping BTF generation for drivers/staging/fbtft/fb_ra8875.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_s6d02a1.mod.o LD [M] drivers/staging/fbtft/fb_s6d02a1.ko BTF [M] drivers/staging/fbtft/fb_s6d02a1.ko Skipping BTF generation for drivers/staging/fbtft/fb_s6d02a1.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_s6d1121.mod.o LD [M] drivers/staging/fbtft/fb_s6d1121.ko BTF [M] drivers/staging/fbtft/fb_s6d1121.ko Skipping BTF generation for drivers/staging/fbtft/fb_s6d1121.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_seps525.mod.o LD [M] drivers/staging/fbtft/fb_seps525.ko BTF [M] drivers/staging/fbtft/fb_seps525.ko Skipping BTF generation for drivers/staging/fbtft/fb_seps525.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_sh1106.mod.o LD [M] drivers/staging/fbtft/fb_sh1106.ko BTF [M] drivers/staging/fbtft/fb_sh1106.ko Skipping BTF generation for drivers/staging/fbtft/fb_sh1106.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1289.mod.o LD [M] drivers/staging/fbtft/fb_ssd1289.ko BTF [M] drivers/staging/fbtft/fb_ssd1289.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1289.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1305.mod.o LD [M] drivers/staging/fbtft/fb_ssd1305.ko BTF [M] drivers/staging/fbtft/fb_ssd1305.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1305.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1306.mod.o LD [M] drivers/staging/fbtft/fb_ssd1306.ko BTF [M] drivers/staging/fbtft/fb_ssd1306.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1306.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1325.mod.o LD [M] drivers/staging/fbtft/fb_ssd1325.ko BTF [M] drivers/staging/fbtft/fb_ssd1325.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1325.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1331.mod.o LD [M] drivers/staging/fbtft/fb_ssd1331.ko BTF [M] drivers/staging/fbtft/fb_ssd1331.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1331.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_ssd1351.mod.o LD [M] drivers/staging/fbtft/fb_ssd1351.ko BTF [M] drivers/staging/fbtft/fb_ssd1351.ko Skipping BTF generation for drivers/staging/fbtft/fb_ssd1351.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_st7735r.mod.o LD [M] drivers/staging/fbtft/fb_st7735r.ko BTF [M] drivers/staging/fbtft/fb_st7735r.ko Skipping BTF generation for drivers/staging/fbtft/fb_st7735r.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_st7789v.mod.o LD [M] drivers/staging/fbtft/fb_st7789v.ko BTF [M] drivers/staging/fbtft/fb_st7789v.ko Skipping BTF generation for drivers/staging/fbtft/fb_st7789v.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_tinylcd.mod.o LD [M] drivers/staging/fbtft/fb_tinylcd.ko BTF [M] drivers/staging/fbtft/fb_tinylcd.ko Skipping BTF generation for drivers/staging/fbtft/fb_tinylcd.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_tls8204.mod.o LD [M] drivers/staging/fbtft/fb_tls8204.ko BTF [M] drivers/staging/fbtft/fb_tls8204.ko Skipping BTF generation for drivers/staging/fbtft/fb_tls8204.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_uc1611.mod.o LD [M] drivers/staging/fbtft/fb_uc1611.ko BTF [M] drivers/staging/fbtft/fb_uc1611.ko Skipping BTF generation for drivers/staging/fbtft/fb_uc1611.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_uc1701.mod.o LD [M] drivers/staging/fbtft/fb_uc1701.ko BTF [M] drivers/staging/fbtft/fb_uc1701.ko Skipping BTF generation for drivers/staging/fbtft/fb_uc1701.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fb_upd161704.mod.o LD [M] drivers/staging/fbtft/fb_upd161704.ko BTF [M] drivers/staging/fbtft/fb_upd161704.ko Skipping BTF generation for drivers/staging/fbtft/fb_upd161704.ko due to unavailability of vmlinux CC [M] drivers/staging/fbtft/fbtft.mod.o LD [M] drivers/staging/fbtft/fbtft.ko BTF [M] drivers/staging/fbtft/fbtft.ko Skipping BTF generation for drivers/staging/fbtft/fbtft.ko due to unavailability of vmlinux drv@ubunlion:~/git/kernels/staging$
On Sat, 29 Oct 2022, Deepak R Varma wrote: > On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > > number of elements in an array. Issue identified using coccicheck. > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > --- > > > drivers/staging/fbtft/fbtft.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > > index 2c2b5f1c1df3..5506a473be91 100644 > > > --- a/drivers/staging/fbtft/fbtft.h > > > +++ b/drivers/staging/fbtft/fbtft.h > > > @@ -231,7 +231,7 @@ struct fbtft_par { > > > bool polarity; > > > }; > > > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > > > Please please please test-build your patches before sending them out. > > To not do so just wastes reviewer resources :( > > Hello Greg, > I did build the .ko files by making the driver/staging/fbtft/ path. I verified > .o and .ko files were built. > > I did a make clean just now and was again able to rebuild without any errors. > Please see the attached log file. > > Is there something wrong with the way I am firing the build? The change is in the definition of a macro. The compiler won't help you in this case unless the macro is actually used in code that is compiled. Find the uses and check for any nearby ifdefs. For file foo.c you can also do make foo.i to see the result of reducing ifdef and expanding macros. Then you can see if the code you changed is actually included in the build. julia
On Sat, Oct 29, 2022 at 07:34:26PM +0200, Julia Lawall wrote: > > > On Sat, 29 Oct 2022, Deepak R Varma wrote: > > > On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > > > number of elements in an array. Issue identified using coccicheck. > > > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > > --- > > > > drivers/staging/fbtft/fbtft.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > > > index 2c2b5f1c1df3..5506a473be91 100644 > > > > --- a/drivers/staging/fbtft/fbtft.h > > > > +++ b/drivers/staging/fbtft/fbtft.h > > > > @@ -231,7 +231,7 @@ struct fbtft_par { > > > > bool polarity; > > > > }; > > > > > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > > > > > Please please please test-build your patches before sending them out. > > > To not do so just wastes reviewer resources :( > > > > Hello Greg, > > I did build the .ko files by making the driver/staging/fbtft/ path. I verified > > .o and .ko files were built. > > > > I did a make clean just now and was again able to rebuild without any errors. > > Please see the attached log file. > > > > Is there something wrong with the way I am firing the build? > > The change is in the definition of a macro. The compiler won't help you > in this case unless the macro is actually used in code that is compiled. > Find the uses and check for any nearby ifdefs. For file foo.c you can > also do make foo.i to see the result of reducing ifdef and expanding > macros. Then you can see if the code you changed is actually included in > the build. Okay. This is helpful. I understand. Looking into the file where the macro expansion is reported to be failed. Thank you, ./drv > > julia >
On Mon, Oct 31, 2022 at 12:41:40PM +0530, Deepak Varma wrote: > On Sat, Oct 29, 2022 at 07:34:26PM +0200, Julia Lawall wrote: > > > > > > On Sat, 29 Oct 2022, Deepak R Varma wrote: > > > > > On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > > > > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > > > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > > > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > > > > number of elements in an array. Issue identified using coccicheck. > > > > > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > > > --- > > > > > drivers/staging/fbtft/fbtft.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > > > > index 2c2b5f1c1df3..5506a473be91 100644 > > > > > --- a/drivers/staging/fbtft/fbtft.h > > > > > +++ b/drivers/staging/fbtft/fbtft.h > > > > > @@ -231,7 +231,7 @@ struct fbtft_par { > > > > > bool polarity; > > > > > }; > > > > > > > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > > > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > > > > > > > Please please please test-build your patches before sending them out. > > > > To not do so just wastes reviewer resources :( > > > > > > Hello Greg, > > > I did build the .ko files by making the driver/staging/fbtft/ path. I verified > > > .o and .ko files were built. > > > > > > I did a make clean just now and was again able to rebuild without any errors. > > > Please see the attached log file. > > > > > > Is there something wrong with the way I am firing the build? > > > > The change is in the definition of a macro. The compiler won't help you > > in this case unless the macro is actually used in code that is compiled. > > Find the uses and check for any nearby ifdefs. For file foo.c you can > > also do make foo.i to see the result of reducing ifdef and expanding > > macros. Then you can see if the code you changed is actually included in > > the build. > > Okay. This is helpful. I understand. Looking into the file where the macro > expansion is reported to be failed. Hi Julia, I could see the macro expansions in the .i files for the fbtft-core.c and fb_hx8353d.c file. I am not sure why it built successfully on my x86 though. The error in Kerbel bot seems to be specific to ARM arch. I will try that later today. I am on the right track to the build error triage? Also, while reviewing the macro expansion, I saw change in the computation that seems odd to me. In the denominator of the expanded macro, there is a "+ ((int)...." computation that I am not sure if is result of ARRAY_SIZE. I have attached the old anf the new .i file diff for your review. If you get a change could you help me understand why this additional computation is added to the denominator? Thank you, ./drv > > Thank you, > ./drv > > > > > julia > > > > >
On Mon, Oct 31, 2022 at 03:10:27PM +0530, Deepak Varma wrote: > On Mon, Oct 31, 2022 at 12:41:40PM +0530, Deepak Varma wrote: > > On Sat, Oct 29, 2022 at 07:34:26PM +0200, Julia Lawall wrote: > > > > > > > > > On Sat, 29 Oct 2022, Deepak R Varma wrote: > > > > > > > On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > > > > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > > > > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > > > > > number of elements in an array. Issue identified using coccicheck. > > > > > > > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > > > > --- > > > > > > drivers/staging/fbtft/fbtft.h | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > > > > > index 2c2b5f1c1df3..5506a473be91 100644 > > > > > > --- a/drivers/staging/fbtft/fbtft.h > > > > > > +++ b/drivers/staging/fbtft/fbtft.h > > > > > > @@ -231,7 +231,7 @@ struct fbtft_par { > > > > > > bool polarity; > > > > > > }; > > > > > > > > > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > > > > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > > > > > > > > > Please please please test-build your patches before sending them out. > > > > > To not do so just wastes reviewer resources :( > > > > > > > > Hello Greg, > > > > I did build the .ko files by making the driver/staging/fbtft/ path. I verified > > > > .o and .ko files were built. > > > > > > > > I did a make clean just now and was again able to rebuild without any errors. > > > > Please see the attached log file. > > > > > > > > Is there something wrong with the way I am firing the build? > > > > > > The change is in the definition of a macro. The compiler won't help you > > > in this case unless the macro is actually used in code that is compiled. > > > Find the uses and check for any nearby ifdefs. For file foo.c you can > > > also do make foo.i to see the result of reducing ifdef and expanding > > > macros. Then you can see if the code you changed is actually included in > > > the build. > > > > Okay. This is helpful. I understand. Looking into the file where the macro > > expansion is reported to be failed. > > Hi Julia, > I could see the macro expansions in the .i files for the fbtft-core.c and > fb_hx8353d.c file. I am not sure why it built successfully on my x86 though. The > error in Kerbel bot seems to be specific to ARM arch. I will try that later > today. I am on the right track to the build error triage? > > Also, while reviewing the macro expansion, I saw change in the computation that > seems odd to me. In the denominator of the expanded macro, there is a "+ > ((int)...." computation that I am not sure if is result of ARRAY_SIZE. I have > attached the old anf the new .i file diff for your review. If you get a change > could you help me understand why this additional computation is added to the > denominator? File now attached. > > Thank you, > ./drv > > > > Thank you, > > ./drv > > > > > > > > julia > > > > > > > > > > > >
On Mon, 31 Oct 2022, Deepak R Varma wrote: > On Mon, Oct 31, 2022 at 12:41:40PM +0530, Deepak Varma wrote: > > On Sat, Oct 29, 2022 at 07:34:26PM +0200, Julia Lawall wrote: > > > > > > > > > On Sat, 29 Oct 2022, Deepak R Varma wrote: > > > > > > > On Sat, Oct 29, 2022 at 09:32:50AM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 28, 2022 at 07:00:05PM +0530, Deepak R Varma wrote: > > > > > > The ARRAY_SIZE(foo) macro should be preferred over sizeof operator > > > > > > based computation such as sizeof(foo)/sizeof(foo[0]) for finding > > > > > > number of elements in an array. Issue identified using coccicheck. > > > > > > > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > > > > --- > > > > > > drivers/staging/fbtft/fbtft.h | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h > > > > > > index 2c2b5f1c1df3..5506a473be91 100644 > > > > > > --- a/drivers/staging/fbtft/fbtft.h > > > > > > +++ b/drivers/staging/fbtft/fbtft.h > > > > > > @@ -231,7 +231,7 @@ struct fbtft_par { > > > > > > bool polarity; > > > > > > }; > > > > > > > > > > > > -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) > > > > > > +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) > > > > > > > > > > Please please please test-build your patches before sending them out. > > > > > To not do so just wastes reviewer resources :( > > > > > > > > Hello Greg, > > > > I did build the .ko files by making the driver/staging/fbtft/ path. I verified > > > > .o and .ko files were built. > > > > > > > > I did a make clean just now and was again able to rebuild without any errors. > > > > Please see the attached log file. > > > > > > > > Is there something wrong with the way I am firing the build? > > > > > > The change is in the definition of a macro. The compiler won't help you > > > in this case unless the macro is actually used in code that is compiled. > > > Find the uses and check for any nearby ifdefs. For file foo.c you can > > > also do make foo.i to see the result of reducing ifdef and expanding > > > macros. Then you can see if the code you changed is actually included in > > > the build. > > > > Okay. This is helpful. I understand. Looking into the file where the macro > > expansion is reported to be failed. > > Hi Julia, > I could see the macro expansions in the .i files for the fbtft-core.c and > fb_hx8353d.c file. I am not sure why it built successfully on my x86 though. The > error in Kerbel bot seems to be specific to ARM arch. I will try that later > today. I am on the right track to the build error triage? > > Also, while reviewing the macro expansion, I saw change in the computation that > seems odd to me. In the denominator of the expanded macro, there is a "+ > ((int)...." computation that I am not sure if is result of ARRAY_SIZE. I have > attached the old anf the new .i file diff for your review. If you get a change > could you help me understand why this additional computation is added to the > denominator? I took a look, but it's pretty complex. You could take the code and reorganize it so that it is more readable, and then take the definition of the ARRAY_SIZE macro, to better see what is going on. julia > > Thank you, > ./drv > > > > Thank you, > > ./drv > > > > > > > > julia > > > > > > > > > > > >
On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote: > > > I took a look, but it's pretty complex. You could take the code and > reorganize it so that it is more readable, and then take the definition of > the ARRAY_SIZE macro, to better see what is going on. > > julia > Hello Greg, Julia, I was able to successfully build the fbtft object file for arm architecture as well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using both. I have attached the build log from my machine for your reference. I am also looking at the .i file and rearrange the expanded macro to understand it. However, since it is built successfully, I am not sure if that is truly the problem area. Should I resend the patch and check if it still errors the kernel build bot? Anything else I can try? Thank you, ./drv drv@qemulion:~/git/kernels/staging$ git status On branch patches-11022022 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: drivers/staging/fbtft/fbtft.h no changes added to commit (use "git add" and/or "git commit -a") drv@qemulion:~/git/kernels/staging$ git diff diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h index 2c2b5f1c1df3..f2ed23123849 100644 --- a/drivers/staging/fbtft/fbtft.h +++ b/drivers/staging/fbtft/fbtft.h @@ -231,7 +231,7 @@ struct fbtft_par { bool polarity; }; -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) #define write_reg(par, ...) \ ((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__)) drv@qemulion:~/git/kernels/staging$ make CROSS_COMPILE=/opt/gcc-9.5.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi- --jobs=8 ARCH=arm drivers/staging/fbtft/fbtft-core.o CALL scripts/checksyscalls.sh CC drivers/staging/fbtft/fbtft-core.o drv@qemulion:~/git/kernels/staging$ make CROSS_COMPILE=/opt/gcc-9.5.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi- --jobs=8 ARCH=arm drivers/staging/fbtft/ CALL scripts/checksyscalls.sh CC drivers/staging/fbtft/fbtft-sysfs.o CC drivers/staging/fbtft/fbtft-bus.o CC drivers/staging/fbtft/fbtft-io.o CC drivers/staging/fbtft/fb_agm1264k-fl.o CC drivers/staging/fbtft/fb_bd663474.o CC drivers/staging/fbtft/fb_hx8340bn.o CC drivers/staging/fbtft/fb_hx8347d.o CC drivers/staging/fbtft/fb_hx8353d.o CC drivers/staging/fbtft/fb_hx8357d.o CC drivers/staging/fbtft/fb_ili9163.o CC drivers/staging/fbtft/fb_ili9320.o CC drivers/staging/fbtft/fb_ili9325.o CC drivers/staging/fbtft/fb_ili9340.o CC drivers/staging/fbtft/fb_ili9341.o CC drivers/staging/fbtft/fb_ili9481.o CC drivers/staging/fbtft/fb_ili9486.o CC drivers/staging/fbtft/fb_pcd8544.o CC drivers/staging/fbtft/fb_ra8875.o CC drivers/staging/fbtft/fb_s6d02a1.o CC drivers/staging/fbtft/fb_s6d1121.o CC drivers/staging/fbtft/fb_seps525.o CC drivers/staging/fbtft/fb_sh1106.o CC drivers/staging/fbtft/fb_ssd1289.o CC drivers/staging/fbtft/fb_ssd1305.o CC drivers/staging/fbtft/fb_ssd1306.o CC drivers/staging/fbtft/fb_ssd1325.o CC drivers/staging/fbtft/fb_ssd1331.o CC drivers/staging/fbtft/fb_ssd1351.o CC drivers/staging/fbtft/fb_st7735r.o CC drivers/staging/fbtft/fb_st7789v.o CC drivers/staging/fbtft/fb_tinylcd.o CC drivers/staging/fbtft/fb_tls8204.o CC drivers/staging/fbtft/fb_uc1611.o CC drivers/staging/fbtft/fb_uc1701.o CC drivers/staging/fbtft/fb_upd161704.o AR drivers/staging/fbtft/built-in.a drv@qemulion:~/git/kernels/staging$
On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote: > On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote: > > > > > > I took a look, but it's pretty complex. You could take the code and > > reorganize it so that it is more readable, and then take the definition of > > the ARRAY_SIZE macro, to better see what is going on. > > > > julia > > > > Hello Greg, Julia, > I was able to successfully build the fbtft object file for arm architecture as > well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using both. I > have attached the build log from my machine for your reference. > > I am also looking at the .i file and rearrange the expanded macro to understand > it. However, since it is built successfully, I am not sure if that is truly the > problem area. > > Should I resend the patch and check if it still errors the kernel build bot? > Anything else I can try? Looks like the change I proposed is causing nesting inside the write_reg function due to additional set of { & } brackets for the __VA_ARGS__ symbol. Am I understanding it right? > > Thank you, > ./drv
On Fri, Nov 04, 2022 at 08:12:11PM +0530, Deepak R Varma wrote: > On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote: > > On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote: > > > > > > > > > I took a look, but it's pretty complex. You could take the code and > > > reorganize it so that it is more readable, and then take the definition of > > > the ARRAY_SIZE macro, to better see what is going on. > > > > > > julia > > > > > > > Hello Greg, Julia, > > I was able to successfully build the fbtft object file for arm architecture as > > well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using both. I > > have attached the build log from my machine for your reference. > > > > I am also looking at the .i file and rearrange the expanded macro to understand > > it. However, since it is built successfully, I am not sure if that is truly the > > problem area. > > > > Should I resend the patch and check if it still errors the kernel build bot? > > Anything else I can try? > > Looks like the change I proposed is causing nesting inside the write_reg > function due to additional set of { & } brackets for the __VA_ARGS__ symbol. > > Am I understanding it right? Hello Julia, Greg, I am unable to reproduce this build failure on my local machine. I tried the X86 and arm based build. I am unable to troubleshoot this further. Do you have any other suggestions? If not, I will drop this patch from my watch list. Thank you, ./drv > > > > > Thank you, > > ./drv > > > >
On Wed, Nov 09, 2022 at 08:30:52PM +0530, Deepak R Varma wrote: > On Fri, Nov 04, 2022 at 08:12:11PM +0530, Deepak R Varma wrote: > > On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote: > > > On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote: > > > > > > > > > > > > I took a look, but it's pretty complex. You could take the code and > > > > reorganize it so that it is more readable, and then take the definition of > > > > the ARRAY_SIZE macro, to better see what is going on. > > > > > > > > julia > > > > > > > > > > Hello Greg, Julia, > > > I was able to successfully build the fbtft object file for arm architecture as > > > well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using both. I > > > have attached the build log from my machine for your reference. > > > > > > I am also looking at the .i file and rearrange the expanded macro to understand > > > it. However, since it is built successfully, I am not sure if that is truly the > > > problem area. > > > > > > Should I resend the patch and check if it still errors the kernel build bot? > > > Anything else I can try? > > > > Looks like the change I proposed is causing nesting inside the write_reg > > function due to additional set of { & } brackets for the __VA_ARGS__ symbol. > > > > Am I understanding it right? > > Hello Julia, Greg, > I am unable to reproduce this build failure on my local machine. I tried the X86 > and arm based build. I am unable to troubleshoot this further. Do you have any > other suggestions? If not, I will drop this patch from my watch list. Please just drop it, it is not a correct change to make. thanks, greg k-h
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h index 2c2b5f1c1df3..5506a473be91 100644 --- a/drivers/staging/fbtft/fbtft.h +++ b/drivers/staging/fbtft/fbtft.h @@ -231,7 +231,7 @@ struct fbtft_par { bool polarity; }; -#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int)) +#define NUMARGS(...) ARRAY_SIZE(((int[]){ __VA_ARGS__ })) #define write_reg(par, ...) \ ((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))