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:2.593 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site