Skip to content
  1. Oct 24, 2019
    • Rafael J. Wysocki's avatar
      Merge branches 'pm-cpuidle' and 'pm-opp' · 767d2d71
      Rafael J. Wysocki authored
      * pm-cpuidle:
        cpuidle: haltpoll: Take 'idle=' override into account
      
      * pm-opp:
        opp: Reinitialize the list_kref before adding the static OPPs again
        opp: core: Revert "add regulators enable and disable"
        opp: of: drop incorrect lockdep_assert_held()
      767d2d71
  2. Oct 23, 2019
    • Rafael J. Wysocki's avatar
      Merge branch 'opp/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm · 028db79c
      Rafael J. Wysocki authored
      Pull operating performance points (OPP) framework fixes for v5.4
      from Viresh Kumar:
      
      "This contains:
      
      - Patch to revert addition of regulator enable/disable in OPP core
        (Marek).
      - Remove incorrect lockdep assert (Viresh).
      - Fix a kref counting issue (Viresh)."
      
      * 'opp/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
        opp: Reinitialize the list_kref before adding the static OPPs again
        opp: core: Revert "add regulators enable and disable"
        opp: of: drop incorrect lockdep_assert_held()
      028db79c
    • Viresh Kumar's avatar
      opp: Reinitialize the list_kref before adding the static OPPs again · b19c2355
      Viresh Kumar authored
      The list_kref reaches a count of 0 when all the static OPPs are removed,
      for example when dev_pm_opp_of_cpumask_remove_table() is called, though
      the actual OPP table may not get freed as it may still be referenced by
      other parts of the kernel, like from a call to
      dev_pm_opp_set_supported_hw(). And if we call
      dev_pm_opp_of_cpumask_add_table() again at this point, we must
      reinitialize the list_kref otherwise the kernel will hit a WARN() in
      kref infrastructure for incrementing a kref with value 0.
      
      Fixes: 11e1a164
      
       ("opp: Don't decrement uninitialized list_kref")
      Reported-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Tested-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      b19c2355
    • Sudeep Holla's avatar
      cpufreq: Cancel policy update work scheduled before freeing · 6941051d
      Sudeep Holla authored
      Scheduled policy update work may end up racing with the freeing of the
      policy and unregistering the driver.
      
      One possible race is as below, where the cpufreq_driver is unregistered,
      but the scheduled work gets executed at later stage when, cpufreq_driver
      is NULL (i.e. after freeing the policy and driver).
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000001c
      pgd = (ptrval)
      [0000001c] *pgd=80000080204003, *pmd=00000000
      Internal error: Oops: 206 [#1] SMP THUMB2
      Modules linked in:
      CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted 5.4.0-rc3-00006-g67f5a8081a4b #86
      Hardware name: ARM-Versatile Express
      Workqueue: events handle_update
      PC is at cpufreq_set_policy+0x58/0x228
      LR is at dev_pm_qos_read_value+0x77/0xac
      Control: 70c5387d  Table: 80203000  DAC: fffffffd
      Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval))
      	(cpufreq_set_policy) from (refresh_frequency_limits.part.24+0x37/0x48)
      	(refresh_frequency_limits.part.24) from (handle_update+0x2f/0x38)
      	(handle_update) from (process_one_work+0x16d/0x3cc)
      	(process_one_work) from (worker_thread+0xff/0x414)
      	(worker_thread) from (kthread+0xff/0x100)
      	(kthread) from (ret_from_fork+0x11/0x28)
      
      Fixes: 67d874c3
      
       ("cpufreq: Register notifiers with the PM QoS framework")
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      [ rjw: Cancel the work before dropping the QoS requests ]
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6941051d
  3. Oct 22, 2019
  4. Oct 21, 2019
  5. Oct 20, 2019
  6. Oct 19, 2019