From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1040147AbdDUNr5 (ORCPT ); Fri, 21 Apr 2017 09:47:57 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:34986 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1040129AbdDUNry (ORCPT ); Fri, 21 Apr 2017 09:47:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7C9FA6075A Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH V2] scsi: mpt3sas: remove redundant wmb To: Sreekanth Reddy , "Martin K. Petersen" References: <1491591978-17880-1-git-send-email-okaya@codeaurora.org> Cc: "linux-scsi@vger.kernel.org" , timur@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sathya Prakash , Chaitra P B , Suganath Prabu Subramani , "James E.J. Bottomley" , "open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)" , open list From: Sinan Kaya Message-ID: <63726ec2-56dc-4fe2-f7ea-e177832d6114@codeaurora.org> Date: Fri, 21 Apr 2017 09:47:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/21/2017 3:56 AM, Sreekanth Reddy wrote: > [Sreekanth] Whether same thing applicable for SPARC & POWER > architectures. If yes then we are fine with this patch changes. This behavior is common for all architectures according to this document. Who would be the best person to comment on SPARC and POWER architectures in specific? James and I exchanged some comments on the first version. James? can you comment on POWER behavior. https://www.kernel.org/doc/Documentation/memory-barriers.txt Inside of the Linux kernel, I/O should be done through the appropriate accessor routines - such as inb() or writel() - which know how to make such accesses appropriately sequential. "Whilst this, for the most part, renders the explicit use of memory barriers unnecessary", there are a couple of situations where they might be needed: (1) On some systems, I/O stores are not strongly ordered across all CPUs, and so for _all_ general drivers locks should be used and mmiowb() must be issued prior to unlocking the critical section. (2) If the accessor functions are used to refer to an I/O memory window with relaxed memory access properties, then _mandatory_ memory barriers are required to enforce ordering. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.