kernel/git/stable/linux.git/drivers/thermal, branch linux-5.12.y

thermal/drivers/rcar_gen3_thermal: Fix coefficient calculations

2021-07-20T14:02:26+00:00

[ Upstream commit 8946187ab57ffd02088e50256c73dd31f49db06d ] The fixed value of 157 used in the calculations are only correct for M3-W, on other Gen3 SoC it should be 167. The constant can be derived correctly from the static TJ_3 constant and the SoC specific TJ_1 value. Update the calculation be correct on all Gen3 SoCs. Fixes: 4eb39f79ef44 ("thermal: rcar_gen3_thermal: Update value of Tj_1") Reported-by: Yoshihiro Shimoda Signed-off-by: Niklas Söderlund Reviewed-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210605085211.564909-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin

thermal/drivers/sprd: Add missing MODULE_DEVICE_TABLE

2021-07-20T14:02:26+00:00

[ Upstream commit 4d57fd9aeaa013a245bf1fade81e2c30a5efd491 ] MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Fixes: 554fdbaf19b18 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Chunyan Zhang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210512093752.243168-1-zhang.lyra@gmail.com Signed-off-by: Sasha Levin

thermal/drivers/int340x/processor_thermal: Fix tcc setting

2021-07-19T08:01:21+00:00

commit fe6a6de6692e7f7159c1ff42b07ecd737df712b4 upstream. The following fixes are done for tcc sysfs interface: - TCC is 6 bits only from bit 29-24 - TCC of 0 is valid - When BIT(31) is set, this register is read only - Check for invalid tcc value - Error for negative values Fixes: fdf4f2fb8e899 ("drivers: thermal: processor_thermal_device: Export sysfs interface for TCC offset") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Acked-by: Zhang Rui Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210628215803.75038-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Greg Kroah-Hartman

thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure

2021-07-14T14:59:14+00:00

[ Upstream commit 2ad8ccc17d1e4270cf65a3f2a07a7534aa23e3fb ] The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available. Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when thermal framework sets capping. Fixes: f12e4f66ab6a3 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Lukasz Luba Signed-off-by: Peter Zijlstra (Intel) Acked-by: Viresh Kumar Link: https://lore.kernel.org/r/20210614191030.22241-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin

x86/thermal: Fix LVT thermal setup for SMI delivery mode

2021-06-10T11:41:47+00:00

commit 9a90ed065a155d13db0d0ffeaad5cc54e51c90c6 upstream. There are machines out there with added value crap^WBIOS which provide an SMI handler for the local APIC thermal sensor interrupt. Out of reset, the BSP on those machines has something like 0x200 in that APIC register (timestamps left in because this whole issue is timing sensitive): [ 0.033858] read lvtthmr: 0x330, val: 0x200 which means: - bit 16 - the interrupt mask bit is clear and thus that interrupt is enabled - bits [10:8] have 010b which means SMI delivery mode. Now, later during boot, when the kernel programs the local APIC, it soft-disables it temporarily through the spurious vector register: setup_local_APIC: ... /* * If this comes from kexec/kcrash the APIC might be enabled in * SPIV. Soft disable it before doing further initialization. */ value = apic_read(APIC_SPIV); value &= ~APIC_SPIV_APIC_ENABLED; apic_write(APIC_SPIV, value); which means (from the SDM): "10.4.7.2 Local APIC State After It Has Been Software Disabled ... * The mask bits for all the LVT entries are set. Attempts to reset these bits will be ignored." And this happens too: [ 0.124111] APIC: Switch to symmetric I/O mode setup [ 0.124117] lvtthmr 0x200 before write 0xf to APIC 0xf0 [ 0.124118] lvtthmr 0x10200 after write 0xf to APIC 0xf0 This results in CPU 0 soft lockups depending on the placement in time when the APIC soft-disable happens. Those soft lockups are not 100% reproducible and the reason for that can only be speculated as no one tells you what SMM does. Likely, it confuses the SMM code that the APIC is disabled and the thermal interrupt doesn't doesn't fire at all, leading to CPU 0 stuck in SMM forever... Now, before 4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()") due to how the APIC_LVTTHMR was read before APIC initialization in mcheck_intel_therm_init(), it would read the value with the mask bit 16 clear and then intel_init_thermal() would replicate it onto the APs and all would be peachy - the thermal interrupt would remain enabled. But that commit moved that reading to a later moment in intel_init_thermal(), resulting in reading APIC_LVTTHMR on the BSP too late and with its interrupt mask bit set. Thus, revert back to the old behavior of reading the thermal LVT register before the APIC gets initialized. Fixes: 4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()") Reported-by: James Feeney Signed-off-by: Borislav Petkov Cc: Cc: Zhang Rui Cc: Srinivas Pandruvada Link: https://lkml.kernel.org/r/YKIqDdFNaXYd39wz@zn.tnic Signed-off-by: Greg Kroah-Hartman

