Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
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 <Avri.Altman@wdc.com>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        =?UTF-8?Q?Kornel_Dul=C4=99ba?= <korneld@chromium.org>,
        Radoslaw Biernacki <biernacki@google.com>,
        Gwendal Grignou <gwendal@chromium.org>,
        Asutosh Das <quic_asutoshd@quicinc.com>
Cc:     Chaotian Jing <chaotian.jing@mediatek.com>,
        Bhavya Kapoor <b-kapoor@ti.com>,
        Kamal Dasu <kamal.dasu@broadcom.com>,
        Al Cooper <alcooperx@gmail.com>,
        Haibo Chen <haibo.chen@nxp.com>,
        Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com>,
        Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>,
        Victor Shih <victor.shih@genesyslogic.com.tw>,
        Ben Chuang <ben.chuang@genesyslogic.com.tw>,
        Thierry Reding <thierry.reding@gmail.com>,
        Aniruddha Tvs Rao <anrao@nvidia.com>,
        Chun-Hung Wu <chun-hung.wu@mediatek.com>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20231103084720.6886-1-adrian.hunter@intel.com>
 <20231103084720.6886-3-adrian.hunter@intel.com>
 <DM6PR04MB65752D6E30DFE006E2CD5632FCA5A@DM6PR04MB6575.namprd04.prod.outlook.com>
From:   Adrian Hunter <adrian.hunter@intel.com>
Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki,
 Business Identity Code: 0357606 - 4, Domiciled in Helsinki
In-Reply-To: <DM6PR04MB65752D6E30DFE006E2CD5632FCA5A@DM6PR04MB6575.namprd04.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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 <adrian.hunter@intel.com>
> Reviewed-by: Avri Altman <avri.altman@wdc.com>
> 
>> ---
>>  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
>