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

thermal: rcar_thermal: Prevent doing work after unbind

2019-02-11T17:53:41+00:00

commit 697ee786f15d7b65c7f3045d45fe3a05d28e0911 upstream.

When testing bind/unbind on r8a7791/koelsch:

    WARNING: CPU: 1 PID: 697 at lib/debugobjects.c:329 debug_print_object+0x8c/0xb4
    ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x10

This happens if the workqueue runs after the device has been unbound.
Fix this by cancelling any queued work during remove.

Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Eduardo Valentin 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

thermal: rcar: Make error and remove paths symmetrical with init

2019-02-11T17:53:41+00:00

commit ac71c7025ebc1ed25114b1be77dc60b7f8cb8544 upstream.

Swap interrupt disable and thermal zone unregistration in the error and
remove paths, to make them more symmetrical with the initialization
path.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Kuninori Morimoto 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Ben Hutchings

thermal: rcar_thermal: Prevent hardware access during system suspend

2019-02-11T17:53:41+00:00

commit 3a31386217628ffe2491695be2db933c25dde785 upstream.

On r8a7791/koelsch, sometimes the following message is printed during
system suspend:

    rcar_thermal e61f0000.thermal: thermal sensor was broken

This happens if the workqueue runs while the device is already
suspended.  Fix this by using the freezable system workqueue instead,
cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from happening
during system suspend").

Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Ben Hutchings

thermal: imx: Fix race condition in imx_thermal_probe()

2018-10-21T07:44:55+00:00

commit cf1ba1d73a33944d8c1a75370a35434bf146b8a7 upstream.

When device boots with T > T_trip_1 and requests interrupt,
the race condition takes place. The interrupt comes before
THERMAL_DEVICE_ENABLED is set. This leads to an attempt to
reading sensor value from irq and disabling the sensor, based on
the data->mode field, which expected to be THERMAL_DEVICE_ENABLED,
but still stays as THERMAL_DEVICE_DISABLED. Afher this issue
sensor is never re-enabled, as the driver state is wrong.

Fix this problem by setting the 'data' members prior to
requesting the interrupts.

Fixes: 37713a1e8e4c ("thermal: imx: implement thermal alarm interrupt handling")
Signed-off-by: Mikhail Lappo 
Signed-off-by: Fabio Estevam 
Reviewed-by: Philipp Zabel 
Acked-by: Dong Aisheng 
Signed-off-by: Zhang Rui 
Signed-off-by: Ben Hutchings

thermal: imx: register irq handler later in probe

2018-10-21T07:44:54+00:00

commit 84866ee5818e95f6e97194656777c10ac24cb9d3 upstream.

The irq handler should be registered after the tempmon
module has been initialized in a known state and the
thermal_zone and cpu_cooling device have been registered
successfully. Otherwise, if the irq is triggled earlier
before thermal probe has been finished, it may lead to
'NULL' pointer kernel panic.

Signed-off-by: Bai Ping 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Ben Hutchings

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