Received: by 10.223.185.111 with SMTP id b44csp427428wrg; Fri, 9 Mar 2018 07:18:12 -0800 (PST) X-Google-Smtp-Source: AG47ELvckbkajRxe3NDfpev+aA89XiwAZ2tIKvCpwi8/DiWVFXMo4EwQJdwXp622PpVUa4RX/DRq X-Received: by 2002:a17:902:5482:: with SMTP id e2-v6mr27913844pli.65.1520608692488; Fri, 09 Mar 2018 07:18:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520608692; cv=none; d=google.com; s=arc-20160816; b=QG8q2jCSrzLYJWfYVHJtEWaNWcfORd+X2B+un+aokH+fS62MtGJJzwBishYucdHA0W r2tkgCWGB7SShDW5hQ9hKIbFKrWDYmI4HlOoRz3iCQxgLv83JFvUybLLFxvGZGOGH3K4 bfYf26C0ib+Q+608lXkvboOIQzrFdfHnQcA8wk+iX/dAfU3hZ33aihjgJAGocKbMXkyT phnV+XHqsL0KoKfMDibtEgh8oveQbRH7j0MFnMv+Fbnn1jrpWEToPYYRebR+tyNL+EZe Ys0yl21XS8ohdbyJQB0wkQpIiuhpy5aZiIfSxY9TBEELd1cqqOVPdyVPpRN8Z+L6uOaX Duzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=aFb4Tg8eJqShIBVof3P1nQsrfvQCWJzhsntE6vEzGkM=; b=HhMt8Sez+hs4CfzGVKGvJ+h8tSmAtlne/L1ViNDX0NdCdNFhYaFCMz+pM/dltZvxvH aD4RN1WPQ3PCkcXvbBpeLHDnUeaYYOtunptfXVAtOJz6g6Rw6mpP/z5Hf5S/SDUn5Fl0 zg8qCIbxiNZ+9zk/TIAtTI7hh1SGLtfbxXRAwRwNUnc71mnnSxXuyZCtaUlMMwVrbrnJ F2LPCBczxgpBFflJZYojeEXItBvIGqf/Y1a3xqOjwaYTBzI0lfrgWfHM7FtTO7L2+FWp N1nnSQjn+5orDeRbXvvBZxSnLoHkuZL7qftN7Pisquj3tAoOsxlW1oqRPYBOEavXGK55 enWA== 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 f11si827185pgv.534.2018.03.09.07.17.57; Fri, 09 Mar 2018 07:18:12 -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 S932168AbeCIPPZ (ORCPT + 99 others); Fri, 9 Mar 2018 10:15:25 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:52428 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbeCIPPY (ORCPT ); Fri, 9 Mar 2018 10:15:24 -0500 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id F318A103C1CCF; Fri, 9 Mar 2018 07:15:22 -0800 (PST) Date: Fri, 09 Mar 2018 10:15:20 -0500 (EST) Message-Id: <20180309.101520.1551234308448290917.davem@davemloft.net> To: Jose.Abreu@synopsys.com Cc: niklas.cassel@axis.com, peppe.cavallaro@st.com, alexandre.torgue@st.com, pavel@ucw.cz, niklass@axis.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] net: stmmac: remove superfluous wmb() memory barriers From: David Miller In-Reply-To: References: <20180308103006.1197-1-niklas.cassel@axis.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 09 Mar 2018 07:15:23 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jose Abreu Date: Fri, 9 Mar 2018 10:26:11 +0000 > Sorry but I know at least two architectures which don't do a > wmb() upon an writel [1] [2]. This can be critical if if we are > accessing the device through some slow or filled bus which will > delay accesses to the device IO. Notice that writel and then > readl to the same address will force CPU to wait for writel > completion before readl, but in this case we are using DMA and > then writel so I think a wmb() before the writel is a safe measure. Wait a second. This is not about whether there is an explicit memory barrier instruction placed in the writel() implementation. Are you saying that the cpu(s) in question will reorder stores in their store buffers, even if they are to real memory vs. IOMEM? That's really dangerous.