Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read

Can Guo
2021-03-23T06:12:28Z

On 2021-03-23 13:37, Daejun Park wrote:
>> On 2021-03-23 12:22, Can Guo wrote:
>>> On 2021-03-22 17:11, Bean Huo wrote:
>>>> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
>>>>> + switch (rsp_field->hpb_op) {
>>>>>
>>>>> + case HPB_RSP_REQ_REGION_UPDATE:
>>>>>
>>>>> + if (data_seg_len != DEV_DATA_SEG_LEN)
>>>>>
>>>>> + dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>>>>
>>>>> + "%s: data seg length is not
>>>>> same.\n",
>>>>>
>>>>> + __func__);
>>>>>
>>>>> + ufshpb_rsp_req_region_update(hpb, rsp_field);
>>>>>
>>>>> + break;
>>>>>
>>>>> + case HPB_RSP_DEV_RESET:
>>>>>
>>>>> + dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>>>>
>>>>> + "UFS device lost HPB information during
>>>>> PM.\n");
>>>>>
>>>>> + break;
>>>>
>>>> Hi Deajun,
>>>> This series looks good to me. Just here I have one question. You
>>>> didn't
>>>> handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
>>>> to
>>>> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
>>>> reset host side HPB entry as well or what else?
>>>>
>>>>
>>>> Bean
>>>
>>> Same question here - I am still collecting feedbacks from flash
>>> vendors
>>> about
>>> what is recommanded host behavior on reception of HPB Op code 0x2,
>>> since it
>>> is not cleared defined in HPB2.0 specs.
>>>
>>> Can Guo.
>>
>> I think the question should be asked in the HPB2.0 patch, since in
>> HPB1.0 device
>> control mode, a HPB reset in device side does not impact anything in
>> host side -
>> host is not writing back any HPB entries to device anyways and HPB
>> Read
>> cmd with
>> invalid HPB entries shall be treated as normal Read(10) cmd without
>> any
>> problems.
>
> Yes, UFS device will process read command even the HPB entries are
> valid or
> not. So it is warning about read performance drop by dev reset.

Yeah, but still I am 100% sure about what should host do in case of
HPB2.0
when it receives HPB Op code 0x2, I am waiting for feedbacks.

Thanks,
Can Guo.

>
> Thanks,
> Daejun
>
>> Please correct me if I am wrong.
>
>
>
>> Thanks,
>> Can Guo.
>>
>>
>>