Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2255441pxb; Sun, 17 Oct 2021 09:46:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlmEcFhB+NU9rNRxsWRoBIvXWhduDzpyq/ZODw8+DTKoFaIgHceFivjy7Vrn1miBY36BAi X-Received: by 2002:a17:90a:6782:: with SMTP id o2mr42167847pjj.165.1634489196721; Sun, 17 Oct 2021 09:46:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634489196; cv=none; d=google.com; s=arc-20160816; b=NyRtbaLbcrGZYCexlaJGXNKGLNajIFAcf3qZLLaDBcDiozLWz6USp4g5h7KEUNmkot KyCNqXHlzBuaYJFW9VLZJ7NJwrVUJtF9d62SsEtLyxGVSVok0TXTR3jPDovKWFkN4dbV n9ZhQPgagPY5EEQIXwXUU6yeofy2KE4CkHPUwd3wuoykILFVmPUWyKMYmh95NNVtYYQW rZRPb98+xT8wB+nwUwmp7V0Vw8iH3z+bjMkey0H8E6I9qqOf/BqLbL8iPWjsS5UvdCOf xkD0sxcZehzlfiJOFw43Bf9mH916maSO9NBJJzpZWHfl6VUgvXwGxMfQ935AuJBzfFyX FqnA== 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; bh=E0ChmABhqWldyiSbn0d0glI2ha/n/HNWvqFbYtgja+I=; b=kFBmUy5yoaR8cgmkH3sndcrQ8W59KgMO0/VXBO+o0WPDW/y+1DfN+AEDVrO22AT0Im HcmtJ4Ek9/i+fMxnanVoy0cPbt31RYKBcOzs46Dt9rSFe6iI53DXYgjqyERjkN3UeisN 9NXe98OHri4aju4qSBxqouWfFcaZ1Ay+HpnC67c782qHCkwGcAtIkz9iCRxq6pnOSX+M VTagb+/JLkSU1EVznSiKyDXla+L+UxC3vQGOaW0FfUMxMD5qfCL1KmX7RXMkjX3zXdn3 XLX4ZOa7vnA2jqDXiRR7V9Q5/nC9LoiOKM9nz6EtwRuydNhHF+tBOtGmjQovdkpQl46z joeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g35si17184156pgl.237.2021.10.17.09.46.22; Sun, 17 Oct 2021 09:46:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242332AbhJOSCK (ORCPT + 99 others); Fri, 15 Oct 2021 14:02:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:60294 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237569AbhJOSCJ (ORCPT ); Fri, 15 Oct 2021 14:02:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2116361212; Fri, 15 Oct 2021 18:00:01 +0000 (UTC) Date: Fri, 15 Oct 2021 18:59:58 +0100 From: Catalin Marinas To: Xiongfeng Wang Cc: mark.rutland@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, moyufeng@huawei.com Subject: Re: [RFC PATCH v2] arm64: barrier: add macro dgh() to control memory accesses merging Message-ID: References: <20211015090511.92421-1-wangxiongfeng2@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211015090511.92421-1-wangxiongfeng2@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 15, 2021 at 05:05:11PM +0800, Xiongfeng Wang wrote: > diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h > index 451e11e5fd23..d71a7457d619 100644 > --- a/arch/arm64/include/asm/barrier.h > +++ b/arch/arm64/include/asm/barrier.h > @@ -18,6 +18,14 @@ > #define wfe() asm volatile("wfe" : : : "memory") > #define wfi() asm volatile("wfi" : : : "memory") > > +/* > + * Data Gathering Hint: > + * This instruction prohibits merging memory accesses with Normal-NC or > + * Device-GRE attributes before the hint instruction with any memory accesses > + * appearing after the hint instruction. > + */ > +#define dgh() asm volatile("hint #6" : : : "memory") On its own, this patch doesn't do anything. It's more interesting to see how it will be used and maybe come up with a common name that other architectures would share (or just implement as no-opp). I'm not sure there was any conclusion last time we discussed this. -- Catalin