On 9/19/22 07:47, Peter Wang wrote:
If the scsi error happened and need do ufshcd_eh_host_reset_handler, the
rpm state should in RPM_ACTIVE.
Because scsi need wakeup suspended LUN, and send command to LUN then get
error, right?
The following sequence may activate the SCSI error handler while the RPM
state is RPM_RESUMING:
* The RPM state is RPM_SUSPENDED.
* The RPM state is changed into RPM_RESUMING and ufshcd_wl_resume() is
called.
* ufshcd_set_dev_pwr_mode() calls scsi_execute() and the START STOP UNIT
command times out.
* Because of this timeout the SCSI error handler is activated.
If remove ufshcd_rpm_get_sync directly, think about this case.
ufshcd_err_handler is on going and try to abort some task (which may get
stuck and timeout too).
Then rpm count down try to suspend. Finally runtime suspend callback may
return IO error and IO hang.
Hmm ... suspending a UFS device involves calling ufshcd_wl_shutdown(),
ufshcd_set_dev_pwr_mode() and scsi_execute(). scsi_execute() is
serialized against the UFS error handler because the latter calls
ufshcd_scsi_block_requests().
Thanks,
Bart.
