Message-ID: <690bbcfe-d6db-f6d1-acea-8ee5aa4ac606@quicinc.com>
Date:   Wed, 8 Mar 2023 17:35:54 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [RFC PATCH v1 4/4] ufs: mcq: Added ufshcd_mcq_abort()
Content-Language: en-US
To:     Bart Van Assche <bvanassche@acm.org>, <quic_asutoshd@quicinc.com>,
        <quic_cang@quicinc.com>, <mani@kernel.org>,
        <stanley.chu@mediatek.com>, <adrian.hunter@intel.com>,
        <beanhuo@micron.com>, <avri.altman@wdc.com>,
        <martin.petersen@oracle.com>
CC:     <linux-scsi@vger.kernel.org>,
        Alim Akhtar <alim.akhtar@samsung.com>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        Arthur Simchaev <Arthur.Simchaev@wdc.com>,
        open list <linux-kernel@vger.kernel.org>
References: <cover.1678247309.git.quic_nguyenb@quicinc.com>
 <c7fcbb70f0e74d225c1a09f107ba1058270739be.1678247309.git.quic_nguyenb@quicinc.com>
 <85994527-d09d-f381-3dda-7cfb9ce98d4b@acm.org>
 <ec627f76-380b-bdfd-e736-1626d5bde0e4@quicinc.com>
 <e354dece-5dc8-9cdc-b822-59a1e0f3a9c3@acm.org>
From:   "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
In-Reply-To: <e354dece-5dc8-9cdc-b822-59a1e0f3a9c3@acm.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 3/8/2023 3:25 PM, Bart Van Assche wrote:
> On 3/8/23 14:37, Bao D. Nguyen wrote:
>> On 3/8/2023 11:02 AM, Bart Van Assche wrote:
>>> On 3/7/23 20:01, Bao D. Nguyen wrote:
>>>> +    if (ufshcd_mcq_cqe_search(hba, hwq, tag)) {
>>>> +        dev_err(hba->dev, "%s: cmd found in cq. hwq=%d, tag=%d\n",
>>>> +                __func__, hwq->id, tag);
>>>> +        /*
>>>> +         * The command should not be 'stuck' in the CQ for such a 
>>>> long time.
>>>> +         * Is interrupt missing? Process the CQEs here. If the 
>>>> interrupt is
>>>> +         * invoked at a later time, the CQ will be empty because 
>>>> the CQEs
>>>> +         * are already processed here.
>>>> +         */
>>>> +        ufshcd_mcq_poll_cqe_lock(hba, hwq);
>>>> +        err = SUCCESS;
>>>> +        goto out;
>>>> +    }
>>>
>>> Please remove the above code and also the definition of the 
>>> ufshcd_mcq_cqe_search() function. The SCSI error handler submits an 
>>> abort to deal with command processing timeouts. 
>>> ufshcd_mcq_cqe_search() can only return true in case of a software 
>>> bug at the host side. Addressing such bugs is out of scope for the 
>>> SCSI error handler.
>>
>> This is an attempt to handle the error case similar to SDB mode where 
>> it prints "%s: cmd was completed, but without a notifying intr, tag = 
>> %d" in the ufshcd_abort() function.
>>
>> In this case the command has been completed by the hardware, but some 
>> reasons the software has not processed it. We have seen this print 
>> happened during debug sessions, so the error case does happen in SBL 
>> mode.
>>
>> Are you suggesting we should return error in this case without 
>> calling ufshcd_mcq_poll_cqe_lock()?
>
> What I am asking is to remove ufshcd_mcq_poll_cqe_lock() and all code 
> that depends on that function returning true. Although such code might 
> be useful for SoC debugging, helping with SoC debugging is out of 
> scope for Linux kernel drivers.
I will remove it. In that case, we don't need the first patch of this 
series, so I will remove the first patch as well. Thanks.
>
> Thanks,
>
> Bart.
>