From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74F65C433EF for ; Tue, 19 Apr 2022 04:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE9A66B00D4; Tue, 19 Apr 2022 00:32:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E984A6B00D5; Tue, 19 Apr 2022 00:32:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D60686B00D7; Tue, 19 Apr 2022 00:32:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id C69956B00D4 for ; Tue, 19 Apr 2022 00:32:53 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4A828A5658 for ; Tue, 19 Apr 2022 04:32:53 +0000 (UTC) X-FDA: 79372358226.26.582F925 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf31.hostedemail.com (Postfix) with ESMTP id D83E520003 for ; Tue, 19 Apr 2022 04:32:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650342772; x=1681878772; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=K6//9ytp+ShNHarzEHcRH8Qe2JZRTBRZP4+agh9KNdc=; b=AS7lmPRV+1JOE6BipPuSfM+j9sJvtkWmLqprMd5PaIIAgIGE/dwNArcC FFjA/YQYLbwOl7GshCHn6AS61sySmgLCgWjr8eoywUfr83n4UXo9MEAyS H/vcfc9aghkfQL8UwNe9p8xXw2dif6PnkkaTBwE0ulEl+BVsbexliFTkv TCcJjI2ZaRiAlZjNmJpiP/XZZd6iWKEUnjYw5RmTaC3zasVO2zPvM+HTe i49mR8vud345BtTGmkVToSO04NSDyk2v9rRsCtzhLFWyma9nWsdO7cISG NCjN1vnaPDCd9dVrhcUUgO0CY9eEtxWzcF0aY8JCKVDJJNvyUQIaFIvYq w==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="262532110" X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="262532110" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 21:32:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="665771677" Received: from xpf.sh.intel.com ([10.239.182.112]) by orsmga004.jf.intel.com with ESMTP; 18 Apr 2022 21:32:45 -0700 Date: Tue, 19 Apr 2022 12:31:28 +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> <50067c2d-5563-7d8c-f992-5fef787d4d38@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50067c2d-5563-7d8c-f992-5fef787d4d38@intel.com> Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AS7lmPRV; spf=none (imf31.hostedemail.com: domain of pengfei.xu@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=pengfei.xu@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Stat-Signature: qgwzj3ofub576coqdkqhadcqebqhp8os X-Rspamd-Queue-Id: D83E520003 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650342771-47089 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022-04-18 at 09:04:33 -0700, Reinette Chatre wrote: > Hi Pengfei, > > On 4/16/2022 12:52 AM, Pengfei Xu wrote: > > 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 > > I encountered this also and that is why this patch contains the "Note to > maintainers" above. It is not clear to me whether you considered the note > since your response does not acknowledge it. > Sorry, I just made a suggestion to fix this problem mentioned by the script. I didn't notice and reply for the note. > > ... > > +#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 > > More information available in > https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs > but from what I understand it does not apply to this macro. Even so, I do > not know what checkpatch.pl uses to determine that this is a "Macro with > complex values". > Checked checkpatch.pl and it seems to suggest using ({ }) for any asm macro definition. > > > > 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 > > " > > Sure, I can do so. > I just made a suggestion to fix the problem reported by the checkpatch.pl. But I didn't think deeply enough before: I'm not sure is there any real improvment or help after the fix. Thanks! --Pengfei > Reinette