On 6/14/21 7:36 PM, Can Guo wrote: > I've considered the similar way (leverage hba->host->eh_noresume) last > year, > but I didn't take this way due to below reasons: > > 1. UFS error handler basically does one thing - reset and restore, which > stops hba [1], resets device [2] and re-probes the device [3]. Stopping > hba [1] > shall complete any pending requests in the doorbell (with error or no > error). > After [1], suspend/resume contexts, blocked by SSU cmd, shall be unblocked > right away to do whatever it needs to handle the SSU cmd failure (completed > in [1], so scsi_execute() returns an error), e.g., put link back to the old > state. call ufshcd_vops_suspend(), turn off irq/clocks/powers and etc... > However, reset and restore ([2] and [3]) is still running, and it can > (most likely) > be disturbed by suspend/resume. So passing a parameter or using > hba->host->eh_noresume > to skip lock_system_sleep() and unlock_system_sleep() can break the cycle, > but error handling may run concurrently with suspend/resume. Of course > we can > modify suspend/resume to avoid it, but I was pursuing a minimal change > to get this fixed. > > 2. Whatever way we take to break the cycle, suspend/resume shall fail and > RPM framework shall save the error to dev.power.runtime_error, leaving > the device in runtime suspended or active mode permanently. If it is left > runtime suspended, UFS driver won't accept cmd anymore, while if it is left > runtime active, powers of UFS device and host will be left ON, leading > to power > penalty. So my main idea is to let suspend/resume contexts, blocked by > PM cmds, > fail fast first and then error handler recover everything back to work. Hi Can, Has it been considered to make the UFS error handler fail pending commands with an error code that causes the SCSI core to resubmit the SCSI command, e.g. DID_IMM_RETRY or DID_TRANSPORT_DISRUPTED? I want to prevent that power management or suspend/resume callbacks fail if the error handler succeeds with recovering the UFS transport. Thanks, Bart.
