linux-toradex.git/drivers/thermal, branch v4.9.100

thermal: exynos: Propagate error value from tmu_read()

2018-05-16T08:08:44+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:08:44+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:34:14+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: power_allocator: fix one race condition issue for thermal_instances list

2018-04-13T17:48:08+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: fix INTEL_SOC_DTS_IOSF_CORE dependencies

2018-02-25T10:05:52+00:00

commit 68fd77cf8a4b045594231f07e5fc92e1a34c0a9e upstream.

We get a Kconfig warning when selecting this without also enabling
CONFIG_PCI:

warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE
&& SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG)
selects IOSF_MBI which has unmet direct dependencies (PCI)

This adds a new depedency.

Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common APIs")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Srinivas Pandruvada 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

thermal/drivers/hisi: Fix multiple alarm interrupts firing

2017-12-25T13:23:46+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

thermal/drivers/hisi: Simplify the temperature/step computation

2017-12-25T13:23:46+00:00

commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream.

The step and the base temperature are fixed values, we can simplify the
computation by converting the base temperature to milli celsius and use a
pre-computed step value. That saves us a lot of mult + div for nothing at
runtime.

Take also the opportunity to change the function names to be consistent with
the rest of the code.

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

thermal/drivers/hisi: Fix kernel panic on alarm interrupt

2017-12-25T13:23:46+00:00

commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream.

The threaded interrupt for the alarm interrupt is requested before the
temperature controller is setup. This one can fire an interrupt immediately
leading to a kernel panic as the sensor data is not initialized.

In order to prevent that, move the threaded irq after the Tsensor is setup.

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

thermal/drivers/hisi: Fix missing interrupt enablement

2017-12-25T13:23:46+00:00

commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream.

The interrupt for the temperature threshold is not enabled at the end of the
probe function, enable it after the setup is complete.

On the other side, the irq_enabled is not correctly set as we are checking if
the interrupt is masked where 'yes' means irq_enabled=false.

	irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
				&data->irq_enabled);

As we are always enabling the interrupt, it is pointless to check if
the interrupt is masked or not, just set irq_enabled to 'true'.

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

thermal: hisilicon: Handle return value of clk_prepare_enable

2017-12-25T13:23:46+00:00

commit 919054fdfc8adf58c5512fe9872eb53ea0f5525d upstream.

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Kevin Wangtao 
Signed-off-by: Greg Kroah-Hartman