Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp3198499rdb; Tue, 26 Dec 2023 22:11:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IGVVRZ9LINF1A+hw+SwAyw/kJwsr3Fb7aOViZCJAMq+Jvj3CLy9tbTJTIPZr3EnfvMyoB7/ X-Received: by 2002:a05:620a:382:b0:77e:fba4:3a2d with SMTP id q2-20020a05620a038200b0077efba43a2dmr9505997qkm.131.1703657478852; Tue, 26 Dec 2023 22:11:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703657478; cv=none; d=google.com; s=arc-20160816; b=MWV0oRp05uyxY2ZwOioasMtKkVtSmLaQ9bbOSURS5M79Z1mvjvQMoHWfwkkOOSAumN vOiEH04uKc/h08XgVroX/+15w6WTKTW4NCvX57gcQbtWhvxNJ4A+UvIIYX12kbb4NTN1 S8D7V+VRa4qRgp5WP56xp4+8x/oBDsBJM+6vROcgJo1P3FFhaO28amgSBmvj2ZRPiLqp i3Dz+fjzRYKhinGk58ByL0IkoAyNu9Pz38lX1l498WNB04nlDaapway/1uvvfwoHe/eu g1cvhZUvMHlhKyu9yhl7LyLA7YoVtTHBuSWtvekQlRSLvqxhLC7WYaFsFyyka86v9A6+ vzpQ== 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=B4U4uljd7qrSRnwTw7/5S3Qp/hZHc0A/Uf9ZVNlT70s=; fh=UMGRLhNHoojhisMeDDlVUXY29HzeMT96/NrbQoq/sWI=; b=cjfZNVc/03J9nplo4y/5W16utUgqqBYT/8/JNgwAU85+EVTrZm7Rd+gsI/JTNOrdR7 1eJfw6D2B1N+XA3ruDkJZNGNl/ZdLnYRZWHWp28SoPwX/ybxiyHTW58rMFSLn2WKkonY 51HX3Hh0xmOa13wKMEOxjmHO2u3cwBRwiOCsa6pdfUeDegtstobW1pvZTdSH2tjq6adm 54ldRZ0IVfJ4Zwns/sG3ztnrsPSQq6lD0dGCFoFt1uxp4Qd4wuLJskMga/efVDpdWb6z 8UJhGq858mGi7PjDYNUwmcl+zTxNdzqwnn4BRt1azGUHkWsVchdA1SuPDa9S8kQ/yosS OPUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=b6PJY+kT; spf=pass (google.com: domain of linux-kernel+bounces-11847-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11847-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id az6-20020a05620a170600b007815c45ec38si1543100qkb.517.2023.12.26.22.11.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Dec 2023 22:11:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-11847-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=b6PJY+kT; spf=pass (google.com: domain of linux-kernel+bounces-11847-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11847-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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 8A3951C22286 for ; Wed, 27 Dec 2023 06:11:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 77FDF5398; Wed, 27 Dec 2023 06:11:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b6PJY+kT" 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 A2E0C5228; Wed, 27 Dec 2023 06:11:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4B17C433C8; Wed, 27 Dec 2023 06:10:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703657465; bh=EbTles2opVDGaZKfZKJxC69A0Tm4AO/LxxDWp87Mq48=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=b6PJY+kT9ne/f1z8+DNBLcNGWxhJKg+EEixZFdmLotdeQ/w5GPlD42S+G09b6ARjG hNcSTY5gUBMG2fF7Pofl4Q2nnKd2FkB/8gES0e8HuFefxgv++jO+uyH83uQ6IXSeoY 3jIi1QLmvDAA+9a63SecS7XrRWNezIU3LV9wLZCOVLEVek11NVb0PhNYbltc9dK9Za 3Q+3Rr9sN+P2iRKpcJEqlmdZ1z3i5zwd5c+luawc/Jv7XERftd0lKmHoejlwyBKrHC +g2hZ4hwHb5xVCSt5Intd6/2NR7tU9m2saczP4qmoVZNXnpZD3K3/RbzyKfe3knhC/ Jjx9kMpevf/8w== Date: Wed, 27 Dec 2023 11:40:53 +0530 From: Manivannan Sadhasivam To: Andrew Halaney Cc: Andy Gross , Bjorn Andersson , Konrad Dybcio , "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 07/11] scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H Message-ID: <20231227061053.GE2814@thinkpad> References: <20231221-ufs-reset-ensure-effect-before-delay-v2-0-75af2a9bae51@redhat.com> <20231221-ufs-reset-ensure-effect-before-delay-v2-7-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-7-75af2a9bae51@redhat.com> On Thu, Dec 21, 2023 at 12:25:24PM -0600, Andrew Halaney wrote: > Currently, the UTP_TASK_REQ_LIST_BASE_L/UTP_TASK_REQ_LIST_BASE_H regs > are written to and then 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 these bits have 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 bits hit 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: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks") > Signed-off-by: Andrew Halaney This also I'm not sure whether we can safely remove readback. So, Reviewed-by: Manivannan Sadhasivam - Mani > --- > drivers/ufs/core/ufshcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c > index d1e33328ff3f..7bfb556e5b8e 100644 > --- a/drivers/ufs/core/ufshcd.c > +++ b/drivers/ufs/core/ufshcd.c > @@ -10351,7 +10351,7 @@ int ufshcd_system_restore(struct device *dev) > * are updated with the latest queue addresses. Only after > * updating these addresses, we can queue the new commands. > */ > - mb(); > + ufshcd_readl(hba, REG_UTP_TASK_REQ_LIST_BASE_H); > > /* Resuming from hibernate, assume that link was OFF */ > ufshcd_set_link_off(hba); > > -- > 2.43.0 > -- மணிவண்ணன் சதாசிவம்