Dear maintainers,
on the branch before 6.5, There is race condition between UFS clock
scaling and ufshcd_ungate_work() would cause that host_self_block
mismatch to scsi_block_reqs_cnt.
Case 1:
UFS driver didn’t call ufshcd_hold() before calling
ufshcd_scsi_block_requests() from devfreq_monitor path:
--> Race condition happened between ufshcd_clock_scaling_prepare () and
ufshcd_ungate_work().
--> host_self_blocked was not set to 1 after ufshcd_clock_scaling_prepare().
--> Requests keep being dispatched to UFS driver and be sent out after
entering H8.
Case 2:
UFS driver has called ufshcd_hold() before calling
ufshcd_scsi_block_requests() from ufs calkscal enable/disable sysfs path:
--> The ufshcd_ungate_work() was running and already set UIC link
status to ACTIVE before the ufshcd_hold() be invoked.
--> The ufshcd_hold() would not flush ufshcd_ungate_work() if the link
status already been set to ACTIVE.
--> Race condition happened between ufshcd_clock_scaling_prepare () and
ufshcd_ungate_work().
--> host_self_blocked was not set to 1 after ufshcd_clock_scaling_prepare().
--> Requests keep being dispatched to UFS driver and be sent out after
entering H8.
Since branch 6.5 , we would not see this issue as the
ufshcd_scsi_block/unblock_requests() has been removed from ufshcd_hold()
and ufshcd_ungate_work due to below commit.
So can we know if the branch 6.1 6.2 6.3 and 6.4 accept bug fix now?
scsi: ufs: Ungate the clock synchronously
Ungating the clock asynchronously causes ufshcd_queuecommand() to return
SCSI_MLQUEUE_HOST_BUSY and hence causes commands to be requeued. This is
suboptimal. Allow ufshcd_queuecommand() to sleep such that clock ungating
does not trigger command requeuing. Remove the ufshcd_scsi_block_requests()
and ufshcd_scsi_unblock_requests() calls because these are no longer
needed. The flush_work(&hba->clk_gating.ungate_work) call is sufficient to
make the SCSI core wait for clock ungating to complete.
Best Regards,
Ziqi
