>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.
Thanks,
Daejun
>Please correct me if I am wrong.
>Thanks,
>Can Guo.
>
>
>
