Received: by 10.213.65.68 with SMTP id h4csp510306imn; Tue, 20 Mar 2018 08:31:59 -0700 (PDT) X-Google-Smtp-Source: AG47ELthv7Oh7v7CyIdkMsI6UBPT59MrApRflaRZL8DPRbHkmZudtFiWymX3XaiwKGW9IX2XjdXJ X-Received: by 10.167.129.195 with SMTP id c3mr14046572pfn.14.1521559919592; Tue, 20 Mar 2018 08:31:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521559919; cv=none; d=google.com; s=arc-20160816; b=Ak7XFKLDSP88D0W5WVbNf6UCWiDitBY/jh3VRW17nwitbPvLPdixx81aFwdjrkvWKn x79VCk1UCUaxhtPUF+yP13loMRwXcJxwrTTviEBG4tYjPNXwZonvH5OBdVws8XNBvk2j cuTqj8oeuPZhw6z2SNlQ8miT/asboY+QyNde5f0VEt6294KiGEQdLEEcpQ24yejj2/0W UsyW0kmNL2OhLzNGPyUeDL67RuLQDBujYKww6PDrd/yT4xspW/Cp0R7FlrI1uhRioqn/ W6ki4YRicyxvSfcds+KHajmLaHfop4X3VmuYMFDdIW/cGWKFlEBVLWM2YljJwGN6zljS Claw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=egclBpJv85zggcuKy3MU1j6AO6/4fILUsUjDS5ElGkk=; b=Usxt+O25i2PIMBd0K/p6we8xXde3uVavvQ2OQWQBXKIsV0xjsOh3MlRG0AWLgSeyvB 0OjFTMWv2Ry4NOBzgOz0YdlEJVIDUhnI8jq8nYXBY6iYSo7iR4fUkdGbq9bmJyktYTN4 QigrrpVW5RnSsK709QzioR6YWYVA3mLJkDXy/eMCedXJIe3BfmeZ6Ww1BDMk2a4hG8vp cux1Es7/92wcEO4Z8PjzavzvrC2OfqvzNDaM4Q01r1fL1owcM5o+W1L0wzuQgtEje/OR lxDJNIxF1wF8STp/50Rq7mwEsfD7k3JhhCxULOEWYHvuzgegS8mcPNEZZz1YEIq/NCIO lvgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=DaZp0xfp; dkim=pass header.i=@codeaurora.org header.s=default header.b=gLaV6V2l; 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 e2si1296225pgs.556.2018.03.20.08.31.45; Tue, 20 Mar 2018 08:31:59 -0700 (PDT) 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; dkim=pass header.i=@codeaurora.org header.s=default header.b=DaZp0xfp; dkim=pass header.i=@codeaurora.org header.s=default header.b=gLaV6V2l; 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 S1751661AbeCTPao (ORCPT + 99 others); Tue, 20 Mar 2018 11:30:44 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54258 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751597AbeCTPai (ORCPT ); Tue, 20 Mar 2018 11:30:38 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 7988660C66; Tue, 20 Mar 2018 15:30:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521559837; bh=d/tp/MJofX/qVjSDTr3XCJrCtYiJf1keksr99vZH1VE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DaZp0xfpbwrGWSVRDo2ObwgwR/mVRjtA1nXWd1EqMAQcONyTZsJiQfjk1YM8GdBt6 5t2gjVCCv7cSexOtIj7DYx3eugI3H93klsTVYQgeHNyv/17RnZVEo9yEQR7KFLxQHy IfzIGRznptygDAJH9PimvlWbTGJKRq/ePYyNlM7Y= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.177.68.48] (pat_11.qualcomm.com [192.35.156.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 96807602FC; Tue, 20 Mar 2018 15:30:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521559836; bh=d/tp/MJofX/qVjSDTr3XCJrCtYiJf1keksr99vZH1VE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gLaV6V2lbunr39eGNZW23gZWcR7NsYuhUbK2RBTDDw8kmovjOGPS96Dq/v4LxfzDp DFV1CKfTyq3kLxTztpd1gJESuIPQlrd5GaOQVMoMoJZdTAYLlU4QVpSkISFPLtgPFq pHuC3L2v3m05EbXUR2cAT2lT0iDBIyOiPP2tqaNw= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 96807602FC 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 v4 1/6] RDMA/bnxt_re: Eliminate duplicate barriers on weakly-ordered archs To: Jason Gunthorpe Cc: linux-rdma@vger.kernel.org, timur@codeaurora.org, sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Selvin Xavier , Devesh Sharma , Somnath Kotur , Sriharsha Basavapatna , Doug Ledford , linux-kernel@vger.kernel.org References: <1521514068-8856-1-git-send-email-okaya@codeaurora.org> <1521514068-8856-2-git-send-email-okaya@codeaurora.org> <20180320144801.GE19744@ziepe.ca> <20180320152043.GK19744@ziepe.ca> From: Sinan Kaya Message-ID: Date: Tue, 20 Mar 2018 10:30:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180320152043.GK19744@ziepe.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/20/2018 10:20 AM, Jason Gunthorpe wrote: > On Tue, Mar 20, 2018 at 10:00:49AM -0500, Sinan Kaya wrote: >> On 3/20/2018 9:48 AM, Jason Gunthorpe wrote: >>> On Mon, Mar 19, 2018 at 10:47:43PM -0400, Sinan Kaya wrote: >>>> Code includes wmb() followed by writel(). writel() already has a barrier on >>>> some architectures like arm64. >>>> >>>> This ends up CPU observing two barriers back to back before executing the >>>> register write. >>>> >>>> Since code already has an explicit barrier call, changing writel() to >>>> writel_relaxed(). >>>> >>>> Signed-off-by: Sinan Kaya >>>> drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 8 ++++---- >>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c >>>> index 8329ec6..4a6b981 100644 >>>> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c >>>> @@ -181,10 +181,10 @@ static int __send_message(struct bnxt_qplib_rcfw *rcfw, struct cmdq_base *req, >>>> >>>> /* ring CMDQ DB */ >>>> wmb(); >>>> - writel(cmdq_prod, rcfw->cmdq_bar_reg_iomem + >>>> - rcfw->cmdq_bar_reg_prod_off); >>>> - writel(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + >>>> - rcfw->cmdq_bar_reg_trig_off); >>>> + writel_relaxed(cmdq_prod, rcfw->cmdq_bar_reg_iomem + >>>> + rcfw->cmdq_bar_reg_prod_off); >>>> + writel_relaxed(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + >>>> + rcfw->cmdq_bar_reg_trig_off); >>> >>> Woah, this may not be safe.. >>> >>> The definition of writel_relaxed() is that it is fully unordered, so >>> the above two writes may change order now. Broadcom guys would have to >>> ack if that it is OK or not for their hardware. >>> >>> In general this is not an OK approach for a mechanical >>> conversion.. Only the first writel can be convereted. >>> >>> You need to check all your patches to make sure there are no >>> subsequent writel's in the places touched. >> >> I paid special attention to this one and went to check the barriers >> document. According to the document, writes (whether it is relaxed or not) >> are always observed by the HW inorder with respect to each other. > > Oh interesting, that document got revised to make writel_relaxed less > relaxed a few years ago, didn't know that. Thanks. > > However, this is still not OK, the full code is: > > /* ring CMDQ DB */ > wmb(); > writel(cmdq_prod, rcfw->cmdq_bar_reg_iomem + > rcfw->cmdq_bar_reg_prod_off); > writel(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + > rcfw->cmdq_bar_reg_trig_off); > done: > spin_unlock_irqrestore(&cmdq->lock, flags); > > > And the definition of _relaxed allows the writes to order outside the > spinlock region, which is very likely to be wrong in this driver. > > I'm not sure adding a mmiowb() just to use a writel_relaxed is any > sort of win though? I'd prefer this. mmiowb() on ARM64 is empty. mmiowb() guarantees that code also works for PPC too. I'll switch to this instead so it works for everybody. > > Jason > -- 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.