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

thermal: hwmon: Properly report critical temperature in sysfs

2017-03-16T02:26:26+00:00

commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream.

In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space.  It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.

For example:
	/sys/class/hwmon/hwmon0/temp1_crit:50000
	/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
	/sys/class/thermal/thermal_zone0/trip_point_0_type:active
	/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
	/sys/class/thermal/thermal_zone0/trip_point_3_type:critical

Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided.  However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().

Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Zhang Rui 
Signed-off-by: Ben Hutchings

thermal: exynos: Fix unbalanced regulator disable on probe failure

2015-12-13T17:49:07+00:00

commit 824ead03b78403a21449cb7eb153a4344cd3b4c8 upstream.

During probe if the regulator could not be enabled, the error exit path
would still disable it. This could lead to unbalanced counter of
regulator enable/disable.

The patch moves code for getting and enabling the regulator from
exynos_map_dt_data() to probe function because it is really not a part
of getting Device Tree properties.

Acked-by: Lukasz Majewski 
Tested-by: Lukasz Majewski 
Reviewed-by: Alim Akhtar 
Signed-off-by: Krzysztof Kozlowski 
Fixes: 5f09a5cbd14a ("thermal: exynos: Disable the regulator on probe failure")
Signed-off-by: Eduardo Valentin 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

thermal: exynos: Disable the regulator on probe failure

2015-08-27T11:08:09+00:00

commit 5f09a5cbd14ae16e93866040fa44d930ff885650 upstream.

During probe the regulator (if present) was enabled but not disabled in
case of failure. So an unsuccessful probe lead to enabling the
regulator which was actually not needed because the device was not
enabled.

Additionally each deferred probe lead to increase of regulator enable
count so it would not be effectively disabled during removal of the
device.

Test HW: Exynos4412 - Trats2 board

Signed-off-by: Krzysztof Kozlowski 
Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator defined at device tree")
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Lukasz Majewski 
Tested-by: Lukasz Majewski 
Signed-off-by: Eduardo Valentin 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

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

2015-08-10T08:54:04+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: Luis Henriques

thermal: step_wise: Revert optimization

2015-06-12T11:55:03+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
Signed-off-by: Luis Henriques

thermal: armada: Update Armada 380 thermal sensor coefficients

2015-06-02T11:08:12+00:00

commit efa86858e1d8970411a140fa1e0c4dd18a8f2a89 upstream.

Improve the Armada 380 thermal sensor accuracy by using updated formula.
The updated formula is:
Temperature[C degrees] = 0.4761 * tsen_vsen_out - 279.1

Signed-off-by: Nadav Haklai 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Luis Henriques

tick/powerclamp: Remove tick_nohz_idle abuse

2015-01-15T10:44:41+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: Luis Henriques

thermal: Fix error path in thermal_init()

2015-01-15T10:43:37+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: Zhang Rui 
Signed-off-by: Luis Henriques

thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address is checked

2014-07-01T01:52:35+00:00

Wrong address is checked after memory allocation.

Signed-off-by: Rickard Strandqvist 
Signed-off-by: Zhang Rui

Thermal: imx: correct critical trip temperature setting

2014-07-01T01:22:28+00:00

On latest i.MX6 SOC with thermal calibration data of 0x5A100000,
the critical trip temperature will be an invalid value and
cause system auto shutdown as below log:

thermal thermal_zone0: critical temperature reached(42 C),shutting down

So, with universal formula for thermal sensor, only room
temperature point is calibrated, which means the calibration
data read from fuse only has valid data of bit [31:20], others
are all 0, the critical trip point temperature can NOT depend
on the hot point calibration data, here we set it to 20 C higher
than default passive temperature.

Signed-off-by: Anson Huang 
Acked-by: Shawn Guo 
Signed-off-by: Zhang Rui