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(-)


base-commit: e30626823a406725ce29bc75cb8ec467d3e1e326
-- 
2.34.1