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

thermal: intel: int3400: clean up ODVP on probe failures

2026-09-14T11:29:20+00:00

[ Upstream commit d83dc9ce57a746a6dca28439bcc0575d26fa6986 ] evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues. Fixes: 006f006f1e5c ("thermal/int340x_thermal: Export OEM vendor variables") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015140.19300-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: intel: Fix dangling resources on thermal_throttle_online() failure

2026-07-24T14:03:19+00:00

[ Upstream commit b91d287fa7a1ba0727eed5823c6ee4924ee5fa31 ] The function thermal_throttle_add_dev() may fail and abort a CPU hotplug online operation. Since the failure occurs within the online callback, thermal_throttle_online(), the CPU hotplug framework does not invoke the corresponding offline callback. As a result, the hardware and software resources set up during the failed operation are not torn down. Since only thermal_throttle_add_dev() can fail, call it before setting up the rest of the resources. Fixes: f6656208f04e ("x86/mce/therm_throt: Optimize notifications of thermal throttle") Signed-off-by: Ricardo Neri Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-1-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: int340x: Fix sysfs group leak on DLVR registration failure

2026-03-04T12:20:56+00:00

[ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ] When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier. Add proper error unwinding to remove the FIVR group before returning failure. Signed-off-by: Kaushlendra Kumar Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR11MB8768.namprd11.prod.outlook.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: intel: x86_pkg_temp_thermal: Fix bogus trip temperature

2025-06-04T12:42:20+00:00

commit cf948c8e274e8b406e846cdf6cc48fe47f98cf57 upstream. The tj_max value obtained from the Intel TCC library are in Celsius, whereas the thermal subsystem operates in milli-Celsius. This discrepancy leads to incorrect trip temperature calculations. Fix bogus trip temperature by converting tj_max to milli-Celsius Unit. Fixes: 8ef0ca4a177d ("Merge back other thermal control material for 6.3.") Signed-off-by: Zhang Rui Reported-by: zhang ning Closes: https://lore.kernel.org/all/TY2PR01MB3786EF0FE24353026293F5ACCD97A@TY2PR01MB3786.jpnprd01.prod.outlook.com/ Tested-by: zhang ning Cc: 6.3+ # 6.3+ Link: https://patch.msgid.link/20250519070901.1031233-1-rui.zhang@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: int340x: Add NULL check for adev

2025-04-10T12:37:26+00:00

[ Upstream commit 2542a3f70e563a9e70e7ded314286535a3321bdb ] Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. Fixes: 77e337c6e23e ("Thermal: introduce INT3402 thermal driver") Signed-off-by: Chenyuan Yang Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20250313043611.1212116-1-chenyuan0y@gmail.com [ rjw: Subject edit, added Fixes: ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: int3400: Fix reading of current_uuid for active policy

2024-12-09T09:33:07+00:00

commit 7082503622986537f57bdb5ef23e69e70cfad881 upstream. When the current_uuid attribute is set to the active policy UUID, reading back the same attribute is returning "INVALID" instead of the active policy UUID on some platforms before Ice Lake. In platforms before Ice Lake, firmware provides a list of supported thermal policies. In this case, user space can select any of the supported thermal policies via a write to attribute "current_uuid". In commit c7ff29763989 ("thermal: int340x: Update OS policy capability handshake")', the OS policy handshake was updated to support Ice Lake and later platforms and it treated priv->current_uuid_index=0 as invalid. However, priv->current_uuid_index=0 is for the active policy, only priv->current_uuid_index=-1 is invalid. Fix this issue by updating the priv->current_uuid_index check. Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake") Signed-off-by: Srinivas Pandruvada Cc: 5.18+ # 5.18+ Link: https://patch.msgid.link/20241114200213.422303-1-srinivas.pandruvada@linux.intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

thermal: intel: int340x: processor: Add MMIO RAPL PL4 support

2024-11-08T15:28:21+00:00

[ Upstream commit 3fb0eea8a1c4be5884e0731ea76cbd3ce126e1f3 ] Similar to the MSR RAPL interface, MMIO RAPL supports PL4 too, so add MMIO RAPL PL4d support to the processor_thermal driver. As a result, the powercap sysfs for MMIO RAPL will show a new "peak power" constraint. Signed-off-by: Zhang Rui Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20240930081801.28502-7-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support

2024-11-08T15:28:21+00:00

[ Upstream commit bfc6819e4bf56a55df6178f93241b5845ad672eb ] CPU0/package0 is always online and the MMIO RAPL driver runs on single package systems only, so there is no need to handle CPU hotplug in it. Always register a RAPL package device for package 0 and remove the unnecessary CPU hotplug support. Signed-off-by: Zhang Rui Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20240930081801.28502-6-rui.zhang@intel.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: intel: int340x: processor: Fix warning during module unload

2024-10-17T13:24:24+00:00

[ Upstream commit 99ca0b57e49fb73624eede1c4396d9e3d10ccf14 ] The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. Fixes: acd65d5d1cf4 ("thermal/drivers/int340x/processor_thermal: Add PCI MMIO based thermal driver") Signed-off-by: Zhang Rui Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20240930081801.28502-3-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

thermal: int340x: processor_thermal: Set feature mask before proc_thermal_add

2024-10-17T13:24:24+00:00

[ Upstream commit 6ebc25d8b053a208786295bab58abbb66b39c318 ] The function proc_thermal_add() adds sysfs entries for power limits. The feature mask of available features is not present at that time, so it cannot be used by proc_thermal_add() to selectively create sysfs attributes. The feature mask is set by proc_thermal_mmio_add(), so modify the code to call it before proc_thermal_add() so as to allow the latter to use the feature mask. There is no functional impact with this change. Signed-off-by: Srinivas Pandruvada [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Stable-dep-of: 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload") Signed-off-by: Sasha Levin