linux-stable.git/drivers/thermal, branch v3.12.44

thermal: step_wise: Revert optimization

2015-06-03T09:33:13+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-26T13:39:29+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: Jiri Slaby

thermal: Fix error path in thermal_init()

2015-01-07T16:55:08+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: Jiri Slaby

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

2014-07-18T13:51:16+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: Jiri Slaby

x86_pkg_temp_thermal: Do not expose as a hwmon device

2014-03-22T21:01:54+00:00

commit 79786880a47a8c5b4c8146c03432b3387a07a169 upstream.

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 
Signed-off-by: Jiri Slaby

Merge branch 'x86_pkg_temp' of .git into for-rc

2013-10-21T03:26:45+00:00

Revert "drivers: thermal: parent virtual hwmon with thermal zone"

2013-10-21T03:16:29+00:00

Commit b82715fdd4a5407f56853b24d387d484dd9c3b5b introduces
a 'device' subdirectory under /sys/class/hwmon/hwmonX/ directory,
for the thermal_zone hwmon devices. And this results in different
handling by libsensors.

The problem is reported and discussed in this thread
http://marc.info/?l=linux-pm&m=138229306109596&w=2

This patch reverts commit b82715fdd4a5407f56853b24d387d484dd9c3b5b.

Reported-by: Arnaud Ebalard 
Signed-off-by: Zhang Rui

drivers: thermal: allow ti-soc-thermal run without pcb zone

2013-10-15T14:10:43+00:00

This patch changes the behavior of TI SoC thermal driver
when there is a PCB thermal zone.

Instead of reporting an error code when reading from
PCB temperature sensor fails, this patch will make
the driver attempt to compose the hotspot extrapolation
based on bandgap readings only.

Cc: Zhang Rui 
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin

thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412

2013-10-15T14:10:42+00:00

The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 ("thermal: exynos: Add
missing definations and code cleanup") has removed setting of test MUX address
value at TMU configuration setting.

This field is not present on Exynos4210 and Exynos5 SoCs. However on Exynos4412
SoC it is required to set this field after reset because without it TMU shows
maximal available temperature, which causes immediate platform shutdown.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Tomasz Figa 
Signed-off-by: Eduardo Valentin

thermal: exynos: Provide separate TMU data for Exynos4412

2013-10-15T14:10:42+00:00

Up till now Exynos5250 and Exynos4412 had the same definitions for TMU
data. Following commit changes that, by introducing separate
exynos4412_default_tmu_data structure.

Since Exynos4412 was chronologically first, the corresponding name for
TMU registers and default data was renamed.

Additionally, new SOC_ARCH_EXYNOS4412 type has been defined.

Moreover, the SOC_ARCH_EXYNOS name has been changed to SOC_ARCH_EXYNOS5250.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Tomasz Figa 
Signed-off-by: Eduardo Valentin