kernel/drivers/thermal, branch linux-6.5.y

thermal: intel: powerclamp: fix mismatch in get function for max_idle

2023-11-28T17:15:05Z

commit fae633cfb729da2771b5433f6b84ae7e8b4aa5f7 upstream. KASAN reported this [ 444.853098] BUG: KASAN: global-out-of-bounds in param_get_int+0x77/0x90 [ 444.853111] Read of size 4 at addr ffffffffc16c9220 by task cat/2105 ... [ 444.853442] The buggy address belongs to the variable: [ 444.853443] max_idle+0x0/0xffffffffffffcde0 [intel_powerclamp] There is a mismatch between the param_get_int and the definition of max_idle. Replacing param_get_int with param_get_byte resolves this issue. Fixes: ebf519710218 ("thermal: intel: powerclamp: Add two module parameters") Cc: 6.3+ # 6.3+ Signed-off-by: David Arcari Reviewed-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: core: Don't update trip points inside the hysteresis range

2023-11-20T10:56:52Z

[ Upstream commit cf3986f8c01d355490d0ac6024391b989a9d1e9d ] When searching for the trip points that need to be set, the nearest higher trip point's temperature is used for the high trip, while the nearest lower trip point's temperature minus the hysteresis is used for the low trip. The issue with this logic is that when the current temperature is inside a trip point's hysteresis range, both high and low trips will come from the same trip point. As a consequence instability can still occur like this: * the temperature rises slightly and enters the hysteresis range of a trip point * polling happens and updates the trip points to the hysteresis range * the temperature falls slightly, exiting the hysteresis range, crossing the trip point and triggering an IRQ, the trip points are updated * repeat So even though the current hysteresis implementation prevents instability from happening due to IRQs triggering on the same temperature value, both ways, it doesn't prevent it from happening due to an IRQ on one way and polling on the other. To properly implement a hysteresis behavior, when inside the hysteresis range, don't update the trip points. This way, the previously set trip points will stay in effect, which will in a way remember the previous state (if the temperature signal came from above or below the range) and therefore have the right trip point already set. The exception is if there was no previous trip point set, in which case a previous state doesn't exist, and so it's sensible to allow the hysteresis range as trip points. The following logs show the current behavior when running on a real machine: [ 202.524658] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 40000 203.562817: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=36986 temp=37979 [ 203.562845] thermal thermal_zone0: new temperature boundaries: 37000 < x < 40000 204.176059: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=37979 temp=40028 [ 204.176089] thermal thermal_zone0: new temperature boundaries: 37000 < x < 100000 205.226813: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=40028 temp=38652 [ 205.226842] thermal thermal_zone0: new temperature boundaries: 37000 < x < 40000 And with this patch applied: [ 184.933415] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 40000 185.981182: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=36986 temp=37872 186.744685: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=37872 temp=40058 [ 186.744716] thermal thermal_zone0: new temperature boundaries: 37000 < x < 100000 187.773284: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=40058 temp=38698 Fixes: 060c034a9741 ("thermal: Add support for hardware-tracked trip points") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Co-developed-by: Rafael J. Wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal/drivers/mediatek: Fix probe for THERMAL_V2

2023-11-20T10:56:51Z

[ Upstream commit 5055fadfa7e16f2427d5b3c40b2bf563ddfdab22 ] Fix the probe function to call mtk_thermal_release_periodic_ts for everything != MTK_THERMAL_V1. This was accidentally changed from V1 to V2 in the original patch. Reported-by: Frank Wunderlich Closes: https://lore.kernel.org/lkml/B0B3775B-B8D1-4284-814F-4F41EC22F532@public-files.de/ Reported-by: Daniel Lezcano Closes: https://lore.kernel.org/lkml/07a569b9-e691-64ea-dd65-3b49842af33d@linaro.org/ Fixes: 33140e668b10 ("thermal/drivers/mediatek: Control buffer enablement tweaks") Signed-off-by: Markus Schneider-Pargmann Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230918100706.1229239-1-msp@baylibre.com Signed-off-by: Sasha Levin

thermal: core: prevent potential string overflow

2023-11-20T10:56:51Z

[ Upstream commit c99626092efca3061b387043d4a7399bf75fbdd5 ] The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow. Fixes: 203d3d4aa482 ("the generic thermal sysfs driver") Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: sysfs: Fix trip_point_hyst_store()

2023-10-06T11:16:27Z

