1. 19 Feb, 2019 1 commit
  2. 09 Jan, 2019 1 commit
  3. 08 Jan, 2019 1 commit
    • Sudeep Holla's avatar
      cpufreq: check if policy is inactive early in __cpufreq_get() · 2f661962
      Sudeep Holla authored
      cpuinfo_cur_freq gets current CPU frequency as detected by hardware
      while scaling_cur_freq last known CPU frequency. Some platforms may not
      allow checking the CPU frequency of an offline CPU or the associated
      resources may have been released via cpufreq_exit when the CPU gets
      offlined, in which case the policy would have been invalidated already.
      If we attempt to get current frequency from the hardware, it may result
      in hang or crash.
      
      For example on Juno, I see:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000188
      [0000000000000188] pgd=0000000000000000
      Internal error: Oops: 96000004 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 5 PID: 4202 Comm: cat Not tainted 4.20.0-08251-ga0f2c0318a15-dirty #87
      Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform
      pstate: 40000005 (nZcv daif -PAN -UAO)
      pc : scmi_cpufreq_get_rate+0x34/0xb0
      lr : scmi_cpufreq_get_rate+0x34/0xb0
      Call trace:
       scmi_cpufreq_get_rate+0x34/0xb0
       __cpufreq_get+0x34/0xc0
       show_cpuinfo_cur_freq+0x24/0x78
       show+0x40/0x60
       sysfs_kf_seq_show+0xc0/0x148
       kernfs_seq_show+0x44/0x50
       seq_read+0xd4/0x480
       kernfs_fop_read+0x15c/0x208
       __vfs_read+0x60/0x188
       vfs_read+0x94/0x150
       ksys_read+0x6c/0xd8
       __arm64_sys_read+0x24/0x30
       el0_svc_common+0x78/0x100
       el0_svc_handler+0x38/0x78
       el0_svc+0x8/0xc
      ---[ end trace 3d1024e58f77f6b2 ]---
      
      So fix the issue by checking if the policy is invalid early in
      __cpufreq_get before attempting to get the current frequency.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f661962
  4. 04 Jan, 2019 1 commit
    • Viresh Kumar's avatar
      cpufreq: scpi/scmi: Fix freeing of dynamic OPPs · 1690d8bb
      Viresh Kumar authored
      Since the commit 2a4eb735 "OPP: Don't remove dynamic OPPs from
      _dev_pm_opp_remove_table()", dynamically created OPP aren't
      automatically removed anymore by dev_pm_opp_cpumask_remove_table(). This
      affects the scpi and scmi cpufreq drivers which no longer free OPPs on
      failures or on invocations of the policy->exit() callback.
      
      Create a generic OPP helper dev_pm_opp_remove_all_dynamic() which can be
      called from these drivers instead of dev_pm_opp_cpumask_remove_table().
      
      In dev_pm_opp_remove_all_dynamic(), we need to make sure that the
      opp_list isn't getting accessed simultaneously from other parts of the
      OPP core while the helper is freeing dynamic OPPs, i.e. we can't drop
      the opp_table->lock while traversing through the OPP list. And to
      accomplish that, this patch also creates _opp_kref_release_unlocked()
      which can be called from this new helper with the opp_table lock already
      held.
      
      Cc: 4.20 <stable@vger.kernel.org> # v4.20
      Reported-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Fixes: 2a4eb735 "OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()"
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Tested-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Reviewed-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1690d8bb
  5. 18 Dec, 2018 1 commit
  6. 11 Dec, 2018 3 commits
    • Quentin Perret's avatar
      sched/topology: Make Energy Aware Scheduling depend on schedutil · 531b5c9f
      Quentin Perret authored
      Energy Aware Scheduling (EAS) is designed with the assumption that
      frequencies of CPUs follow their utilization value. When using a CPUFreq
      governor other than schedutil, the chances of this assumption being true
      are small, if any. When schedutil is being used, EAS' predictions are at
      least consistent with the frequency requests. Although those requests
      have no guarantees to be honored by the hardware, they should at least
      guide DVFS in the right direction and provide some hope in regards to the
      EAS model being accurate.
      
      To make sure EAS is only used in a sane configuration, create a strong
      dependency on schedutil being used. Since having sugov compiled-in does
      not provide that guarantee, make CPUFreq call a scheduler function on
      governor changes hence letting it rebuild the scheduling domains, check
      the governors of the online CPUs, and enable/disable EAS accordingly.
      Signed-off-by: default avatarQuentin Perret <quentin.perret@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: adharmap@codeaurora.org
      Cc: chris.redpath@arm.com
      Cc: currojerez@riseup.net
      Cc: dietmar.eggemann@arm.com
      Cc: edubezval@gmail.com
      Cc: gregkh@linuxfoundation.org
      Cc: javi.merino@kernel.org
      Cc: joel@joelfernandes.org
      Cc: juri.lelli@redhat.com
      Cc: morten.rasmussen@arm.com
      Cc: patrick.bellasi@arm.com
      Cc: pkondeti@codeaurora.org
      Cc: skannan@codeaurora.org
      Cc: smuckle@google.com
      Cc: srinivas.pandruvada@linux.intel.com
      Cc: thara.gopinath@linaro.org
      Cc: tkjos@google.com
      Cc: valentin.schneider@arm.com
      Cc: vincent.guittot@linaro.org
      Cc: viresh.kumar@linaro.org
      Link: https://lkml.kernel.org/r/20181203095628.11858-9-quentin.perret@arm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      531b5c9f
    • Yangtao Li's avatar
      cpufreq: nforce2: Remove meaningless return · a67d5849
      Yangtao Li authored
      Delete a line of meaningless return and some useless blank lines. In a function
      whose return type is void, returning on the last line is not required.
      Signed-off-by: default avatarYangtao Li <tiny.windzz@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a67d5849
    • Yangtao Li's avatar
      cpufreq: ia64: Remove unused header files · df3e1c83
      Yangtao Li authored
      seq_file.h does not need to be included, so remove it. Moreover deleted
      a line of meaningless return and some useless blank lines. In a function
      whose return type is void, returning on the last line is not required.
      Signed-off-by: default avatarYangtao Li <tiny.windzz@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      df3e1c83
  7. 29 Nov, 2018 6 commits
  8. 27 Nov, 2018 2 commits
  9. 26 Nov, 2018 1 commit
  10. 19 Nov, 2018 1 commit
  11. 07 Nov, 2018 1 commit
  12. 25 Oct, 2018 3 commits
  13. 17 Oct, 2018 1 commit
  14. 16 Oct, 2018 2 commits
  15. 08 Oct, 2018 2 commits
  16. 04 Oct, 2018 1 commit
  17. 03 Oct, 2018 1 commit
  18. 02 Oct, 2018 1 commit
    • Peter Zijlstra's avatar
      x86/cpu: Sanitize FAM6_ATOM naming · f2c4db1b
      Peter Zijlstra authored
      Going primarily by:
      
        https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
      
      with additional information gleaned from other related pages; notably:
      
       - Bonnell shrink was called Saltwell
       - Moorefield is the Merriefield refresh which makes it Airmont
      
      The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
      
        for i in `git grep -l FAM6_ATOM` ; do
      	sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g'		\
      		-e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/'		\
      		-e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g'		\
      		-e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g'	\
      		-e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g'		\
      		-e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g'	\
      		-e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g'	\
      		-e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g'	\
      		-e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g'	\
      		-e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g'		\
      		-e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
        done
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: dave.hansen@linux.intel.com
      Cc: len.brown@intel.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f2c4db1b
  19. 29 Sep, 2018 1 commit
    • Nathan Chancellor's avatar
      cpufreq: qcom-kryo: Fix section annotations · d51aea13
      Nathan Chancellor authored
      There is currently a warning when building the Kryo cpufreq driver into
      the kernel image:
      
      WARNING: vmlinux.o(.text+0x8aa424): Section mismatch in reference from
      the function qcom_cpufreq_kryo_probe() to the function
      .init.text:qcom_cpufreq_kryo_get_msm_id()
      The function qcom_cpufreq_kryo_probe() references
      the function __init qcom_cpufreq_kryo_get_msm_id().
      This is often because qcom_cpufreq_kryo_probe lacks a __init
      annotation or the annotation of qcom_cpufreq_kryo_get_msm_id is wrong.
      
      Remove the '__init' annotation from qcom_cpufreq_kryo_get_msm_id
      so that there is no more mismatch warning.
      
      Additionally, Nick noticed that the remove function was marked as
      '__init' when it should really be marked as '__exit'.
      
      Fixes: 46e2856b (cpufreq: Add Kryo CPU scaling driver)
      Fixes: 5ad7346b (cpufreq: kryo: Add module remove and exit)
      Reported-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.18+ <stable@vger.kernel.org> # 4.18+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d51aea13
  20. 27 Sep, 2018 1 commit
  21. 19 Sep, 2018 1 commit
  22. 17 Sep, 2018 1 commit
  23. 10 Sep, 2018 2 commits
  24. 16 Aug, 2018 1 commit
  25. 06 Aug, 2018 1 commit
  26. 31 Jul, 2018 1 commit
  27. 26 Jul, 2018 1 commit
    • Waiman Long's avatar
      cpufreq: Fix a circular lock dependency problem · 9b3d9bb3
      Waiman Long authored
      With lockdep turned on, the following circular lock dependency problem
      was reported:
      
      [   57.470040] ======================================================
      [   57.502900] WARNING: possible circular locking dependency detected
      [   57.535208] 4.18.0-0.rc3.1.el8+7.x86_64+debug #1 Tainted: G
      [   57.577761] ------------------------------------------------------
      [   57.609714] tuned/1505 is trying to acquire lock:
      [   57.633808] 00000000559deec5 (cpu_hotplug_lock.rw_sem){++++}, at: store+0x27/0x120
      [   57.672880]
      [   57.672880] but task is already holding lock:
      [   57.702184] 000000002136ca64 (kn->count#118){++++}, at: kernfs_fop_write+0x1d0/0x410
      [   57.742176]
      [   57.742176] which lock already depends on the new lock.
      [   57.742176]
      [   57.785220]
      [   57.785220] the existing dependency chain (in reverse order) is:
          :
      [   58.932512] other info that might help us debug this:
      [   58.932512]
      [   58.973344] Chain exists of:
      [   58.973344]   cpu_hotplug_lock.rw_sem --> subsys mutex#5 --> kn->count#118
      [   58.973344]
      [   59.030795]  Possible unsafe locking scenario:
      [   59.030795]
      [   59.061248]        CPU0                    CPU1
      [   59.085377]        ----                    ----
      [   59.108160]   lock(kn->count#118);
      [   59.124935]                                lock(subsys mutex#5);
      [   59.156330]                                lock(kn->count#118);
      [   59.186088]   lock(cpu_hotplug_lock.rw_sem);
      [   59.208541]
      [   59.208541]  *** DEADLOCK ***
      
      In the cpufreq_register_driver() function, the lock sequence is:
      
        cpus_read_lock --> kn->count
      
      For the cpufreq sysfs store method, the lock sequence is:
      
        kn->count --> cpus_read_lock
      
      These sequences are actually safe as they are taking a share lock on
      cpu_hotplug_lock. However, the current lockdep code doesn't check for
      share locking when detecting circular lock dependency.  Fixing that
      could be a substantial effort.
      
      Instead, we can work around this problem by using cpus_read_trylock()
      in the store method which is much simpler. The chance of not getting
      the read lock is very small. If that happens, the userspace application
      that writes the sysfs file will get an error.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9b3d9bb3