From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 603DCC4332F for ; Mon, 6 Nov 2023 06:58:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230299AbjKFG6I (ORCPT ); Mon, 6 Nov 2023 01:58:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbjKFG6H (ORCPT ); Mon, 6 Nov 2023 01:58:07 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04FCCA4; Sun, 5 Nov 2023 22:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699253885; x=1730789885; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=d/1uCOzy63KPya2fh5wdWCSdQMv4USuUbMlWjMlQ4EE=; b=WCRSfy5jCKnakdsywufSVJFh7zTRlmeLcqy73FlNTw4Ufwo7PYgFn36R x1u86eKmaEoQBuj9Lo1MCDrXMhudCUjwT6FPrS/Sm7pVhQB7ZpXONZjdO pXCXsUCWkhJ0K57SS3DTbdfKZsyLo1pBGRrgJB3HdA60JM1E4LOcbqPXK bUtImtOAGsk6s5ShajCKjhv/p3eq29biyeDWgF+zuoXoAxgx8V4NYRqTq 9gFIyDTw7438D4D5qbW1X35lULKFZC7RwmQsNkE9uWrfdwJOP/+Y4vbBl NaqYxKZJeQu7CLfOg6UCKZzq4uACbBofZLrI+mdvcZXukXFeXS8R3lFpD Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="368554212" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="368554212" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 22:58:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="738719602" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="738719602" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO [10.0.2.15]) ([10.251.215.231]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 22:57:59 -0800 Message-ID: <0c36eb5d-d703-47e2-963f-619cb542ba3f@intel.com> Date: Mon, 6 Nov 2023 08:57:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2 2/6] mmc: cqhci: Increase recovery halt timeout Content-Language: en-US To: Avri Altman , Ulf Hansson , =?UTF-8?Q?Kornel_Dul=C4=99ba?= , Radoslaw Biernacki , Gwendal Grignou , Asutosh Das Cc: Chaotian Jing , Bhavya Kapoor , Kamal Dasu , Al Cooper , Haibo Chen , Shaik Sajida Bhanu , Sai Krishna Potthuri , Victor Shih , Ben Chuang , Thierry Reding , Aniruddha Tvs Rao , Chun-Hung Wu , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20231103084720.6886-1-adrian.hunter@intel.com> <20231103084720.6886-3-adrian.hunter@intel.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On 3/11/23 12:37, Avri Altman wrote: >> Failing to halt complicates the recovery. Additionally, unless the card or >> controller are stuck, which is expected to be very rare, then the halt should >> succeed, so it is better to wait. Set a large timeout. > Maybe also explain that If task queuing is in progress, CQE needs to complete the operation, sending both commands and processing the responses. True, although those commands should be quite quick. > >> >> Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled >> host") >> Cc: stable@vger.kernel.org >> Signed-off-by: Adrian Hunter > Reviewed-by: Avri Altman > >> --- >> drivers/mmc/host/cqhci-core.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/mmc/host/cqhci-core.c b/drivers/mmc/host/cqhci-core.c >> index b3d7d6d8d654..15f5a069af1f 100644 >> --- a/drivers/mmc/host/cqhci-core.c >> +++ b/drivers/mmc/host/cqhci-core.c >> @@ -984,10 +984,10 @@ static bool cqhci_halt(struct mmc_host *mmc, >> unsigned int timeout) >> /* >> * After halting we expect to be able to use the command line. We interpret >> the >> * failure to halt to mean the data lines might still be in use (and the upper >> - * layers will need to send a STOP command), so we set the timeout based >> on a >> - * generous command timeout. >> + * layers will need to send a STOP command), however failing to halt >> + complicates >> + * the recovery, so set a timeout that would reasonably allow I/O to >> complete. >> */ >> -#define CQHCI_START_HALT_TIMEOUT 5 >> +#define CQHCI_START_HALT_TIMEOUT 500 >> >> static void cqhci_recovery_start(struct mmc_host *mmc) { >> -- >> 2.34.1 >