Re: [PATCH v3 06/12] scsi: ufs: core: Add helpers to pause and resume command processing

[Can Guo <can.guo@oss.qualcomm.com>]

Hi Bart,

On 3/14/2026 6:26 AM, Bart Van Assche wrote:
> On 3/8/26 8:14 AM, Can Guo wrote:
>> +/**
>> + * ufshcd_pause_command_processing - Pause command processing
>> + * @hba: per-adapter instance
>> + * @timeout_us: timeout in microseconds to wait for pending commands 
>> to finish
>> + *
>> + * This function stops new command submissions and waits for 
>> existing commands
>> + * to complete.
>> + *
>> + * Return: 0 on success, %-EBUSY if commands did not finish within 
>> @timeout_us.
>> + * On failure, all acquired locks are released and the tagset is 
>> unquiesced.
>> + */
>> +int ufshcd_pause_command_processing(struct ufs_hba *hba, u64 
>> timeout_us)
>> +{
>> +    int ret = 0;
>> +
>> +    mutex_lock(&hba->host->scan_mutex);
>> +    blk_mq_quiesce_tagset(&hba->host->tag_set);
>> +    down_write(&hba->clk_scaling_lock);
>> +
>> +    if (ufshcd_wait_for_pending_cmds(hba, timeout_us)) {
>> +        ret = -EBUSY;
>> +        up_write(&hba->clk_scaling_lock);
>> +        blk_mq_unquiesce_tagset(&hba->host->tag_set);
>> +        mutex_unlock(&hba->host->scan_mutex);
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +/**
>> + * ufshcd_resume_command_processing - Resume command processing
>> + * @hba: per-adapter instance
>> + *
>> + * This function resumes command submissions.
>> + */
>> +void ufshcd_resume_command_processing(struct ufs_hba *hba)
>> +{
>> +    up_write(&hba->clk_scaling_lock);
>> +    blk_mq_unquiesce_tagset(&hba->host->tag_set);
>> +    mutex_unlock(&hba->host->scan_mutex);
>> +}
>> +
>
> This patch duplicates existing code. Please integrate the following
> changes in this patch:
> - ufshcd_clock_scaling_prepare() calls
>   ufshcd_pause_command_processing().
> - ufshcd_clock_scaling_unprepare() calls
>   ufshcd_resume_command_processing().
I looked into ufshcd_clock_scaling_prepare() and 
ufshcd_clock_scaling_unprepare(),
I see they are coupled with Writebooster, wb_mutex and check on 
scaling.is_allowed,
I don't see an easy way of calling ufshcd_pause_command_processing() and
ufshcd_resume_command_processing() from there.

I also checked the history of changes to ufshcd_clock_scaling_prepare() and
ufshcd_clock_scaling_unprepare(), I can see multiple issues, e.g., deadlock,
were reported and fixed. I am not confident at all to make intrusive changes
to the two functions without breaking clock scaling.

Can we do it later as a separate patch and with enough testing conducted?

Thanks,
Can Guo.
>
> Thanks,
>
> Bart.