linux-stable.git/drivers/thermal, branch linux-3.14.y

thermal: step_wise: fix: Prevent from binary overflow when trend is dropping

2015-08-03T16:29:52+00:00

commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706 upstream.

It turns out that some boards can have instance->lower greater than 0 and
when thermal trend is dropping it results with next_target equal to -1.

Since the next_target is defined as unsigned long it is interpreted as
0xFFFFFFFF and larger than instance->upper.
As a result the next_target is set to instance->upper which ramps up to
maximal cooling device target when the temperature is steadily decreasing.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Zhang Rui 
Cc: Mason 
Signed-off-by: Greg Kroah-Hartman

thermal: step_wise: Revert optimization

2015-06-06T15:19:39+00:00

Commit 178c2490b99f898efc06d1ad75cadc84f13021a6 ("thermal: step_wise:
cdev only needs update on a new target state") broke driver acerhdf.
That driver abused the step_wise thermal governor until the bang_bang
governor was available, and the optimization broke this usage model.

Kernels v3.12 to v3.18 are affected. In v3.19 the acerhdf driver was
switched to the bang_bang governor and that solved the problem.

For kernels v3.12 to v3.17, the bang_bang governor isn't available
yet so the easiest fix is to revert the optimization.

Signed-off-by: Jean Delvare 
Reported-by: Dieter Jurzitza (https://bugzilla.opensuse.org/show_bug.cgi?id=925961)
Tested-by: Peter Feuerer 
Tested-by: Dieter Jurzitza

tick/powerclamp: Remove tick_nohz_idle abuse

2015-01-27T16:18:55+00:00

commit a5fd9733a30d18d7ac23f17080e7e07bb3205b69 upstream.

commit 4dbd27711cd9 "tick: export nohz tick idle symbols for module
use" was merged via the thermal tree without an explicit ack from the
relevant maintainers.

The exports are abused by the intel powerclamp driver which implements
a fake idle state from a sched FIFO task. This causes all kinds of
wreckage in the NOHZ core code which rightfully assumes that
tick_nohz_idle_enter/exit() are only called from the idle task itself.

Recent changes in the NOHZ core lead to a failure of the powerclamp
driver and now people try to hack completely broken and backwards
workarounds into the NOHZ core code. This is completely unacceptable
and just papers over the real problem. There are way more subtle
issues lurking around the corner.

The real solution is to fix the powerclamp driver by rewriting it with
a sane concept, but that's beyond the scope of this.

So the only solution for now is to remove the calls into the core NOHZ
code from the powerclamp trainwreck along with the exports.

Fixes: d6d71ee4a14a "PM: Introduce Intel PowerClamp Driver"
Signed-off-by: Thomas Gleixner 
Cc: Preeti U Murthy 
Cc: Viresh Kumar 
Cc: Frederic Weisbecker 
Cc: Fengguang Wu 
Cc: Frederic Weisbecker 
Cc: Pan Jacob jun 
Cc: LKP 
Cc: Peter Zijlstra 
Cc: Zhang Rui 
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412181110110.17382@nanos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

thermal: Fix error path in thermal_init()

2015-01-08T18:00:49+00:00

commit 9d367e5e7b05c71a8c1ac4e9b6e00ba45a79f2fc upstream.

thermal_unregister_governors() and class_unregister() were being called in
the wrong order.

Fixes: 80a26a5c22b9 ("Thermal: build thermal governors into thermal_sys module")
Signed-off-by: Luis Henriques 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

thermal: hwmon: Make the check for critical temp valid consistent

2014-07-17T23:21:03+00:00

commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream.

On 05/21/2014 04:22 PM, Aaron Lu wrote:
> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>> Hello,
>>
>> I get following error when rmmod thermal.
>>
>> rmmod  thermal
>> Killed

While dealing with this problem, I found another problem that also
results in a kernel crash on thermal module removal:

From: Aaron Lu 
Date: Wed, 21 May 2014 16:05:38 +0800
Subject: thermal: hwmon: Make the check for critical temp valid consistent

We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
to decide if we need to create the temp_crit attribute file but we just
check if tz->ops->get_crit_temp exists to decide if we need to remove
that attribute file. Some ACPI thermal zone doesn't have a valid critical
trip point and that would result in removing a non-existent device file
on thermal module unload.

Signed-off-by: Aaron Lu 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

Thermal: thermal zone governor fix

2014-03-03T15:15:57+00:00

This patch does a cleanup about the thermal zone govenor,
setting and make the following rule.
1. For thermal zone devices that are registered w/o tz->tzp,
   they can use the default thermal governor only.
2. For thermal zone devices w/ governor name specified in
   tz->tzp->governor_name, we will use the default govenor
   if the governor specified is not available at the moment,
   and update tz->governor when the matched governor is registered.

This also fixes a problem that OF registered thermal zones
are running with no governor.

Signed-off-by: Zhang Rui 
Acked-by: Javi Merino

Thermal: Allow first update of cooling device state

2014-03-03T15:15:29+00:00

In initialization, if the cooling device is initialized at
max cooling state, and the thermal zone temperature is below
the first trip point, then the cooling state can't be updated
to the right state, untill the first trip point be triggered.

To fix this issue, allow first update of cooling device state
during registration, initialized "updated" device field as
"false" (instead of "true").

Signed-off-by: Wei Ni 
Signed-off-by: Zhang Rui

thermal,rcar_thermal: Add dependency on HAS_IOMEM

2014-03-03T15:15:02+00:00

Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST)
broke build on archs wihout io memory.

On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.

drivers/thermal/rcar_thermal.c:404: undefined reference to `devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to `devm_ioremap_resource'

Signed-off-by: Richard Weinberger 
Acked-by: Laurent Pinchart 
Acked-by: Kuninori Morimoto 
Signed-off-by: Zhang Rui

x86_pkg_temp_thermal: Fix the thermal zone type

2014-03-03T15:13:37+00:00

The thermal zone type should not include an instance number. Otherwise
each zone is considered a different type and the thermal-to-hwmon
bridge fails to group them all in a single hwmon device.

I also changed the type to "x86_pkg_temp", because "pkg" was too
generic, and other thermal drivers use an underscore, not a dash, as
a separator. Or maybe "cpu_pkg_temp" would be better?

Signed-off-by: Jean Delvare 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Zhang Rui

x86_pkg_temp_thermal: Do not expose as a hwmon device

2014-03-03T15:13:24+00:00

The temperature value reported by x86_pkg_temp_thermal is already
reported by the coretemp driver. So, do not expose this thermal zone
as a hwmon device, because it would be redundant.

Signed-off-by: Jean Delvare 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Acked-by: Guenter Roeck 
Signed-off-by: Zhang Rui