From patchwork Mon Nov 27 10:38:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 119668 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp56187qgn; Mon, 27 Nov 2017 02:39:11 -0800 (PST) X-Google-Smtp-Source: AGs4zMalhZPNKq+K5eU3H0qMfOdJ/xgK82FLa2cqTJ3px5L5RayfOg4Hh1bfyaU7RztZS0Rv/YS2 X-Received: by 10.84.128.229 with SMTP id a92mr22806877pla.108.1511779151620; Mon, 27 Nov 2017 02:39:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511779151; cv=none; d=google.com; s=arc-20160816; b=iYEyArjPewnaxa8F2E+rb1krrv9U7lAB01Hv0KIA0PpAFibOofwVGq551c0i7r3B8Y HAGxWnQxCKfd63zJYeobkrhFrMN1VMeiVWoyFALhg3J5y1PTDebbJA+msmVKk0E4H7O/ yMZd4Pg+MGzvAd8UBvizhUnJ/v3dymAE6nBP7Jpy2LQdDVRAwhEJKMHH8evzx3SOqnou EhHJITt5vt86wCk8jzfok9B+bI2oIYXUtXjB3cU/+FSnaalyO+yqdBbf+Ogg1IOk8ghl ciqa0o4DDvSp/TDl2tQkFHt4l0NNvpuSyZcQ+5/byCdhm7hm8a3tnKZJRWQFEYLZm9dt 5UiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=feyRSg8P5UI0n2FolzvWjI0ZCln3scQIbAG2XzUuj3c=; b=EU3qCiM6QC1RdJnXghkwl+BWP3P0sW7R+CPh+ECyIIhw4D0ZqJ83T0fyke21rTcegf 3GQFgmNH8ZNgdQ+jxTa/MYc9z16W7OVuAz2L2ZQyfWofcxsffc7JfmJr6SK0aXEPAIzH PQ4oFINSh9jFYKvAG2mueL9PP/eGxh9S4ht/iQP0M3U7mz5rePr1oZwv5ht1DOxaN2k6 wVQHcJ+msYXXpXyI6xWCwvOoa5rYnY8aP7UQji64tsBUCXeEZD1/nFqui4vm0duvTr8l JBa5E+ctUJx9dHtJg+fTujqJ+EixK5BkS+DWdsyzEkc5D2uN4HyHLCEYn+t+QaMe7fDh G42g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 y192si22458009pgd.109.2017.11.27.02.39.11; Mon, 27 Nov 2017 02:39:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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 linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953AbdK0KjK (ORCPT + 28 others); Mon, 27 Nov 2017 05:39:10 -0500 Received: from foss.arm.com ([217.140.101.70]:35774 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751935AbdK0Kig (ORCPT ); Mon, 27 Nov 2017 05:38:36 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B98021596; Mon, 27 Nov 2017 02:38:35 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 404823F246; Mon, 27 Nov 2017 02:38:34 -0800 (PST) From: Mark Rutland To: linux-kernel@vger.kernel.org, mingo@redhat.com Cc: acme@redhat.com, apw@canonical.com, joe@perches.com, mark.rutland@arm.com, paulmck@linux.vnet.ibm.com, peterz@infradead.org Subject: [PATCH 2/4] tools: include: remove ACCESS_ONCE() Date: Mon, 27 Nov 2017 10:38:22 +0000 Message-Id: <20171127103824.36526-3-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20171127103824.36526-1-mark.rutland@arm.com> References: <20171127103824.36526-1-mark.rutland@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There are no longer any usersapce uses of ACCESS_ONCE(), so we can remove the definition from our userspace , which is only used by tools in the kernel directory (i.e. it isn't a uapi header). This patch removes the ACCESS_ONCE() definition, and updates comments which referred to it. At the same time, some inconsistent and redundant whitespace is removed from comments. Signed-off-by: Mark Rutland Cc: Arnaldo Carvalho de Melo Cc: Ingo Molnar Cc: Joe Perches Cc: Paul E. McKenney Cc: Peter Zijlstra --- tools/include/linux/compiler.h | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) -- 2.11.0 diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h index 07fd03c74a77..04e32f965ad7 100644 --- a/tools/include/linux/compiler.h +++ b/tools/include/linux/compiler.h @@ -84,8 +84,6 @@ #define uninitialized_var(x) x = *(&(x)) -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) - #include /* @@ -135,20 +133,19 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s /* * Prevent the compiler from merging or refetching reads or writes. The * compiler is also forbidden from reordering successive instances of - * READ_ONCE, WRITE_ONCE and ACCESS_ONCE (see below), but only when the - * compiler is aware of some particular ordering. One way to make the - * compiler aware of ordering is to put the two invocations of READ_ONCE, - * WRITE_ONCE or ACCESS_ONCE() in different C statements. + * READ_ONCE and WRITE_ONCE, but only when the compiler is aware of some + * particular ordering. One way to make the compiler aware of ordering is to + * put the two invocations of READ_ONCE or WRITE_ONCE in different C + * statements. * - * In contrast to ACCESS_ONCE these two macros will also work on aggregate - * data types like structs or unions. If the size of the accessed data - * type exceeds the word size of the machine (e.g., 32 bits or 64 bits) - * READ_ONCE() and WRITE_ONCE() will fall back to memcpy and print a - * compile-time warning. + * These two macros will also work on aggregate data types like structs or + * unions. If the size of the accessed data type exceeds the word size of + * the machine (e.g., 32 bits or 64 bits) READ_ONCE() and WRITE_ONCE() will + * fall back to memcpy and print a compile-time warning. * * Their two major use cases are: (1) Mediating communication between * process-level code and irq/NMI handlers, all running on the same CPU, - * and (2) Ensuring that the compiler does not fold, spindle, or otherwise + * and (2) Ensuring that the compiler does not fold, spindle, or otherwise * mutilate accesses that either do not require ordering or that interact * with an explicit memory barrier or atomic instruction that provides the * required ordering.