RE: RE: [PATCH v32 4/4] scsi: ufs: Add HPB 2.0 support

[Daejun Park <daejun7.park@samsung.com>]

Hi Avri,

>> @@ -1653,6 +2148,7 @@ void ufshpb_destroy_lu(struct ufs_hba *hba, struct
>> scsi_device *sdev)
>> 
>>         ufshpb_cancel_jobs(hpb);
>> 
>> +       ufshpb_pre_req_mempool_destroy(hpb);
>>         ufshpb_destroy_region_tbl(hpb);
>> 
>>         kmem_cache_destroy(hpb->map_req_cache);
>> @@ -1692,6 +2188,7 @@ static void ufshpb_hpb_lu_prepared(struct ufs_hba
>> *hba)
>>                         ufshpb_set_state(hpb, HPB_PRESENT);
>>                         if ((hpb->lu_pinned_end - hpb->lu_pinned_start) > 0)
>>                                 queue_work(ufshpb_wq, &hpb->map_work);
>> +                       ufshpb_issue_umap_all_req(hpb);
>>                 } else {
>>                         dev_err(hba->dev, "destroy HPB lu %d\n", hpb->lun);
>>                         ufshpb_destroy_lu(hba, sdev);
>Here in lu_prepare, ufshpb_remove can be called without destroy_lu,
>and while there are jobs running.

If init_success is false, ufshpb_destroy_lu and ufshpb_remove are called.
If init_success is true, ufshpb_destroy_lu and ufshpb_remove are not called
in this function.

So I think it is not problem.

Thanks,
Daejun

>How about calling destroy_lu as part of ufshpb_remove?
>Calling it again when __scsi_remove_device, hostdata is already null so it won't matter.
> 
>Again, only after we know where all this is going to.
> 
>Thanks,
>Avri
> 
> 
>