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

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 <redacted>