[PATCH v2] ufs: core: fix lockdep warning of clk_scaling_lock

[Bart Van Assche]

On 7/24/22 21:30, peter.wang at mediatek.com wrote:
> From: Peter Wang <peter.wang at mediatek.com>
> 
> There have a lockdep warning like below in current flow.
> kworker/u16:0:  Possible unsafe locking scenario:
> 
> kworker/u16:0:        CPU0                    CPU1
> kworker/u16:0:        ----                    ----
> kworker/u16:0:   lock(&hba->clk_scaling_lock);
> kworker/u16:0:                                lock(&hba->dev_cmd.lock);
> kworker/u16:0:                                lock(&hba->clk_scaling_lock);
> kworker/u16:0:   lock(&hba->dev_cmd.lock);
> kworker/u16:0:
> 
> Before this patch clk_scaling_lock was held in reader mode during the ufshcd_wb_toggle() call.
> With this patch applied clk_scaling_lock is not held while ufshcd_wb_toggle() is called.
> 
> This is safe because ufshcd_wb_toggle will held clk_scaling_lock in reader mode "again" in flow
> ufshcd_wb_toggle -> __ufshcd_wb_toggle -> ufshcd_query_flag_retry -> ufshcd_query_flag ->
> ufshcd_exec_dev_cmd -> down_read(&hba->clk_scaling_lock);
> The protect should enough and make sure clock is not change while send command.

Since this is a bug fix, please add a Fixes: tag.

>   out_unprepare:
> -	ufshcd_clock_scaling_unprepare(hba, is_writelock);
> +	ufshcd_clock_scaling_unprepare(hba);
> +
> +	/* Enable Write Booster if we have scaled up else disable it */
> +	if (wb_toggle)
> +		ufshcd_wb_toggle(hba, scale_up);
> +
>   	return ret;
>   }

Can the above patch can have the following unwanted effect?
* ufshcd_devfreq_scale() calls ufshcd_clock_scaling_unprepare().
* Clock scaling to a lower frequency happens.
* ufshcd_wb_toggle() enables the write booster.

Shouldn't the above ufshcd_wb_toggle() call be surrounded by down_read() 
and up_read() calls in addition to a check whether the WriteBooster 
really should be enabled instead of using 'scale_up'?

Thanks,

Bart.