1. 05 5月, 2016 1 次提交
  2. 21 2月, 2016 2 次提交
  3. 16 2月, 2016 2 次提交
    • V
      PM / OPP: Initialize regulator pointer to an error value · 0c717d0f
      Viresh Kumar 提交于
      We are currently required to do two checks for regulator pointer:
      IS_ERR() and IS_NULL().
      
      And multiple instances are reported, about both of these not being used
      consistently and so resulting in crashes.
      
      Fix that by initializing regulator pointer with an error value and
      checking it only against an error.
      
      This makes code more consistent and more efficient.
      
      Fixes: 7d34d56e (PM / OPP: Disable OPPs that aren't supported by the regulator)
      Reported-and-tested-by: NJon Hunter <jonathanh@nvidia.com>
      Reported-and-tested-by: NTony Lindgren <tony@atomide.com>
      Reported-and-tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Initialize to -ENXIO ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0c717d0f
    • V
      PM / OPP: Initialize u_volt_min/max to a valid value · c88c395f
      Viresh Kumar 提交于
      We kept u_volt_min/max initialized to 0, when only the target voltage is
      present in DT, instead of the target/min/max triplet.
      
      This didn't go well with the regulator framework, as on few calls the
      min voltage was set to target and max was set to 0 and so resulted in a
      kernel crash like below:
      
      kernel BUG at ../drivers/regulator/core.c:216!
      
      [<c0684af4>] (regulator_check_voltage) from [<c06857ac>] (regulator_set_voltage_unlocked+0x58/0x230)
      [<c06857ac>] (regulator_set_voltage_unlocked) from [<c06859ac>] (regulator_set_voltage+0x28/0x54)
      [<c06859ac>] (regulator_set_voltage) from [<c0775b28>] (_set_opp_voltage+0x30/0x98)
      [<c0775b28>] (_set_opp_voltage) from [<c0776630>] (dev_pm_opp_set_rate+0xf0/0x28c)
      [<c0776630>] (dev_pm_opp_set_rate) from [<c096f784>] (__cpufreq_driver_target+0x184/0x2b4)
      [<c096f784>] (__cpufreq_driver_target) from [<c0973760>] (dbs_check_cpu+0x1b0/0x1f4)
      [<c0973760>] (dbs_check_cpu) from [<c0973f30>] (cpufreq_governor_dbs+0x324/0x5c4)
      [<c0973f30>] (cpufreq_governor_dbs) from [<c0970958>] (__cpufreq_governor+0xe4/0x1ec)
      [<c0970958>] (__cpufreq_governor) from [<c09711e0>] (cpufreq_init_policy+0x64/0x8c)
      [<c09711e0>] (cpufreq_init_policy) from [<c09718cc>] (cpufreq_online+0x2fc/0x708)
      [<c09718cc>] (cpufreq_online) from [<c0765ff0>] (subsys_interface_register+0x94/0xd8)
      [<c0765ff0>] (subsys_interface_register) from [<c0970530>] (cpufreq_register_driver+0x14c/0x19c)
      [<c0970530>] (cpufreq_register_driver) from [<c09746dc>] (dt_cpufreq_probe+0x70/0xec)
      [<c09746dc>] (dt_cpufreq_probe) from [<c076907c>] (platform_drv_probe+0x4c/0xb0)
      [<c076907c>] (platform_drv_probe) from [<c07678e0>] (driver_probe_device+0x214/0x2c0)
      [<c07678e0>] (driver_probe_device) from [<c0767a18>] (__driver_attach+0x8c/0x90)
      [<c0767a18>] (__driver_attach) from [<c0765c2c>] (bus_for_each_dev+0x68/0x9c)
      [<c0765c2c>] (bus_for_each_dev) from [<c0766d78>] (bus_add_driver+0x1a0/0x218)
      [<c0766d78>] (bus_add_driver) from [<c076810c>] (driver_register+0x78/0xf8)
      [<c076810c>] (driver_register) from [<c0301d74>] (do_one_initcall+0x90/0x1d8)
      [<c0301d74>] (do_one_initcall) from [<c1100e14>] (kernel_init_freeable+0x15c/0x1fc)
      [<c1100e14>] (kernel_init_freeable) from [<c0b27a0c>] (kernel_init+0x8/0xf0)
      [<c0b27a0c>] (kernel_init) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
      Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)
      
      Fix that by initializing u_volt_min/max to the target voltage in such cases.
      Reported-and-tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 27465902 (PM / OPP: Add support to parse "operating-points-v2" bindings)
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c88c395f
  4. 12 2月, 2016 1 次提交
  5. 10 2月, 2016 7 次提交
  6. 06 1月, 2016 1 次提交
  7. 28 12月, 2015 1 次提交
  8. 11 12月, 2015 2 次提交
  9. 24 11月, 2015 1 次提交
    • V
      PM / OPP: Add debugfs support · deaa5146
      Viresh Kumar 提交于
      This patch adds debugfs support to OPP layer to export OPPs and their
      properties for all the devices.
      
      This creates a top level directory: /sys/kernel/debug/opp and then
      device specific directories (based on device names) inside it. For
      example: 'cpu0', 'cpu1', etc..
      
      If multiple devices share the OPP table, then the real directory is
      created only for the first device. For all others, links are created to
      the real directory.
      
      Inside the device specific directory, a separate directory is created
      for each OPP. And within that files per opp property.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      deaa5146
  10. 07 11月, 2015 3 次提交
    • V
      PM / OPP: Add opp_rcu_lockdep_assert() to _find_device_opp() · 0597e818
      Viresh Kumar 提交于
      _find_device_opp() should be called with rcu-read lock or
      dev_opp_list_lock held. Add the opp_rcu_lockdep_assert() check to make
      sure caller have taken appropriate locks.
      
      Fix comment over the routine as well.
      Suggested-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0597e818
    • V
      PM / OPP: Hold dev_opp_list_lock for writers · 4a3a1353
      Viresh Kumar 提交于
      Writers need to update OPP device and their list with dev_opp_list_lock
      mutex held, which was missed at few places. Fix it.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.3 <stable@vger.kernel.org> # 4.3
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4a3a1353
    • V
      PM / OPP: Protect updates to list_dev with mutex · 87b4115d
      Viresh Kumar 提交于
      dev_opp_list_lock is used everywhere to protect device and OPP lists,
      but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
      rcu-lock, which wouldn't help here as we are adding a new list_dev.
      
      This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
      from within rcu-lock, which isn't allowed as kzalloc can sleep when
      called with GFP_KERNEL.
      
      With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:
      
      include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      5 locks held by swapper/0/1:
       #0:  (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach+0x48/0x98
       #1:  (&dev->mutex){......}, at: [<c02f6904>] __driver_attach+0x58/0x98
       #2:  (cpu_hotplug.lock){++++++}, at: [<c00249d0>] get_online_cpus+0x40/0xb0
       #3:  (subsys mutex#5){+.+.+.}, at: [<c02f4f8c>] subsys_interface_register+0x44/0xdc
       #4:  (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus+0x0/0x1e4
      
      stack backtrace:
      CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.3.0-rc7-00047-g81f5932958a8 #59
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack+0x10/0x14)
      [<c001355c>] (show_stack) from [<c022553c>] (dump_stack+0x94/0xbc)
      [<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep+0x24c/0x298)
      [<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc+0xe8/0x164)
      [<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev+0x30/0x58)
      [<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus+0xd0/0x1e4)
      [<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init+0x4cc/0x62c)
      [<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online+0xbc/0x73c)
      [<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register+0x98/0xdc)
      [<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver+0x110/0x17c)
      [<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe+0x60/0x8c)
      [<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe+0x44/0xa4)
      [<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device+0x208/0x2f4)
      [<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach+0x94/0x98)
      [<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev+0x68/0x9c)
      Reported-by: NMichael Turquette <mturquette@baylibre.com>
      Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.3 <stable@vger.kernel.org> # 4.3
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      87b4115d
  11. 02 11月, 2015 3 次提交
  12. 15 9月, 2015 5 次提交
  13. 10 9月, 2015 1 次提交
  14. 09 9月, 2015 1 次提交
  15. 28 8月, 2015 3 次提交
  16. 07 8月, 2015 6 次提交