commit ea3105672c68a5b6d7368504067220682ee6c65c upstream. After commit 2e38a2a981b2 ("thermal/core: Add a generic thermal_zone_set_trip() function") updating a trip point temperature doesn't actually work, because the value supplied by user space is subsequently overwritten with the current trip point hysteresis value. Fix this by changing the code to parse the number string supplied by user space after retrieving the current trip point data from the thermal zone. Also drop a redundant tab character from the code in question. Fixes: 2e38a2a981b2 ("thermal/core: Add a generic thermal_zone_set_trip() function") Signed-off-by: Rafael J. Wysocki Cc: 6.3+ # 6.3+ Signed-off-by: Greg Kroah-Hartman

thermal/of: add missing of_node_put()

2023-10-06T11:16:11Z

[ Upstream commit 8a81cf96f5510aaf9a65d103f7405079a7b0fcc5 ] for_each_child_of_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. This was done using the Coccinelle semantic patch iterators/for_each_child.cocci Signed-off-by: Julia Lawall Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal/drivers/imx8mm: Suppress log message on probe deferral

2023-09-13T07:53:47Z

[ Upstream commit 4afcb58ea47e66c025d2b0a5f091dce5aaf95b0f ] nvmem_cell_read_u32() may return -EPROBE_DEFER if NVMEM supplier has not yet been probed. Future reprobe may succeed, so printing: i.mx8mm_thermal 30260000.tmu: Failed to read OCOTP nvmem cell (-517). to the log is confusing. Fix this by using dev_err_probe. This also elevates the message from warning to error, which is more correct: The log message is only ever printed in probe error path and probe aborts afterwards, so it really warrants an error-level message. Fixes: 403291648823 ("thermal/drivers/imx: Add support for loading calibration data from OCOTP") Signed-off-by: Ahmad Fatoum Reviewed-by: Marek Vasut Reviewed-by: Peng Fan Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230708112647.2897294-1-a.fatoum@pengutronix.de Signed-off-by: Sasha Levin

thermal/drivers/mediatek/lvts_thermal: Manage threshold between sensors

2023-09-13T07:53:47Z

[ Upstream commit 2bba1acf7a4cbe62abbb4c686e0414209ec5943b ] Each LVTS thermal controller can have up to four sensors, each capable of triggering its own interrupt when its measured temperature crosses the configured threshold. The threshold for each sensor is handled separately by the thermal framework, since each one is registered with its own thermal zone and trips. However, the temperature thresholds are configured on the controller, and therefore are shared between all sensors on that controller. When the temperature measured by the sensors is different enough to cause the thermal framework to configure different thresholds for each one, interrupts start triggering on sensors outside the last threshold configured. To address the issue, track the thresholds required by each sensor and only actually set the highest one in the hardware, and disable interrupts for all sensors outside the current configured range. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Alexandre Mergnat Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230706153823.201943-7-nfraprado@collabora.com Signed-off-by: Sasha Levin

thermal/drivers/mediatek/lvts_thermal: Don't leave threshold zeroed

2023-09-13T07:53:47Z

[ Upstream commit 77354eaef8218bc40d6b37e783b0b8dcca22a7d9 ] The thermal framework might leave the low threshold unset if there aren't any lower trip points. This leaves the register zeroed, which translates to a very high temperature for the low threshold. The interrupt for this threshold is then immediately triggered, and the state machine gets stuck, preventing any other temperature monitoring interrupts to ever trigger. (The same happens by not setting the Cold or Hot to Normal thresholds when using those) Set the unused threshold to a valid low value. This value was chosen so that for any valid golden temperature read from the efuse, when the value is converted to raw and back again to milliCelsius, the result doesn't underflow. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Alexandre Mergnat Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230706153823.201943-6-nfraprado@collabora.com Signed-off-by: Sasha Levin

thermal/drivers/mediatek/lvts_thermal: Disable undesired interrupts

2023-09-13T07:53:47Z

[ Upstream commit 487bf099e85b724c824f5fafaf93c6749c4d2120 ] Out of the many interrupts supported by the hardware, the only ones of interest to the driver currently are: * The temperature went over the high offset threshold, for any of the sensors * The temperature went below the low offset threshold, for any of the sensors * The temperature went over the stage3 threshold These are the only thresholds configured by the driver through the OFFSETH, OFFSETL, and PROTTC registers, respectively. The current interrupt mask in LVTS_MONINT_CONF, enables many more interrupts, including data ready on sensors for both filtered and immediate mode. These are not only not handled by the driver, but they are also triggered too often, causing unneeded overhead. Disable these unnecessary interrupts. The meaning of each bit can be seen in the comment describing LVTS_MONINTST in the IRQ handler. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Alexandre Mergnat Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230706153823.201943-5-nfraprado@collabora.com Signed-off-by: Sasha Levin