Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1390666pxb; Sat, 16 Apr 2022 07:13:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjqxMIriWbl/ASgl6EJIt45wIKEg9MhP4pbhk1MuDvQMjkXAOtSaNmXD5XrHArk8r/AWvq X-Received: by 2002:a17:907:a40c:b0:6ef:7bd7:a508 with SMTP id sg12-20020a170907a40c00b006ef7bd7a508mr2065303ejc.614.1650118436300; Sat, 16 Apr 2022 07:13:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650118436; cv=none; d=google.com; s=arc-20160816; b=rWACfglypa9LnWWvuabcoNHHOS3XKCHX9e9CVR5KKohgt/znQtAHbs7JTxHHmug5KG vfAUv8IXfAa7s0DlclkbID+pXjwnWI2rMVFhZFGkdHOSA9ojmBOB8mA8MbnYYQrhQalU 6yu2WRzbYKGXqzk5ESPAFizSQP8rqdmjMUw7rxbfIaxeCo1VvyZKFbVEwUzZsaAWHDED aNNs9I+aqSatQAphj97irfi16oZ/HFij/o5++GQKkUk2wyHBLDCW4Z2omhJgSsNlDUuS TlPDsBD6oauZf9uHpbIgXGJreiis7YL+Ro3LdttoaExCG9zOVS9BYusJi+JY9t6vwnQC rrTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Taa5X8R6tZvEoEPIRaZwVxvIevFhDa8M1pC+96G/AI8=; b=z/MwBZlvN++KOMpeNcEnBJJAqac6SDXWK6X/4STXWZMYOpYeXlkMWYJCxv0LtHYNmf MONFRPsLJcON/JGL4ZgxSihJgEVsC4W3L3p9Jthhe5hnAVkdYDGjY8NkRQVG2YOCV62Y aPX+JtqtOL9Yp7VLxM9uTAK2dV2A8IoouLzgm4QGLskcGerVCIGnaYH/9Npp8m6SoNwE KyU8K2OiiPiKARHIuMePLY69+b8sJ44Ft4V7PAVTKGDRQKnOa3n/vQZWlYgRbVyRUUU8 UE/btFEurqMq0OeDvUg+sBSNpESreGNFsS20vbGXasndit00+i3nrKF8BcWpbj1TH9QW 2Yfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mpgWMiO5; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id zd8-20020a17090698c800b006e871a3f9aasi2701584ejb.924.2022.04.16.07.13.24; Sat, 16 Apr 2022 07:13:56 -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=pass header.i=@intel.com header.s=Intel header.b=mpgWMiO5; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229732AbiDPHz5 (ORCPT + 99 others); Sat, 16 Apr 2022 03:55:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbiDPHzz (ORCPT ); Sat, 16 Apr 2022 03:55:55 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E2C110877E; Sat, 16 Apr 2022 00:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650095604; x=1681631604; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xV/d1iJRhjqgFrWqpQ6qFBsR6GoGgFOYv3MLCdk9Kno=; b=mpgWMiO57rMiBl/urS2/YiUpbxeo0GGvGVJPRrNC5egTLMn7LEy6x7Qq IONHLF7vz5SXZo23UV5O5R/MmWe5KbsggRCk4hYmdRb58XoT3CvjTCNAB lhAI66x+NDsHLLM1cCWUJvAIDmaZF7gUDuyqJNxTPYUOQWgBkWpYH+sg6 My4ZjXqeR2/h0KHWqU8pMaUFXP8euyPhBlhORG/5r5FPQfcfpikJ2OwTq uWnO3ivqonicm4UitwNWZdoUkWE+98zRGuGXuObA5iuNqV9SsHAyL4wmb Oat7+MMd5J7RK3ljj28590uA4kmFfHFdaFQPEem5zm08DrwirER+DzB+J A==; X-IronPort-AV: E=McAfee;i="6400,9594,10318"; a="243859024" X-IronPort-AV: E=Sophos;i="5.90,264,1643702400"; d="scan'208";a="243859024" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2022 00:53:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,264,1643702400"; d="scan'208";a="528214753" Received: from xpf.sh.intel.com ([10.239.182.112]) by orsmga006.jf.intel.com with ESMTP; 16 Apr 2022 00:53:19 -0700 Date: Sat, 16 Apr 2022 15:52:00 +0800 From: Pengfei Xu To: Reinette Chatre Cc: shuah@kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com, sandipan@linux.ibm.com, fweimer@redhat.com, desnesn@linux.vnet.ibm.com, mingo@kernel.org, bauerman@linux.ibm.com, mpe@ellerman.id.au, msuchanek@suse.de, linux-mm@kvack.org, chang.seok.bae@intel.com, bp@suse.de, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, luto@kernel.org, heng.su@intel.com Subject: Re: [PATCH V2 1/4] selftests: Provide local define of __cpuid_count() Message-ID: References: <7c49dbfe5bab04389ed84c516fcbfe31d66df880.1647360971.git.reinette.chatre@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c49dbfe5bab04389ed84c516fcbfe31d66df880.1647360971.git.reinette.chatre@intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-03-15 at 09:44:25 -0700, Reinette Chatre wrote: > Some selftests depend on information provided by the CPUID instruction. > To support this dependency the selftests implement private wrappers for > CPUID. > > Duplication of the CPUID wrappers should be avoided. > > Both gcc and clang/LLVM provide __cpuid_count() macros but neither > the macro nor its header file are available in all the compiler > versions that need to be supported by the selftests. __cpuid_count() > as provided by gcc is available starting with gcc v4.4, so it is > not available if the latest tests need to be run in all the > environments required to support kernels v4.9 and v4.14 that > have the minimal required gcc v3.2. > > Provide a centrally defined macro for __cpuid_count() to help > eliminate the duplicate CPUID wrappers while continuing to > compile in older environments. > > Suggested-by: Shuah Khan > Signed-off-by: Reinette Chatre > --- > Note to maintainers: > - Macro is identical to the one provided by gcc, but not liked by > checkpatch.pl with message "Macros with complex values should > be enclosed in parentheses". Similar style is used in kernel, > for example in arch/x86/kernel/fpu/xstate.h. > > tools/testing/selftests/kselftest.h | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h > index f1180987492c..898d7b2fac6c 100644 > --- a/tools/testing/selftests/kselftest.h > +++ b/tools/testing/selftests/kselftest.h > @@ -52,6 +52,21 @@ > + * have __cpuid_count(). > + */ > +#ifndef __cpuid_count > +#define __cpuid_count(level, count, a, b, c, d) \ > + __asm__ __volatile__ ("cpuid\n\t" \ > + : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ > + : "0" (level), "2" (count)) > +#endif Linux C check tool "scripts/checkpatch.pl" shows an error: " ERROR: Macros with complex values should be enclosed in parentheses ... +#define __cpuid_count(level, count, a, b, c, d) \ + __asm__ __volatile__ ("cpuid\n\t" \ + : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ + : "0" (level), "2" (count)) " Googling: https://www.google.com/search?q=Macros+with+complex+values+should+be+enclosed+in+parentheses&rlz=1C1GCEB_enUS884US884&oq=Macros+with+complex+values+should+be+enclosed+in+parentheses&aqs=chrome.0.69i59j0i5i30l2.313j0j7&sourceid=chrome&ie=UTF-8 -> https://stackoverflow.com/questions/8142280/why-do-we-need-parentheses-around-block-macro Could we fix it as follow, shall we? " #ifndef __cpuid_count #define __cpuid_count(level, count, a, b, c, d) ({ \ __asm__ __volatile__ ("cpuid\n\t" \ : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ : "0" (level), "2" (count)) \ }) #endif " Thanks! --Pengfei