linux-stable.git/drivers/thermal, branch v4.14.78

thermal: of-thermal: disable passive polling when thermal zone is disabled

2018-10-04T00:00:57+00:00

[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]

When thermal zone is in passive mode, disabling its mode from
sysfs is NOT taking effect at all, it is still polling the
temperature of the disabled thermal zone and handling all thermal
trips, it makes user confused. The disabling operation should
disable the thermal zone behavior completely, for both active and
passive mode, this patch clears the passive_delay when thermal
zone is disabled and restores it when it is enabled.

Signed-off-by: Anson Huang 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

thermal: exynos: fix setting rising_threshold for Exynos5433

2018-08-03T05:50:37+00:00

[ Upstream commit 8bfc218d0ebbabcba8ed2b8ec1831e0cf1f71629 ]

Add missing clearing of the previous value when setting rising
temperature threshold.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

thermal: bcm2835: Stop using printk format %pCr

2018-07-03T09:24:48+00:00

commit bd2a07f71a1e2e198f8a30cb551d9defe422d83d upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by printing the variable that already holds the clock rate.
Note that calling clk_get_rate() is safe here, as the code runs in task
context.

Link: http://lkml.kernel.org/r/1527845302-12159-3-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai 
To: Jonathan Corbet 
To: Michael Turquette 
To: Stephen Boyd 
To: Zhang Rui 
To: Eduardo Valentin 
To: Eric Anholt 
To: Stefan Wahren 
To: Greg Kroah-Hartman 
Cc: Sergey Senozhatsky 
Cc: Petr Mladek 
Cc: Linus Torvalds 
Cc: Steven Rostedt 
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 4.12+
Signed-off-by: Geert Uytterhoeven 
Acked-by: Stefan Wahren 
Signed-off-by: Petr Mladek 
Signed-off-by: Greg Kroah-Hartman

thermal: int3403_thermal: Fix NULL pointer deref on module load / probe

2018-06-20T19:02:47+00:00

[ Upstream commit 13b86f50eaaddaea4bdd2fe476fd12e6a0951add ]

Starting with kernel 4.17 thermal_cooling_device_register() will call the
get_max_state() op during register.

Since we deref priv->priv in int3403_get_max_state() this means we must
set priv->priv before calling thermal_cooling_device_register().

Signed-off-by: Hans de Goede 
Signed-off-by: Zhang Rui 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

thermal: exynos: Propagate error value from tmu_read()

2018-05-16T08:10:30+00:00

commit c8da6cdef57b459ac0fd5d9d348f8460a575ae90 upstream.

tmu_read() in case of Exynos4210 might return error for out of bound
values. Current code ignores such value, what leads to reporting critical
temperature value. Add proper error code propagation to exynos_get_temp()
function.

Signed-off-by: Marek Szyprowski 
CC: stable@vger.kernel.org # v4.6+
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

thermal: exynos: Reading temperature makes sense only when TMU is turned on

2018-05-16T08:10:30+00:00

commit 88fc6f73fddf64eb507b04f7b2bd01d7291db514 upstream.

When thermal sensor is not yet enabled, reading temperature might return
random value. This might even result in stopping system booting when such
temperature is higher than the critical value. Fix this by checking if TMU
has been actually enabled before reading the temperature.

This change fixes booting of Exynos4210-based board with TMU enabled (for
example Samsung Trats board), which was broken since v4.4 kernel release.

Signed-off-by: Marek Szyprowski 
Fixes: 9e4249b40340 ("thermal: exynos: Fix first temperature read after registering sensor")
CC: stable@vger.kernel.org # v4.6+
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

thermal: imx: Fix race condition in imx_thermal_probe()

2018-04-24T07:36:34+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")
Cc: 
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: Greg Kroah-Hartman

thermal: int3400_thermal: fix error handling in int3400_thermal_probe()

2018-04-12T10:32:21+00:00

[ Upstream commit 0be86969ae385c5c944286bd9f66068525de15ee ]

There are resources that are not dealocated on failure path
in int3400_thermal_probe().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Zhang Rui 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

thermal: power_allocator: fix one race condition issue for thermal_instances list

2018-04-12T10:32:12+00:00

[ Upstream commit a5de11d67dcd268b8d0beb73dc374de5e97f0caf ]

