On 8/4/2025 8:43 PM, Peter Wang (王信友) wrote:
On Mon, 2025-08-04 at 15:54 +0800, Ziqi Chen wrote:
Hi Peter && Bart,
How do you think about using
if (!mutex_trylock(&hba->host->scan_mutex))
return -EAGAIN;
instead of
mutex_lock(&hba->host->scan_mutex);
But this way will cause one line print of devfreq failed.
BRs
Ziqi
Hi Ziqi,
After applying the patch below, the lockdep issue no longer appears.
Would you be able to upstream this fix?
---
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 2ff91f2..0af34ce 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1435,7 +1435,8 @@ static int ufshcd_clock_scaling_prepare(struct
ufs_hba *hba, u64 timeout_us)
* make sure that there are no outstanding requests when
* clock scaling is in progress
*/
- mutex_lock(&hba->host->scan_mutex);
+ if(!mutex_trylock(&hba->host->scan_mutex))
+ return -EAGAIN;
blk_mq_quiesce_tagset(&hba->host->tag_set);
mutex_lock(&hba->wb_mutex);
down_write(&hba->clk_scaling_lock);
Thanks.
Peter
Hi Peter,
I saw you raised a ACK change to revert this whole change on branch
Android16-6.12. Without this change, you will meet stuck issue during
stability reboot test due to request queue quiesce and unquiesce
mismatch.
This lockdep print just a warning, and as per my analysis before, This
is a misjudgment. But stuck/crash issue is a real issue which has real
instance.
Can you abort your reverting change?
BRs,
Ziqi
