Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2569397ybc; Wed, 13 Nov 2019 17:05:37 -0800 (PST) X-Google-Smtp-Source: APXvYqygUXAy84R01K7pNZshoQjqd54chdgFqhEmo11j5G2BRklKuHwYpM8EqOFvIDpQ9nXW2o/c X-Received: by 2002:a50:f30c:: with SMTP id p12mr6948108edm.208.1573693537153; Wed, 13 Nov 2019 17:05:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573693537; cv=none; d=google.com; s=arc-20160816; b=GNvCt+rcL7+eMMSa9emTaAgjOqV2ODxz3DiA6gzgvaLZhZJ1qw5A8X/MmNsbiwMhsb 2ArestqMyFdF10y3+fiijUQe3MWr2apqfjMcsfnwYaRG8hHgZuu4K3ArxuTDKdcEq7P4 JiV4BUtaHo/0IeE4IQjBZVPjd8Iw74Pg2Y4s1P8zpujK7rYAPygY40tH6FgJINIK8iNk a6gYYg1THKqQXBNu3HS/IJrar2sPDVkmva2271i5KMBCorytZphZRMrWn2VvnfRY7Gjf 1oazUAp52h8srrRnY5f1JFsBjl60dXqfHWLdfxaBvlk6e8VDX3Nfpa00kf46V8byVzau ztSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature; bh=dxeHEicw5LCtZZElB2dpx8bMUCMzzm84+nT55ZwwDwo=; b=BvJ3xqWDx3EqlFa+r0JxGWTpy81oCNujGzpO9HmSwIzY+Fm4gAlyJrgjRJWPky7Xh6 7iWcFx1l9MV7+5GubggHQhBU1hLnCfqij1AVfpCxqlQYzKQLMwD4n+2QhONs6vkTcNQg 5IqjNL0gixMHIAGQ0+sbAtW3aZrcwOimwYRuh5rWV5gYWrLXumznD1DQbAJYfTg4lVom j3DKUBm0RXMobXfIQNHcmRh7aGqejk59UCW3Hty0REeeU9IzIUSZzLkabCFezgN/A0q8 O6ow/SOqUclcrC1Lr859kWVmKHU6NDbyAP68t7N0MW0aEw0ZAaM1riBMGW0tA4T+l7KF KZnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=UwZVJT0P; dkim=pass header.i=@codeaurora.org header.s=default header.b="AL/Phc4b"; 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 j23si2332253eja.393.2019.11.13.17.05.11; Wed, 13 Nov 2019 17:05:37 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=UwZVJT0P; dkim=pass header.i=@codeaurora.org header.s=default header.b="AL/Phc4b"; 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 S1727021AbfKNBDO (ORCPT + 99 others); Wed, 13 Nov 2019 20:03:14 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:59954 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726363AbfKNBDO (ORCPT ); Wed, 13 Nov 2019 20:03:14 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id A76FC60DAE; Thu, 14 Nov 2019 01:03:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1573693392; bh=mtDzRp609jVa8P6rGZmHkR8KyMo+8LG+VpVhw6EWN3c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UwZVJT0PbYWh5sPRHorsWeFIUEErNjMBLMQKMZTS1kcF9JP1t+qG65ByLDTyV4A/a C33jMTKXSVUViLFHQOsywMSG2WJUEOmQO/W1g9MhZV7zPggZtJdTOVWvE06xSZGPjM Q944WJzOaTU0rIxZqakPFoiaZWkbzbrfJa51uMgc= 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.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id C31856092C; Thu, 14 Nov 2019 01:03:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1573693390; bh=mtDzRp609jVa8P6rGZmHkR8KyMo+8LG+VpVhw6EWN3c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AL/Phc4bSaB4DjALScQ96lTPexLPY8Ovl2HcEXO6p+5X+w7pOLOBi2m048aFeZIGE OllJw4kGKpdnBTML0OoAlmi+SdNgyhnRQCFLr1WWJlyLxj37rwp5/DxqizB7SjaPTA 3vGrZktpBiTyRf03/4Vizc1eVh2K8cSY+AX2kb7w= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Nov 2019 09:03:10 +0800 From: cang@codeaurora.org To: "Bean Huo (beanhuo)" Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, rnayak@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, Alim Akhtar , Avri Altman , Pedro Sousa , "James E.J. Bottomley" , "Martin K. Petersen" , Stanley Chu , Subhash Jadavani , Tomas Winkler , open list , Can Guo Subject: Re: [EXT] [PATCH v1 5/5] scsi: ufs: Complete pending requests in host reset and restore path In-Reply-To: References: <1573200932-384-1-git-send-email-cang@codeaurora.org> <1573200932-384-6-git-send-email-cang@codeaurora.org> Message-ID: <0dc202a1decb6bbc103253b8c3c8c8ce@codeaurora.org> X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-11-14 06:04, Bean Huo (beanhuo) wrote: >> >> In UFS host reset and restore path, before probe, we stop and start >> the host >> controller once. After host controller is stopped, the pending >> requests, if any, >> are cleared from the doorbell, but no completion IRQ would be raised >> due to the >> hba is stopped. >> These pending requests shall be completed along with the first NOP_OUT >> command(as it is the first command which can raise a transfer >> completion >> IRQ) sent during probe. > > Hi, Can > I am not sure for this point, because there is HW/SW device reset > before or after host reset/restore. > Device HW/SW reset also will clear the pended tasks in device side. > That will be better. > I think Qcom platform already enabled HW reset. > > //Bean > Hi Bean, By pending tasks here, it means the requests sent down from scsi/block layer, but have not yet been handled by ufs driver(cmd->scsi_done() have not been called yet for these requests). For these requests, although removed by host and UFS device in their HW queues(doorbell), UFS driver still needs to complete them from SW side(call cmd->scsi_done() for each one of them) to let upper layer know that they are finished(although not successfully) to avoid hitting timeout of these pending tasks. I hope I make my explanation clearly. Best Regards, Can Guo. >> Since the OCSs of these pending requests are not SUCCESS(because they >> are not >> yet literally finished), their UPIUs shall be dumped. When there are >> multiple >> pending requests, the UPIU dump can be overwhelming and may lead to >> stability >> issues because it is in atomic context. >> Therefore, before probe, complete these pending requests right after >> host >> controller is stopped.