1. 27 9月, 2016 22 次提交
  2. 19 8月, 2016 3 次提交
  3. 08 8月, 2016 5 次提交
    • W
      thermal: clock_cooling: Fix missing mutex_init() · 165989a5
      Wei Yongjun 提交于
      The driver allocates the mutex but not initialize it.
      Use mutex_init() on it to initialize it correctly.
      
      This is detected by Coccinelle semantic patch.
      Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      165989a5
    • K
      thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs · f4c59243
      Kuninori Morimoto 提交于
      thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need
      EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR
      
      >> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!
      >> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      f4c59243
    • M
      thermal: fix race condition when updating cooling device · d0b7306d
      Michele Di Giorgio 提交于
      When multiple thermal zones are bound to the same cooling device, multiple
      kernel threads may want to update the cooling device state by calling
      thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race
      condition. Consider the following situation with two kernel threads k1 and k2:
      
      	    Thread k1				Thread k2
                                          ||
                                          ||  call thermal_cdev_update()
                                          ||      ...
                                          ||      set_cur_state(cdev, target);
          call power_actor_set_power()    ||
              ...                         ||
              instance->target = state;   ||
              cdev->updated = false;      ||
                                          ||      cdev->updated = true;
                                          ||      // completes execution
          call thermal_cdev_update()      ||
              // cdev->updated == true    ||
              return;                     ||
                                          \/
                                          time
      
      k2 has already looped through the thermal instances looking for the deepest
      cooling device state and is preempted right before setting cdev->updated to
      true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated
      to false. Then, k1 is preempted and k2 continues the execution by setting
      cdev->updated to true, therefore preventing k1 from performing the update.
      Notice that this is not an issue if k2 looks at the instance->target modified by
      k1 "after" it is assigned by k1. In fact, in this case the update will happen
      anyway and k1 can safely return immediately from thermal_cdev_update().
      
      This may lead to a situation where a thermal governor never updates the cooling
      device. For example, this is the case for the step_wise governor: when calling
      the function thermal_zone_trip_update(), the governor may always get a new state
      equal to the old one (which, however, wasn't notified to the cooling device) and
      will therefore skip the update.
      
      CC: Zhang Rui <rui.zhang@intel.com>
      CC: Eduardo Valentin <edubezval@gmail.com>
      CC: Peter Feuerer <peter@piie.net>
      Reported-by: NToby Huang <toby.huang@arm.com>
      Signed-off-by: NMichele Di Giorgio <michele.digiorgio@arm.com>
      Reviewed-by: NJavi Merino <javi.merino@arm.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      d0b7306d
    • P
      thermal/powerclamp: Prevent division by zero when counting interval · 70c50ee7
      Petr Mladek 提交于
      I have got a zero division error when disabling the forced
      idle injection from the intel powerclamp. I did
      
        echo 0 >/sys/class/thermal/cooling_device48/cur_state
      
      and got
      
      [  986.072632] divide error: 0000 [#1] PREEMPT SMP
      [  986.078989] Modules linked in:
      [  986.083618] CPU: 17 PID: 24967 Comm: kidle_inject/17 Not tainted 4.7.0-1-default+ #3055
      [  986.093781] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.R3.27.D685.1305151734 05/15/2013
      [  986.106227] task: ffff880430e1c080 task.stack: ffff880427ef0000
      [  986.114122] RIP: 0010:[<ffffffff81794859>]  [<ffffffff81794859>] clamp_thread+0x1d9/0x600
      [  986.124609] RSP: 0018:ffff880427ef3e20  EFLAGS: 00010246
      [  986.131860] RAX: 0000000000000258 RBX: 0000000000000006 RCX: 0000000000000001
      [  986.141179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000018
      [  986.150478] RBP: ffff880427ef3ec8 R08: ffff880427ef0000 R09: 0000000000000002
      [  986.159779] R10: 0000000000003df2 R11: 0000000000000018 R12: 0000000000000002
      [  986.169089] R13: 0000000000000000 R14: ffff880427ef0000 R15: ffff880427ef0000
      [  986.178388] FS:  0000000000000000(0000) GS:ffff880435940000(0000) knlGS:0000000000000000
      [  986.188785] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  986.196559] CR2: 00007f1d0caf0000 CR3: 0000000002006000 CR4: 00000000001406e0
      [  986.205909] Stack:
      [  986.209524]  ffff8802be897b00 ffff880430e1c080 0000000000000011 0000006a35959780
      [  986.219236]  0000000000000011 ffff880427ef0008 0000000000000000 ffff8804359503d0
      [  986.228966]  0000000100029d93 ffffffff81794140 0000000000000000 ffffffff05000011
      [  986.238686] Call Trace:
      [  986.242825]  [<ffffffff81794140>] ? pkg_state_counter+0x80/0x80
      [  986.250866]  [<ffffffff81794680>] ? powerclamp_set_cur_state+0x180/0x180
      [  986.259797]  [<ffffffff8111d1a9>] kthread+0xc9/0xe0
      [  986.266682]  [<ffffffff8193d69f>] ret_from_fork+0x1f/0x40
      [  986.274142]  [<ffffffff8111d0e0>] ? kthread_create_on_node+0x180/0x180
      [  986.282869] Code: d1 ea 48 89 d6 80 3d 6a d0 d4 00 00 ba 64 00 00 00 89 d8 41 0f 45 f5 0f af c2 42 8d 14 2e be 31 00 00 00 83 fa 31 0f 42 f2 31 d2 <f7> f6 48 8b 15 9e 07 87 00 48 8b 3d 97 07 87 00 48 63 f0 83 e8
      [  986.307806] RIP  [<ffffffff81794859>] clamp_thread+0x1d9/0x600
      [  986.315871]  RSP <ffff880427ef3e20>
      
      RIP points to the following lines:
      
      	compensation = get_compensation(target_ratio);
      	interval = duration_jiffies*100/(target_ratio+compensation);
      
      A solution would be to switch the following two commands in
      powerclamp_set_cur_state():
      
      	set_target_ratio = 0;
      	end_power_clamp();
      
      But I think that the zero division might happen also when target_ratio
      is non-zero because the compensation might be negative. Therefore
      we also check the sum of target_ratio and compensation explicitly.
      
      Also the compensated_ratio variable is always set. Therefore there
      is no need to initialize it.
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Acked-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      70c50ee7
    • S
      thermal: intel_pch_thermal: Add suspend/resume callback · 176b1ec2
      Srinivas Pandruvada 提交于
      Added suspend/resume callback to disable/enable PCH thermal sensor
      respectively. If the sensor is enabled by the BIOS, then the sensor status
      will not be changed during suspend/resume.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      176b1ec2
  4. 09 6月, 2016 1 次提交
    • V
      cpufreq: Remove cpufreq_frequency_get_table() · f8bfc116
      Viresh Kumar 提交于
      Most of the callers of cpufreq_frequency_get_table() already have the
      pointer to a valid 'policy' structure and they don't really need to go
      through the per-cpu variable first and then a check to validate the
      frequency, in order to find the freq-table for the policy.
      
      Directly use the policy->freq_table field instead for them.
      
      Only one user of that API is left after above changes, cpu_cooling.c and
      it accesses the freq_table in a racy way as the policy can get freed in
      between.
      
      Fix it by using cpufreq_cpu_get() properly.
      
      Since there are no more users of cpufreq_frequency_get_table() left, get
      rid of it.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: Javi Merino <javi.merino@arm.com> (cpu_cooling.c)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8bfc116
  5. 08 6月, 2016 1 次提交
  6. 01 6月, 2016 1 次提交
  7. 30 5月, 2016 1 次提交
  8. 17 5月, 2016 6 次提交