On 2021-03-23 13:37, Daejun Park wrote:

quoted

On 2021-03-23 12:22, Can Guo wrote:

quoted

On 2021-03-22 17:11, Bean Huo wrote:

quoted

On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:

quoted

+       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

quoted

Please correct me if I am wrong.

quoted

Thanks,
Can Guo.