kernel/linux.git/drivers/thermal, branch v4.8.16

thermal/powerclamp: add back module device table

2016-12-02T08:10:32+00:00

commit ec638db8cb9ddd5ca08b23f2835b6c9c15eb616d upstream. Commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 replaced module cpu id table with a cpu feature check, which is logically correct. But we need the module device table to allow module auto loading. Fixes:3105f234 thermal/powerclamp: correct cpu support check Signed-off-by: Jacob Pan Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman

thermal/powerclamp: correct cpu support check

2016-11-10T15:38:46+00:00

commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream. Initial logic for checking CPU match resulted in OR of CPU features rather than the intended AND. Updated to use boot_cpu_has macro rather than x86_match_cpu. In addition, MWAIT is the only required CPU feature for idle injection to work. Drop other feature requirements since they are only needed for optimal efficiency. Signed-off-by: Eric Ernst Acked-by: Jacob Pan Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman

thermal: rcar_thermal: Fix priv->zone error handling

2016-09-06T12:46:06+00:00

In case thermal_zone_xxx_register() returns an error, priv->zone isn't NULL any more, but contains the error code. This is passed to thermal_zone_device_unregister(), then. This checks for priv->zone being NULL, but the error code is != NULL. So it works with the error code as a pointer. Crashing immediately. To fix this, reset priv->zone to NULL before entering rcar_gen3_thermal_remove(). Signed-off-by: Dirk Behme Reviewed-by: Geert Uytterhoeven Signed-off-by: Zhang Rui

thermal: imx: fix a possible NULL dereference

2016-08-19T13:34:08+00:00

of_match_device could return NULL, and so cause a NULL pointer dereference later at line 472: data->socdata = of_id->data; For fixing this problem, we use of_device_get_match_data(), this will simplify the code a little by using a standard function for getting the match data. Reported-by: coverity (CID 1324128) Signed-off-by: LABBE Corentin Signed-off-by: Zhang Rui

Thermal-INT3406: Delete owner assignment

2016-08-19T13:32:48+00:00

The field "owner" is set by core. Thus delete an extra initialisation. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Markus Elfring Signed-off-by: Zhang Rui

thermal: cpu_cooling: Fix NULL dereference in cpufreq_state2power

2016-08-19T13:32:18+00:00

Currently all CPU cooling devices share a `struct thermal_cooling_device_ops` instance. The thermal core uses the presence of functions in this struct to determine if a cooling device has a power model (see cdev_is_power_actor). cpu_cooling.c adds the power model functions to the shared struct when a device is registered with a power model. Therefore, if a CPU cooling device is registered using [of_]cpufreq_power_cooling_register, _all_ devices will be determined to have a power model, including any registered with [of_]cpufreq_cooling_register. This can result in cpufreq_state2power being called on a device where dyn_power_table is NULL. With this commit, instead of having a shared thermal_cooling_device_ops which is mutated, we have two versions: one with the power functions and one without. Signed-off-by: Brendan Jackman Cc: Amit Daniel Kachhap Cc: Viresh Kumar Cc: Javi Merino Acked-by: Viresh Kumar Acked-by: Javi Merino Signed-off-by: Zhang Rui

Merge branches 'thermal-intel' and 'thermal-core' into next

2016-08-08T02:59:35+00:00

thermal: clock_cooling: Fix missing mutex_init()

2016-08-08T02:57:39+00:00

The driver allocates the mutex but not initialize it. Use mutex_init() on it to initialize it correctly. This is detected by Coccinelle semantic patch. Signed-off-by: Wei Yongjun Signed-off-by: Zhang Rui

thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

2016-08-08T02:57:39+00:00

thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR >> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined! >> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined! Signed-off-by: Kuninori Morimoto Signed-off-by: Zhang Rui

thermal: fix race condition when updating cooling device

2016-08-08T02:57:39+00:00

When multiple thermal zones are bound to the same cooling device, multiple kernel threads may want to update the cooling device state by calling thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race condition. Consider the following situation with two kernel threads k1 and k2: Thread k1 Thread k2 || || call thermal_cdev_update() || ... || set_cur_state(cdev, target); call power_actor_set_power() || ... || instance->target = state; || cdev->updated = false; || || cdev->updated = true; || // completes execution call thermal_cdev_update() || // cdev->updated == true || return; || \/ time k2 has already looped through the thermal instances looking for the deepest cooling device state and is preempted right before setting cdev->updated to true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated to false. Then, k1 is preempted and k2 continues the execution by setting cdev->updated to true, therefore preventing k1 from performing the update. Notice that this is not an issue if k2 looks at the instance->target modified by k1 "after" it is assigned by k1. In fact, in this case the update will happen anyway and k1 can safely return immediately from thermal_cdev_update(). This may lead to a situation where a thermal governor never updates the cooling device. For example, this is the case for the step_wise governor: when calling the function thermal_zone_trip_update(), the governor may always get a new state equal to the old one (which, however, wasn't notified to the cooling device) and will therefore skip the update. CC: Zhang Rui CC: Eduardo Valentin CC: Peter Feuerer Reported-by: Toby Huang Signed-off-by: Michele Di Giorgio Reviewed-by: Javi Merino Signed-off-by: Zhang Rui