RE: [PATCH 0/3] devfreq: check the get_cur_freq() return value and use it in ufshcd

[Avri Altman]

> The devfreq core has three users of the optional ->get_cur_freq() callback.
> Two of them check the return value, the third one does not and passes an
> uninitialized frequency to the transition notifiers when the callback fails. Patch
> 1 fixes this.
> 
> Patch 3 adds the callback to ufshcd. Without it the cur_freq attribute shows
> the last frequency the governor selected, which is wrong whenever the
> controller is scaled outside the governor, for example after writing
> 0 to clkscale_enable.
> 
> The patches touch two subsystems. Patches 1 and 2 are for the devfreq tree
> and patch 3 is for the SCSI tree. They do not depend on each other at build
> time and can be applied separately. Patch 3 only needs patch 1 for the error
> case described above, which requires OPPs and happens before the controller
> is scaled for the first time.
> 
> Tested on a Radxa Dragon Q6A with UFS 3.1, with patch 3 applied:
> 
>   before "echo 0 > clkscale_enable":  cur_freq 75000000, target_freq
> 75000000
>   after  "echo 0 > clkscale_enable":  cur_freq 300000000, target_freq
> 75000000
> 
> Before patch 3 both files report 75000000 and keep doing so for as long as
> clock scaling stays disabled.
> 
> Clock scaling itself still works. A 4 GiB direct read moved the controller to
> 300000000 and back, and trans_stat recorded it.
> 
> Bean Huo (3):
>   PM / devfreq: Fall back to previous_freq when get_cur_freq() fails
>   PM / devfreq: Add more details to the get_cur_freq() comment
>   scsi: ufs: core: Report the current clock frequency to devfreq
> 
>  drivers/devfreq/devfreq.c |  5 ++---
>  drivers/ufs/core/ufshcd.c | 32 ++++++++++++++++++++++++++++++++
>  include/linux/devfreq.h   |  7 +++++--
>  3 files changed, 39 insertions(+), 5 deletions(-)
For the whole series:
Reviewed-by: Avri Altman <avri.altman@xxxxxxxxxxx>