BMC/Intel-BMC/linux.git/drivers/thermal, branch dev-5.15-intel

thermal: int340x: Check for NULL after calling kmemdup()

2022-04-08T12:23:05+00:00

[ Upstream commit 38b16d6cfe54c820848bcfc999bc5e8a7da1cefb ] As the potential failure of the allocation, kmemdup() may return NULL. Then, 'bin_attr_data_vault.private' will be NULL, but 'bin_attr_data_vault.size' is not 0, which is not consistent. Therefore, it is better to check the return value of kmemdup() to avoid the confusion. Fixes: 0ba13c763aac ("thermal/int340x_thermal: Export GDDV") Signed-off-by: Jiasheng Jiang [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: int340x: Increase bitmap size

2022-04-08T12:23:01+00:00

commit 668f69a5f863b877bc3ae129efe9a80b6f055141 upstream. The number of policies are 10, so can't be supported by the bitmap size of u8. Even though there are no platfoms with these many policies, but for correctness increase to u32. Signed-off-by: Srinivas Pandruvada Fixes: 16fc8eca1975 ("thermal/int340x_thermal: Add additional UUIDs") Cc: 5.1+ # 5.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: core: Fix TZ_GET_TRIP NULL pointer dereference

2022-03-08T18:12:43+00:00

commit 5838a14832d447990827d85e90afe17e6fb9c175 upstream. Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if the thermal zone does not define one. Fixes: 1ce50e7d408e ("thermal: core: genetlink support for events/cmd/sampling") Signed-off-by: Nicolas Cavallari Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: int340x: fix memory leak in int3400_notify()

2022-03-02T10:48:07+00:00

commit 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 upstream. It is easy to hit the below memory leaks in my TigerLake platform: unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [] __kmalloc_track_caller+0x2fe/0x4a0 [] kvasprintf+0x65/0xd0 [] kasprintf+0x4e/0x70 [] int3400_notify+0x82/0x120 [int3400_thermal] [] acpi_ev_notify_dispatch+0x54/0x71 [] acpi_os_execute_deferred+0x17/0x30 [] process_one_work+0x21a/0x3f0 [] worker_thread+0x4a/0x3b0 [] kthread+0xfd/0x130 [] ret_from_fork+0x1f/0x30 Fix it by calling kfree() accordingly. Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event") Signed-off-by: Chuansheng Liu Cc: 4.14+ # 4.14+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal/drivers/int340x: Fix RFIM mailbox write commands

2022-02-16T11:56:07+00:00

commit 2685c77b80a80c57e2a25a726b82fb31e6e212ab upstream. The existing mail mechanism only supports writing of workload types. However, mailbox command for RFIM (cmd = 0x08) also requires write operation which is ignored. This results in failing to store RFI restriction. Fixint this requires enhancing mailbox writes for non workload commands too, so remove the check for MBOX_CMD_WORKLOAD_TYPE_WRITE in mailbox write to allow this other write commands to be supoorted. At the same time, however, we have to make sure that there is no impact on read commands, by avoiding to write anything into the mailbox data register. To properly implement that, add two separate functions for mbox read and write commands for the processor thermal workload command type. This helps to distinguish the read and write workload command types from each other while sending mbox commands. Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Sumeet Pawnikar Cc: 5.14+ # 5.14+ Acked-by: Srinivas Pandruvada [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: int340x: Limit Kconfig to 64-bit

2022-02-16T11:56:07+00:00

commit 994a04a20b03128838ec0250a0e266aab24d23f1 upstream. 32-bit processors cannot generally access 64-bit MMIO registers atomically, and it is unknown in which order the two halves of this registers would need to be read: drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c: In function 'send_mbox_cmd': drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c:79:37: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration] 79 | *cmd_resp = readq((void __iomem *) (proc_priv->mmio_base + MBOX_OFFSET_DATA)); | ^~~~~ | readl The driver already does not build for anything other than x86, so limit it further to x86-64. Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") Signed-off-by: Arnd Bergmann Reviewed-by: Srinivas Pandruvada Reviewed-by: Randy Dunlap Signed-off-by: Rafael J. Wysocki Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman

thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses

2022-02-16T11:56:07+00:00

commit aeb58c860dc516794fdf7ff89d96ead2644d5889 upstream. Some of the RFIM mail box command returns 64 bit values. So enhance mailbox interface to return 64 bit values and use them for RFIM commands. Signed-off-by: Srinivas Pandruvada Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman

thermal/drivers/int340x: Improve the tcc offset saving for suspend/resume

2022-02-16T11:56:07+00:00

commit c4fcf1ada4ae63e0aab6afd19ca2e7d16833302c upstream. When the driver resumes, the tcc offset is set back to its previous value. But this only works if the value was user defined as otherwise the offset isn't saved. This asymmetric logic is harder to maintain and introduced some issues. Improve the logic by saving the tcc offset in a suspend op, so the right value is always restored after a resume. Signed-off-by: Antoine Tenart Reviewed-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210909085613.5577-3-atenart@kernel.org Signed-off-by: Daniel Lezcano Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman

thermal/drivers/imx8mm: Enable ADC when enabling monitor

2022-01-27T10:03:23+00:00

[ Upstream commit 3de89d8842a2b5d3dd22ebf97dd561ae0a330948 ] The i.MX 8MP has a ADC_PD bit in the TMU_TER register that controls the operating mode of the ADC: * 0 means normal operating mode * 1 means power down mode When enabling/disabling the TMU, the ADC operating mode must be set accordingly. i.MX 8M Mini & Nano are lacking this bit. Signed-off-by: Paul Gerber Signed-off-by: Alexander Stein Fixes: 2b8f1f0337c5 ("thermal: imx8mm: Add i.MX8MP support") Link: https://lore.kernel.org/r/20211122114225.196280-1-alexander.stein@ew.tq-group.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin

thermal/drivers/imx: Implement runtime PM support

2022-01-27T10:03:21+00:00

[ Upstream commit 4cf2ddf16e175ee18c5c29865c32da7d6269cf44 ] Starting with commit d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement") this driver stared using irq_enabled flag to make decision to power on/off the thermal core. This triggered a regression, where after reaching critical temperature, alarm IRQ handler set irq_enabled to false, disabled thermal core and was not able read temperature and disable cooling sequence. In case the cooling device is "CPU/GPU freq", the system will run with reduce performance until next reboot. To solve this issue, we need to move all parts implementing hand made runtime power management and let it handle actual runtime PM framework. Fixes: d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement") Signed-off-by: Oleksij Rempel Tested-by: Petr Beneš Link: https://lore.kernel.org/r/20211117103426.81813-1-o.rempel@pengutronix.de Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin