lkml.org 
[lkml]   [2021]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: RE: [PATCH v32 4/4] scsi: ufs: Add HPB 2.0 support
From
Date
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
>
>
>

\
 
 \ /
  Last update: 2021-04-28 02:38    [W:0.211 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site