summaryrefslogtreecommitdiff
path: root/drivers/thermal/intel/int340x_thermal
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2023-08-10 21:16:14 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2023-08-11 18:44:45 +0200
commit02a49aaceff4a229d775b82ccaaafe59fe16b8f5 (patch)
tree087d4d2811619806296e956bb5a6a82594075ce0 /drivers/thermal/intel/int340x_thermal
parent5bc3da35d7ad35e61d2b902f0fdc9b530bed3d89 (diff)
thermal: intel: intel_soc_dts_iosf: Rework critical trip setup
Critical trip points appear in the DTS thermal zones only after those thermal zones have been registered via intel_soc_dts_iosf_init(). Moreover, they are "created" by changing the type of an existing trip point from THERMAL_TRIP_PASSIVE to THERMAL_TRIP_CRITICAL via intel_soc_dts_iosf_add_read_only_critical_trip(), the caller of which has to be careful enough to pass at least 1 as the number of read-only trip points to intel_soc_dts_iosf_init() beforehand. This is questionable, because user space may have started to use the trips at the time when intel_soc_dts_iosf_add_read_only_critical_trip() runs and there is no synchronization between it and sys_set_trip_temp(). To address it, use the observation that nonzero number of read-only trip points is only passed to intel_soc_dts_iosf_init() when critical trip points are going to be used, so in fact that function may get all of the information regarding the critical trip points upfront and it can configure them before registering the corresponding thermal zones. Accordingly, replace the read_only_trip_count argument of intel_soc_dts_iosf_init() with a pair of new arguments related to critical trip points: a bool one indicating whether or not critical trip points are to be used at all and an int one representing the critical trip point temperature offset relative to Tj_max. Use these arguments to configure the critical trip points before the registration of the thermal zones and to compute the number of writeable trip points in add_dts_thermal_zone(). Modify both callers of intel_soc_dts_iosf_init() to take these changes into account and drop the intel_soc_dts_iosf_add_read_only_critical_trip() call, that is not necessary any more, from intel_soc_thermal_init(), which also allows it to return success right after requesting the IRQ. Finally, drop intel_soc_dts_iosf_add_read_only_critical_trip() altogether, because it does not have any more users. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Diffstat (limited to 'drivers/thermal/intel/int340x_thermal')
-rw-r--r--drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci_legacy.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci_legacy.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci_legacy.c
index 46ec0e243692..16fd9df5f36d 100644
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci_legacy.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci_legacy.c
@@ -59,7 +59,7 @@ static int proc_thermal_pci_probe(struct pci_dev *pdev,
* ACPI/MSR. So we don't want to fail for auxiliary DTSs.
*/
proc_priv->soc_dts = intel_soc_dts_iosf_init(
- INTEL_SOC_DTS_INTERRUPT_MSI, 0);
+ INTEL_SOC_DTS_INTERRUPT_MSI, false, 0);
if (!IS_ERR(proc_priv->soc_dts) && pdev->irq) {
ret = pci_enable_msi(pdev);