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

thermal: cpu_cooling: Avoid accessing potentially freed structures

2017-07-27T22:06:02+00:00

commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream.

After the lock is dropped, it is possible that the cpufreq_dev gets
freed before we call get_level() and that can cause kernel to crash.

Drop the lock after we are done using the structure.

Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
Signed-off-by: Viresh Kumar 
Reviewed-by: Lukasz Luba 
Tested-by: Lukasz Luba 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

thermal: hwmon: Properly report critical temperature in sysfs

2017-01-09T07:07:44+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: Greg Kroah-Hartman

thermal: cpu_cooling: fix improper order during initialization

2016-07-27T16:47:29+00:00

commit f840ab18bdf2e415dac21d09fbbbd2873111bd48 upstream.

The freq_table array is not populated before calling
thermal_of_cooling_register. The code which populates the freq table was
introduced in commit f6859014.
This should be done before registering new thermal cooling device.
The log shows effects of this wrong decision.
[    2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34
[    2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34

Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
Signed-off-by: Lukasz Luba 
Acked-by: Javi Merino 
Acked-by: Viresh Kumar 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

thermal: rockchip: fix a impossible condition caused by the warning

2016-05-04T21:48:54+00:00

commit 43b4eb9fe719b107c8e5d49d1edbff0c135a42cb upstream.

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter 
Signed-off-by: Caesar Wang 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

Thermal: Ignore invalid trip points

2016-04-12T16:08:35+00:00

commit 81ad4276b505e987dd8ebbdf63605f92cd172b52 upstream.

In some cases, platform thermal driver may report invalid trip points,
thermal core should not take any action for these trip points.

This fixed a regression that bogus trip point starts to screw up thermal
control on some Lenovo laptops, after
commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
Author: Zhang Rui 
Date:   Fri Oct 30 16:31:47 2015 +0800

    Thermal: initialize thermal zone device correctly

    After thermal zone device registered, as we have not read any
    temperature before, thus tz->temperature should not be 0,
    which actually means 0C, and thermal trend is not available.
    In this case, we need specially handling for the first
    thermal_zone_device_update().

    Both thermal core framework and step_wise governor is
    enhanced to handle this. And since the step_wise governor
    is the only one that uses trends, so it's the only thermal
    governor that needs to be updated.

    Tested-by: Manuel Krause 
    Tested-by: szegad 
    Tested-by: prash 
    Tested-by: amish 
    Tested-by: Matthias 
    Reviewed-by: Javi Merino 
    Signed-off-by: Zhang Rui 
    Signed-off-by: Chen Yu 

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

thermal: cpu_cooling: fix out of bounds access in time_in_idle

2016-03-09T23:34:56+00:00

commit a53b8394ec3c67255928df6ee9cc99dd1cd452e3 upstream.

In __cpufreq_cooling_register() we allocate the arrays for time_in_idle
and time_in_idle_timestamp to be as big as the number of cpus in this
cpufreq device.  However, in get_load() we access this array using the
cpu number as index, which can result in an out of bound access.

Index time_in_idle{,_timestamp} using the index in the cpufreq_device's
allowed_cpus mask, as we do for the load_cpu array in
cpufreq_get_requested_power()

Reported-by: Nicolas Boichat 
Cc: Amit Daniel Kachhap 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Tested-by: Nicolas Boichat 
Acked-by: Viresh Kumar 
Signed-off-by: Javi Merino 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

Thermal: do thermal zone update after a cooling device registered

2016-03-03T23:07:25+00:00

commit 4511f7166a2deb5f7a578cf87fd2fe1ae83527e3 upstream.

When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.

This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.

Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/

Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu 
Signed-off-by: Greg Kroah-Hartman

Thermal: handle thermal zone device properly during system sleep

2016-03-03T23:07:25+00:00

commit ff140fea847e1c2002a220571ab106c2456ed252 upstream.

Current thermal code does not handle system sleep well because
1. the cooling device cooling state may be changed during suspend
2. the previous temperature reading becomes invalid after resumed because
   it is got before system sleep
3. updating thermal zone device during suspending/resuming
   is wrong because some devices may have already been suspended
   or may have not been resumed.

Thus, the proper way to do this is to cancel all thermal zone
device update requirements during suspend/resume, and after all
the devices have been resumed, reset and update every registered
thermal zone devices.

This also fixes a regression introduced by:
Commit 19593a1fb1f6 ("ACPI / fan: convert to platform driver")
Because, with above commit applied, all the fan devices are attached
to the acpi_general_pm_domain, and they are turned on by the pm_domain
automatically after resume, without the awareness of thermal core.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411
Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Tested-by: Matthias 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu 
Signed-off-by: Greg Kroah-Hartman

Thermal: initialize thermal zone device correctly

2016-03-03T23:07:25+00:00

commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 upstream.

After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().

Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.

Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Tested-by: Matthias 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu 
Signed-off-by: Greg Kroah-Hartman

imx: thermal: use CPU temperature grade info for thresholds

2015-11-24T00:38:40+00:00

The IMX6Q/IMX6DL SoC's have a 2-bit temperature grade stored in OTP which
is valid for all IMX6 SoC's (despite the fact that the IMXSDLRM and
IMXSXRM do not document this - this has been proven via tests as well as
verified by Freescale FAE).

Instead of assuming a fixed 85C for passive cooling threshold and 105C for
critical use the thermal grade for these configurations.

We will set the critical to maxT - 5C and passive to maxT - 10C.

Cc: Anson Huang 
Cc: Fabio Estevam 
Acked-by: Shawn Guo 
Acked-by: Jon Nettleton 
Signed-off-by: Tim Harvey 
----
v3:
 - rebase against linux-soc-thermal.git
 - added ack's from Shawn and Jon
v2:
 - remove check for IMX6Q and update comments: The OTP values have been tested
   on IMX6SOLO, IMX6DUALLITE, and IMX6SX and Freescale FAE has shared data with
   me that the OTP settings are the same and that the reference manuals will
   reflect this in their next updates.
 - set critical to max - 5C
 - set passive to max - 10C
 - display max temp in info
 - do not allow passive to be set above critical
Signed-off-by: Eduardo Valentin