Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp3191640rdb; Tue, 26 Dec 2023 21:48:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IGUNODqiv3moIWtESeUedWU+k05Q+TJDEBcPcbWql+116v5InOI7sY86/3PcotwtH2lGep0 X-Received: by 2002:adf:f2c7:0:b0:336:6db8:a00c with SMTP id d7-20020adff2c7000000b003366db8a00cmr4339689wrp.26.1703656080168; Tue, 26 Dec 2023 21:48:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703656080; cv=none; d=google.com; s=arc-20160816; b=tZm6KLafpKAD8MM0iGfyKezAf8z/mMTyIuGE0guaLSaa3rYk9yC9Q1uKdYkp3OZHib yUDv2hd2vxPaqkI0bbVZtz00DIj5v9oeTYLtwAmbG3XlUjw3oUxULjFAjAP1LpoPzmdV st3RYOk+FDi4KYs475V9mJV+KZWcpYesrz5iAbnyEKIw68N8JGdScBnX5XSgxggO+/9x HuwQusX8YIUN1QSR6Ei9NxpogiAOl3uyeJPOHlamX6mJAckQUvz+Kh1GM0P4inmZCPHj wqxu2ZKf/Oziw9mdGKXAMC83I6qRLDfEU8izEMWK3jHzB5/c35JOXFk1iUX9k/W9lPkz QQqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=M/tk9ttyfsUURXyZNR062KAb1XrqDcnbLBZBPOcTBgM=; fh=SZfMy6739bGcIsSH72WZaxtxzgQIkZnwUdUQFAnlIyY=; b=iv8wzWJTfqFN6ibz434uC9y9ZGZ8ICeFCJWQA+XxZw6Xh6E/C0GKnv3uO/Gb+/0Vvp ZUKOWMuyoTNFMz+0Z7eYy8m+zyPp5r3f8R5vD13IrBfRABhXROe8iZaJGuCAxGmbrj3U UZHryuD+S0T3wVOcPMu8YXUtlgaGKhfgC0HyLdO6K/Qtomy1cLhnd8TZdR4AiqqpLLO0 brUbXoeLZgBTHxXfOP1k0/20Jy98g2swDiKtHAWLXGUII2iAje1m4IW65L/NSjKYeceN gMO2/EnuqkSQu16kqiTlbIftVKKYA52RTwimASdROyKMaqfQlouzJnfu7JU5LC04Ox+q zudA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PDSHgRlG; spf=pass (google.com: domain of linux-kernel+bounces-11835-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11835-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id dk22-20020a0564021d9600b0055538bf9c57si777117edb.228.2023.12.26.21.48.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Dec 2023 21:48:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-11835-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PDSHgRlG; spf=pass (google.com: domain of linux-kernel+bounces-11835-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11835-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DFA711F21899 for ; Wed, 27 Dec 2023 05:47:59 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5435C523E; Wed, 27 Dec 2023 05:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PDSHgRlG" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7016B4403; Wed, 27 Dec 2023 05:47:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 780BDC433C8; Wed, 27 Dec 2023 05:47:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703656067; bh=HmpjSaYrmUUsg9E2xroGEt/cOrPn7cVKnOx0gLYZpSU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PDSHgRlGhvQ5EJ8TvsFa7lgIbVlMlVn/INxni06BVCcRvBbJFZAfQPP8DxLOVU2Iw z2JGKDdYtQc8hSk/Pn7Ma9bjubSXUwevcK7sfUg5GwTZTUkWPXDor9U2lrh9zx+JHv 6rK1B6rnhYaGbA/uGGeRT919GevcHwCLPVHPgbodua7V4foksZxwGYYCo7Tg5FeO0i ZqRya950f4RXRb/oPepio2Fke8tsGjPk/9GFGl74aecqz81Y9w10PEeSx4RaxP3MbM jWZG4N2AiDvkvC/J7eBkyiNAUjgZr0vu/Vo954DLFeEpcwHNx25tMt1bc4jpMiGpdG Lig9eDHfbZohw== Date: Wed, 27 Dec 2023 11:17:34 +0530 From: Manivannan Sadhasivam To: Andrew Halaney Cc: Andy Gross , Bjorn Andersson , Konrad Dybcio , Manivannan Sadhasivam , "James E.J. Bottomley" , "Martin K. Petersen" , Yaniv Gardi , Dov Levenglick , Hannes Reinecke , Subhash Jadavani , Gilad Broner , Venkat Gopalakrishnan , Janek Kotas , Alim Akhtar , Avri Altman , Bart Van Assche , Anjana Hari , Dolev Raviv , Can Guo , Will Deacon , linux-arm-msm@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC v2 03/11] scsi: ufs: qcom: Perform read back after writing testbus config Message-ID: <20231227054734.GA2814@thinkpad> References: <20231221-ufs-reset-ensure-effect-before-delay-v2-0-75af2a9bae51@redhat.com> <20231221-ufs-reset-ensure-effect-before-delay-v2-3-75af2a9bae51@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231221-ufs-reset-ensure-effect-before-delay-v2-3-75af2a9bae51@redhat.com> On Thu, Dec 21, 2023 at 12:25:20PM -0600, Andrew Halaney wrote: > Currently, the testbus configuration is written and completed with an > mb(). > > mb() ensure that the write completes, but completion doesn't mean > that it isn't stored in a buffer somewhere. The recommendation for > ensuring this bit has taken effect on the device is to perform a read > back to force it to make it all the way to the device. This is > documented in device-io.rst and a talk by Will Deacon on this can > be seen over here: > > https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 > > Let's do that to ensure the bit hits the device. Because the mb()'s > purpose wasn't to add extra ordering (on top of the ordering guaranteed > by writel()/readl()), it can safely be removed. > > Fixes: 9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers") > Signed-off-by: Andrew Halaney > --- > drivers/ufs/host/ufs-qcom.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c > index 4c15c8a1d058..6df2ab3b6f23 100644 > --- a/drivers/ufs/host/ufs-qcom.c > +++ b/drivers/ufs/host/ufs-qcom.c > @@ -1332,6 +1332,9 @@ static void ufs_qcom_enable_test_bus(struct ufs_qcom_host *host) > ufshcd_rmwl(host->hba, UFS_REG_TEST_BUS_EN, > UFS_REG_TEST_BUS_EN, REG_UFS_CFG1); > ufshcd_rmwl(host->hba, TEST_BUS_EN, TEST_BUS_EN, REG_UFS_CFG1); > + > + /* dummy read to ensure this has been enabled prior to returning */ > + ufshcd_readl(host->hba, REG_UFS_CFG1); In this case, I do not see the necessity to do a read back itself since there is no delay afterwards nor any dependent operation in an altogether different domain. So removing the mb() should be sufficient. - Mani > } > > static void ufs_qcom_get_default_testbus_cfg(struct ufs_qcom_host *host) > @@ -1429,11 +1432,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host) > (u32)host->testbus.select_minor << offset, > reg); > ufs_qcom_enable_test_bus(host); > - /* > - * Make sure the test bus configuration is > - * committed before returning. > - */ > - mb(); > > return 0; > } > > -- > 2.43.0 > -- மணிவண்ணன் சதாசிவம்