• C
    scsi: ufs: Recover HBA runtime PM error in error handler · c72e79c0
    Can Guo 提交于
    The current error handler can not recover HBA runtime PM error if
    ufshcd_suspend/resume has failed due to UFS errors, e.g. hibern8 enter/exit
    error or SSU cmd error. When this happens, error handler may fail
    performing a full reset and restore because error handler always assumes
    that power, IRQs and clocks are ready after pm_runtime_get_sync returns,
    but actually they are not if ufshcd_resume fails[1].
    
    If ufschd_suspend/resume fails due to UFS errors, runtime PM framework
    saves the error value to dev.power.runtime_error. After that, HBA dev
    runtime suspend/resume would not be invoked anymore unless runtime_error is
    cleared[2].
    
    In case of ufshcd_suspend/resume fails due to UFS errors, for scenario [1],
    error handler cannot assume anything of pm_runtime_get_sync, meaning error
    handler should explicitly turn ON powers, IRQs and clocks again. To get the
    HBA runtime PM work as regard for scenario [2], error handler can clear the
    runtime_error by calling pm_runtime_set_active() if full reset and restore
    succeeds. And, more important, if pm_runtime_set_active() returns no error,
    which means runtime_error has been cleared, we also need to resume those
    scsi devices under HBA in case any of them has failed to be resumed due to
    HBA runtime resume failure. This is to unblock blk_queue_enter in case
    there are bios waiting inside it.
    
    Link: https://lore.kernel.org/r/1596975355-39813-7-git-send-email-cang@codeaurora.orgReviewed-by: NBean Huo <beanhuo@micron.com>
    Reviewed-by: NAsutosh Das <asutoshd@codeaurora.org>
    Signed-off-by: NCan Guo <cang@codeaurora.org>
    Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
    c72e79c0
ufshcd.c 241.5 KB