thermal/drivers/qcom: Fix error code in adc_tm5_get_dt_channel_data()

2021-06-03T07:09:51+00:00

[ Upstream commit 5d8db38ad7660e4d78f4e2a63f14336f31f07a63 ] Return -EINVAL when args is invalid instead of 'ret' which is set to zero by a previous successful call to a function. Fixes: ca66dca5eda6 ("thermal: qcom: add support for adc-tm5 PMIC thermal monitor") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210527092640.2070555-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin

thermal/drivers/intel: Initialize RW trip to THERMAL_TEMP_INVALID

2021-06-03T07:09:32+00:00

commit eb8500b874cf295971a6a2a04e14eb0854197a3c upstream. After commit 81ad4276b505 ("Thermal: Ignore invalid trip points") all user_space governor notifications via RW trip point is broken in intel thermal drivers. This commits marks trip_points with value of 0 during call to thermal_zone_device_register() as invalid. RW trip points can be 0 as user space will set the correct trip temperature later. During driver init, x86_package_temp and all int340x drivers sets RW trip temperature as 0. This results in all these trips marked as invalid by the thermal core. To fix this initialize RW trips to THERMAL_TEMP_INVALID instead of 0. Cc: Signed-off-by: Srinivas Pandruvada Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210430122343.1789899-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Greg Kroah-Hartman

thermal/drivers/tsens: Fix missing put_device error

2021-05-19T08:56:24+00:00

[ Upstream commit f4136863e8899fa0554343201b78b9e197c78a78 ] Fixes coccicheck error: drivers/thermal/qcom/tsens.c:759:4-10: ERROR: missing put_device; call of_find_device_by_node on line 715, but without a corresponding object release within this function. Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into tsens.c") Signed-off-by: Guangqing Zhu Reviewed-by: Bjorn Andersson Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210404125431.12208-1-zhuguangqing83@gmail.com Signed-off-by: Sasha Levin

thermal: thermal_of: Fix error return code of thermal_of_populate_bind_params()

2021-05-19T08:56:21+00:00

[ Upstream commit 45c7eaeb29d67224db4ba935deb575586a1fda09 ] When kcalloc() returns NULL to __tcbp or of_count_phandle_with_args() returns zero or -ENOENT to count, no error return code of thermal_of_populate_bind_params() is assigned. To fix these bugs, ret is assigned with -ENOMEM and -ENOENT in these cases, respectively. Fixes: a92bab8919e3 ("of: thermal: Allow multiple devices to share cooling map") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210310122423.3266-1-baijiaju1990@gmail.com Signed-off-by: Sasha Levin

thermal/core/fair share: Lock the thermal zone while looping over instances

2021-05-12T06:40:04+00:00

commit fef05776eb02238dcad8d5514e666a42572c3f32 upstream. The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Lukasz Luba Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.com Signed-off-by: Greg Kroah-Hartman