When invoking allow_maximum_power and traverse tz->thermal_instances,
we should grab thermal_zone_device->lock to avoid race condition. For
example, during the system reboot, if the mali GPU device implements
device shutdown callback and unregister GPU devfreq cooling device,
the deleted list head may be accessed to cause panic, as the following
log shows:

[   33.551070] c3 25 (kworker/3:0) Unable to handle kernel paging request at virtual address dead000000000070
[   33.566708] c3 25 (kworker/3:0) pgd = ffffffc0ed290000
[   33.572071] c3 25 (kworker/3:0) [dead000000000070] *pgd=00000001ed292003, *pud=00000001ed292003, *pmd=0000000000000000
[   33.581515] c3 25 (kworker/3:0) Internal error: Oops: 96000004 [#1] PREEMPT SMP
[   33.599761] c3 25 (kworker/3:0) CPU: 3 PID: 25 Comm: kworker/3:0 Not tainted 4.4.35+ #912
[   33.614137] c3 25 (kworker/3:0) Workqueue: events_freezable thermal_zone_device_check
[   33.620245] c3 25 (kworker/3:0) task: ffffffc0f32e4200 ti: ffffffc0f32f0000 task.ti: ffffffc0f32f0000
[   33.629466] c3 25 (kworker/3:0) PC is at power_allocator_throttle+0x7c8/0x8a4
[   33.636609] c3 25 (kworker/3:0) LR is at power_allocator_throttle+0x808/0x8a4
[   33.643742] c3 25 (kworker/3:0) pc : [] lr : [] pstate: 20000145
[   33.652874] c3 25 (kworker/3:0) sp : ffffffc0f32f3bb0
[   34.468519] c3 25 (kworker/3:0) Process kworker/3:0 (pid: 25, stack limit = 0xffffffc0f32f0020)
[   34.477220] c3 25 (kworker/3:0) Stack: (0xffffffc0f32f3bb0 to 0xffffffc0f32f4000)
[   34.819822] c3 25 (kworker/3:0) Call trace:
[   34.824021] c3 25 (kworker/3:0) Exception stack(0xffffffc0f32f39c0 to 0xffffffc0f32f3af0)
[   34.924993] c3 25 (kworker/3:0) [] power_allocator_throttle+0x7c8/0x8a4
[   34.933184] c3 25 (kworker/3:0) [] handle_thermal_trip.part.25+0x70/0x224
[   34.941545] c3 25 (kworker/3:0) [] thermal_zone_device_update+0xc0/0x20c
[   34.949818] c3 25 (kworker/3:0) [] thermal_zone_device_check+0x20/0x2c
[   34.957924] c3 25 (kworker/3:0) [] process_one_work+0x168/0x458
[   34.965414] c3 25 (kworker/3:0) [] worker_thread+0x13c/0x4b4
[   34.972650] c3 25 (kworker/3:0) [] kthread+0xe8/0xfc
[   34.979187] c3 25 (kworker/3:0) [] ret_from_fork+0x10/0x40
[   34.986244] c3 25 (kworker/3:0) Code: f9405e73 eb1302bf d102e273 54ffc460 (b9402a61)
[   34.994339] c3 25 (kworker/3:0) ---[ end trace 32057901e3b7e1db ]---

Signed-off-by: Yi Zeng 
Signed-off-by: Zhang Rui 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

thermal/drivers/hisi: Fix multiple alarm interrupts firing

2017-12-25T13:26:31+00:00

commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream.

The DT specifies a threshold of 65000, we setup the register with a value in
the temperature resolution for the controller, 64656.

When we reach 64656, the interrupt fires, the interrupt is disabled. Then the
irq thread runs and calls thermal_zone_device_update() which will call in turn
hisi_thermal_get_temp().

The function will look if the temperature decreased, assuming it was more than
65000, but that is not the case because the current temperature is 64656
(because of the rounding when setting the threshold). This condition being
true, we re-enable the interrupt which fires immediately after exiting the irq
thread. That happens again and again until the temperature goes to more than
65000.

Potentially, there is here an interrupt storm if the temperature stabilizes at
this temperature. A very unlikely case but possible.

In any case, it does not make sense to handle dozens of alarm interrupt for
nothing.

Fix this by rounding the threshold value to the controller resolution so the
check against the threshold is consistent with the one set in the controller.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Leo Yan 
Tested-by: Leo Yan 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Kevin Wangtao 
Signed-off-by: Greg Kroah-Hartman