[PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

Recently sent as a RFC, the thermal ACPI for generic trip points is a set of
functions to fill the generic trip points structure which will become the
standard structure for the thermal framework and its users.

Different Intel drivers and the ACPI thermal driver are using the ACPI tables to
get the thermal zone information. As those are getting the same information,
providing this set of ACPI function with the generic trip points will
consolidate the code.

Also, the Intel PCH and the Intel 34xx drivers are converted to use the generic
trip points relying on the ACPI generic trip point parsing functions.

These changes have been tested on a Thinkpad Lenovo x280 with the PCH and
INT34xx drivers. No regression have been observed, the trip points remain the
same for what is described on this system.

Changelog:
 - V5:
   - Fixed GTSH unit conversion, deciK -> milli C

 - V4:
   - Fixed Kconfig option dependency, select THERMAL_ACPI if ACPI is set
     only for the PCH driver

 - V3:
   - Took into account Rafael's comments
   - Used a silence option THERMAL_ACPI in order to stay consistent
     with THERMAL_OF. It is up to the API user to select the option.

 - V2:
   - Fix the thermal ACPI patch where the thermal_acpi.c was not included in
     the series
   - Provide a couple of users of this API which could have been tested on a
     real system

Daniel Lezcano (3):
  thermal/acpi: Add ACPI trip point routines
  thermal/drivers/intel: Use generic trip points for intel_pch
  thermal/drivers/intel: Use generic trip points int340x

 drivers/thermal/Kconfig                       |   4 +
 drivers/thermal/Makefile                      |   1 +
 drivers/thermal/intel/Kconfig                 |   1 +
 drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
 .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++-----------
 .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
 drivers/thermal/intel/intel_pch_thermal.c     |  88 ++------
 drivers/thermal/thermal_acpi.c                | 210 ++++++++++++++++++
 include/linux/thermal.h                       |   8 +
 9 files changed, 286 insertions(+), 214 deletions(-)
 create mode 100644 drivers/thermal/thermal_acpi.c

-- 
2.34.1

[PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Daniel Lezcano]

The ACPI specification describes the trip points, the device tree
bindings as well.

The OF code uses the generic trip point structures.

The ACPI has their own trip points structure and uses the get_trip_*
ops to retrieve them.

We can do the same as the OF code and create a set of ACPI functions
to retrieve a trip point description. Having a common code for ACPI
will help to cleanup the remaining Intel drivers and get rid of the
get_trip_* functions.

These changes add the ACPI thermal calls to retrieve the basic
information we need to be reused in the thermal ACPI and Intel
drivers.

The different ACPI functions have the generic trip point structure
passed as parameter where it is filled.

This structure aims to be the one used by all the thermal drivers and
the thermal framework.

After this series, a couple of Intel drivers and the ACPI thermal
driver will still have their own trip points definition but a new
series on top of this one will finish the conversion to the generic
trip point handling.

This series depends on the generic trip point added to the thermal
framework and available in the thermal/linux-next branch.

 https://lkml.org/lkml/2022/10/3/456

It has been tested on a Intel i7-8650U - x280 with the INT3400, the
PCH, ACPITZ, and x86_pkg_temp. No regression observed so far.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/thermal/Kconfig        |   4 +
 drivers/thermal/Makefile       |   1 +
 drivers/thermal/thermal_acpi.c | 209 +++++++++++++++++++++++++++++++++
 include/linux/thermal.h        |   8 ++
 4 files changed, 222 insertions(+)
 create mode 100644 drivers/thermal/thermal_acpi.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e052dae614eb..eaeb2b2ee6e9 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -76,6 +76,10 @@ config THERMAL_OF
 	  Say 'Y' here if you need to build thermal infrastructure
 	  based on device tree.
 
+config THERMAL_ACPI
+       depends on ACPI
+       bool
+
 config THERMAL_WRITABLE_TRIPS
 	bool "Enable writable trip points"
 	help
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 2506c6c8ca83..60f0dfa9aae2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -13,6 +13,7 @@ thermal_sys-$(CONFIG_THERMAL_NETLINK)		+= thermal_netlink.o
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
 thermal_sys-$(CONFIG_THERMAL_OF)		+= thermal_of.o
+thermal_sys-$(CONFIG_THERMAL_ACPI)		+= thermal_acpi.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= gov_fair_share.o
diff --git a/drivers/thermal/thermal_acpi.c b/drivers/thermal/thermal_acpi.c
new file mode 100644
index 000000000000..ef6f10713650
--- /dev/null
+++ b/drivers/thermal/thermal_acpi.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2022 Linaro Limited
+ *
+ * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
+ *
+ * ACPI thermal configuration
+ */
+#include <linux/acpi.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/units.h>
+#include <uapi/linux/thermal.h>
+
+#include "thermal_core.h"
+
+/*
+ * An hysteresis value below zero is invalid and we can consider a
+ * value greater than 20°K/°C is invalid too.
+ */
+#define HYSTERESIS_MIN_DECIK	0
+#define HYSTERESIS_MAX_DECIK	200
+
+/*
+ * Minimum temperature for full military grade is 218°K (-55°C) and
+ * max temperature is 448°K (175°C). We can consider those values as
+ * the boundaries for the [trips] temperature returned by the
+ * firmware. Any values out of these boundaries can be considered
+ * bogus and we can assume the firmware has no data to provide.
+ */
+#define TEMPERATURE_MIN_DECIK	2180
+#define TEMPERATURE_MAX_DECIK	4480
+
+static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
+					       char *object, int *temperature)
+{
+	unsigned long long temp;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(adev->handle, object, NULL, &temp);
+	if (ACPI_FAILURE(status)) {
+		acpi_handle_debug(adev->handle, "No temperature object '%s'\n", object);
+		return -ENODEV;
+	}
+
+	if (temp < TEMPERATURE_MIN_DECIK || temp >= TEMPERATURE_MAX_DECIK) {
+		acpi_handle_info(adev->handle, "Invalid temperature '%llu deci°K' for object '%s'\n",
+				 temp, object);
+		return -ENODATA;
+	}
+
+	*temperature = deci_kelvin_to_millicelsius(temp);
+
+	return 0;
+}
+
+/**
+ * thermal_acpi_trip_gtsh() - Get the global hysteresis value
+ * @adev: the acpi device to get the description from
+ *
+ * Get the global hysteresis value for the trip points. If any call
+ * fail, we shall return a zero hysteresis value.
+ *
+ * Return: An integer between %HYSTERESIS_MIN_DECIK and %HYSTERESIS_MAX_DECIK
+ */
+int thermal_acpi_trip_gtsh(struct acpi_device *adev)
+{
+	unsigned long long hyst;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(adev->handle, "GTSH", NULL, &hyst);
+	if (ACPI_FAILURE(status))
+		return 0;
+
+	if (hyst < HYSTERESIS_MIN_DECIK || hyst >= HYSTERESIS_MAX_DECIK) {
+		acpi_handle_info(adev->handle, "Invalid hysteresis '%llu deci°K' for object 'GTSH'\n",
+				 hyst);
+		return 0;
+	}
+
+	return deci_kelvin_to_millicelsius(hyst);
+}
+EXPORT_SYMBOL_GPL(thermal_acpi_trip_gtsh);
+
+/**
+ * thermal_acpi_trip_act() - Get the specified active trip point
+ * @adev: the acpi device to get the description from
+ * @trip: a &struct thermal_trip to be filled if the function succeed
+ * @id: an integer speciyfing the active trip point id
+ *
+ * The function calls the ACPI framework to get the "_ACTx" objects
+ * which describe the active trip points. The @id builds the "_ACTx"
+ * string with the numbered active trip point name. Then it fills the
+ * @trip structure with the information retrieved from those objects.
+ *
+ * Return:
+ * * 0 - Success
+ * * -ENODEV - Failed to retrieve the ACPI object
+ * * -ENODATA - The ACPI object value appears to be inconsistent
+ */
+int thermal_acpi_trip_act(struct acpi_device *adev,
+			  struct thermal_trip *trip, int id)
+{
+	char name[5];
+	int ret;
+
+	sprintf(name, "_AC%d", id);
+
+	ret = thermal_acpi_get_temperature_object(adev, name, &trip->temperature);
+	if (ret)
+		return ret;
+
+	trip->hysteresis = 0;
+	trip->type = THERMAL_TRIP_ACTIVE;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_acpi_trip_act);
+
+/**
+ * thermal_acpi_trip_psv() - Get the passive trip point
+ * @adev: the acpi device to get the description from
+ * @trip: a &struct thermal_trip to be filled if the function succeed
+ *
+ * The function calls the ACPI framework to get the "_PSV" object
+ * which describe the passive trip point. Then it fills the @trip
+ * structure with the information retrieved from those objects.
+ *
+ * Return:
+ * * 0 - Success
+ * * -ENODEV - Failed to retrieve the ACPI object
+ * * -ENODATA - The ACPI object value appears to be inconsistent
+ */
+int thermal_acpi_trip_psv(struct acpi_device *adev, struct thermal_trip *trip)
+{
+	int ret;
+
+	ret = thermal_acpi_get_temperature_object(adev, "_PSV", &trip->temperature);
+	if (ret)
+		return ret;
+
+	trip->hysteresis = 0;
+	trip->type = THERMAL_TRIP_PASSIVE;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_acpi_trip_psv);
+
+/**
+ * thermal_acpi_trip_hot() - Get the near critical trip point
+ * @adev: the acpi device to get the description from
+ * @trip: a &struct thermal_trip to be filled if the function succeed
+ *
+ * The function calls the ACPI framework to get the "_HOT" object
+ * which describe the hot trip point. Then it fills the @trip
+ * structure with the information retrieved from those objects.
+ *
+ * Return:
+ * * 0 - Success
+ * * -ENODEV - Failed to retrieve the ACPI object
+ * * -ENODATA - The ACPI object appears to be inconsistent
+ */
+int thermal_acpi_trip_hot(struct acpi_device *adev, struct thermal_trip *trip)
+{
+	int ret;
+
+	ret = thermal_acpi_get_temperature_object(adev, "_HOT", &trip->temperature);
+	if (ret)
+		return ret;
+
+	trip->hysteresis = 0;
+	trip->type = THERMAL_TRIP_HOT;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_acpi_trip_hot);
+
+/**
+ * thermal_acpi_trip_crit() - Get the critical trip point
+ * @adev: the acpi device to get the description from
+ * @trip: a &struct thermal_trip to be filled if the function succeed
+ *
+ * The function calls the ACPI framework to get the "_CRT" object
+ * which describe the critical trip point. Then it fills the @trip
+ * structure with the information retrieved from this object.
+ *
+ * Return:
+ * * 0 - Success
+ * * -ENODEV - Failed to retrieve the ACPI object
+ * * -ENODATA - The ACPI object value appears to be inconsistent
+ */
+int thermal_acpi_trip_crit(struct acpi_device *adev, struct thermal_trip *trip)
+{
+	int ret;
+
+	ret = thermal_acpi_get_temperature_object(adev, "_CRT", &trip->temperature);
+	if (ret)
+		return ret;
+
+	/*
+	 * The hysteresis value has no sense here because critical
+	 * trip point has no u-turn
+	 */
+	trip->hysteresis = 0;
+	trip->type = THERMAL_TRIP_CRITICAL;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_acpi_trip_crit);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 30353e4b1424..ba2d5d4c23e2 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -334,6 +334,14 @@ static inline void devm_thermal_of_zone_unregister(struct device *dev,
 }
 #endif
 
+#ifdef CONFIG_THERMAL_ACPI
+int thermal_acpi_trip_gtsh(struct acpi_device *adev);
+int thermal_acpi_trip_crit(struct acpi_device *adev, struct thermal_trip *trip);
+int thermal_acpi_trip_hot(struct acpi_device *adev, struct thermal_trip *trip);
+int thermal_acpi_trip_psv(struct acpi_device *adev, struct thermal_trip *trip);
+int thermal_acpi_trip_act(struct acpi_device *adev, struct thermal_trip *trip, int id);
+#endif
+
 int __thermal_zone_get_trip(struct thermal_zone_device *tz, int trip_id,
 			    struct thermal_trip *trip);
 int thermal_zone_get_trip(struct thermal_zone_device *tz, int trip_id,
-- 
2.34.1

[PATCH v5 2/3] thermal/drivers/intel: Use generic trip points for intel_pch

[Daniel Lezcano]

The thermal framework gives the possibility to register the trip
points with the thermal zone. When that is done, no get_trip_* ops are
needed and they can be removed.

Convert the ops content logic into generic trip points and register
them with the thermal zone.

In order to consolidate the code, use the ACPI thermal framework API
to fill the generic trip point from the ACPI tables.

It has been tested on a Intel i7-8650U - x280 with the INT3400, the
PCH, ACPITZ, and x86_pkg_temp. No regression observed so far.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/thermal/intel/Kconfig             |  1 +
 drivers/thermal/intel/intel_pch_thermal.c | 88 +++++------------------
 2 files changed, 20 insertions(+), 69 deletions(-)

diff --git a/drivers/thermal/intel/Kconfig b/drivers/thermal/intel/Kconfig
index f0c845679250..7d68c076c23d 100644
--- a/drivers/thermal/intel/Kconfig
+++ b/drivers/thermal/intel/Kconfig
@@ -75,6 +75,7 @@ config INTEL_BXT_PMIC_THERMAL
 config INTEL_PCH_THERMAL
 	tristate "Intel PCH Thermal Reporting Driver"
 	depends on X86 && PCI
+	select THERMAL_ACPI if ACPI
 	help
 	  Enable this to support thermal reporting on certain intel PCHs.
 	  Thermal reporting device will provide temperature reading,
diff --git a/drivers/thermal/intel/intel_pch_thermal.c b/drivers/thermal/intel/intel_pch_thermal.c
index dabf11a687a1..8d3aaa467468 100644
--- a/drivers/thermal/intel/intel_pch_thermal.c
+++ b/drivers/thermal/intel/intel_pch_thermal.c
@@ -65,6 +65,8 @@
 #define WPT_TEMP_OFFSET	(PCH_TEMP_OFFSET * MILLIDEGREE_PER_DEGREE)
 #define GET_PCH_TEMP(x)	(((x) / 2) + PCH_TEMP_OFFSET)
 
+#define PCH_MAX_TRIPS 3 /* critical, hot, passive */
+
 /* Amount of time for each cooling delay, 100ms by default for now */
 static unsigned int delay_timeout = 100;
 module_param(delay_timeout, int, 0644);
@@ -82,12 +84,7 @@ struct pch_thermal_device {
 	const struct pch_dev_ops *ops;
 	struct pci_dev *pdev;
 	struct thermal_zone_device *tzd;
-	int crt_trip_id;
-	unsigned long crt_temp;
-	int hot_trip_id;
-	unsigned long hot_temp;
-	int psv_trip_id;
-	unsigned long psv_temp;
+	struct thermal_trip trips[PCH_MAX_TRIPS];
 	bool bios_enabled;
 };
 
@@ -102,33 +99,22 @@ static void pch_wpt_add_acpi_psv_trip(struct pch_thermal_device *ptd,
 				      int *nr_trips)
 {
 	struct acpi_device *adev;
-
-	ptd->psv_trip_id = -1;
+	int ret;
 
 	adev = ACPI_COMPANION(&ptd->pdev->dev);
-	if (adev) {
-		unsigned long long r;
-		acpi_status status;
-
-		status = acpi_evaluate_integer(adev->handle, "_PSV", NULL,
-					       &r);
-		if (ACPI_SUCCESS(status)) {
-			unsigned long trip_temp;
-
-			trip_temp = deci_kelvin_to_millicelsius(r);
-			if (trip_temp) {
-				ptd->psv_temp = trip_temp;
-				ptd->psv_trip_id = *nr_trips;
-				++(*nr_trips);
-			}
-		}
-	}
+	if (!adev)
+		return;
+
+	ret = thermal_acpi_trip_psv(adev, &ptd->trips[*nr_trips]);
+	if (ret)
+		return;
+
+	++(*nr_trips);
 }
 #else
 static void pch_wpt_add_acpi_psv_trip(struct pch_thermal_device *ptd,
 				      int *nr_trips)
 {
-	ptd->psv_trip_id = -1;
 
 }
 #endif
@@ -163,21 +149,19 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int *nr_trips)
 	}
 
 read_trips:
-	ptd->crt_trip_id = -1;
 	trip_temp = readw(ptd->hw_base + WPT_CTT);
 	trip_temp &= 0x1FF;
 	if (trip_temp) {
-		ptd->crt_temp = GET_WPT_TEMP(trip_temp);
-		ptd->crt_trip_id = 0;
+		ptd->trips[*nr_trips].temperature = GET_WPT_TEMP(trip_temp);
+		ptd->trips[*nr_trips].type = THERMAL_TRIP_CRITICAL;
 		++(*nr_trips);
 	}
 
-	ptd->hot_trip_id = -1;
 	trip_temp = readw(ptd->hw_base + WPT_PHL);
 	trip_temp &= 0x1FF;
 	if (trip_temp) {
-		ptd->hot_temp = GET_WPT_TEMP(trip_temp);
-		ptd->hot_trip_id = *nr_trips;
+		ptd->trips[*nr_trips].temperature = GET_WPT_TEMP(trip_temp);
+		ptd->trips[*nr_trips].type = THERMAL_TRIP_HOT;
 		++(*nr_trips);
 	}
 
@@ -298,39 +282,6 @@ static int pch_thermal_get_temp(struct thermal_zone_device *tzd, int *temp)
 	return	ptd->ops->get_temp(ptd, temp);
 }
 
-static int pch_get_trip_type(struct thermal_zone_device *tzd, int trip,
-			     enum thermal_trip_type *type)
-{
-	struct pch_thermal_device *ptd = tzd->devdata;
-
-	if (ptd->crt_trip_id == trip)
-		*type = THERMAL_TRIP_CRITICAL;
-	else if (ptd->hot_trip_id == trip)
-		*type = THERMAL_TRIP_HOT;
-	else if (ptd->psv_trip_id == trip)
-		*type = THERMAL_TRIP_PASSIVE;
-	else
-		return -EINVAL;
-
-	return 0;
-}
-
-static int pch_get_trip_temp(struct thermal_zone_device *tzd, int trip, int *temp)
-{
-	struct pch_thermal_device *ptd = tzd->devdata;
-
-	if (ptd->crt_trip_id == trip)
-		*temp = ptd->crt_temp;
-	else if (ptd->hot_trip_id == trip)
-		*temp = ptd->hot_temp;
-	else if (ptd->psv_trip_id == trip)
-		*temp = ptd->psv_temp;
-	else
-		return -EINVAL;
-
-	return 0;
-}
-
 static void pch_critical(struct thermal_zone_device *tzd)
 {
 	dev_dbg(&tzd->device, "%s: critical temperature reached\n", tzd->type);
@@ -338,8 +289,6 @@ static void pch_critical(struct thermal_zone_device *tzd)
 
 static struct thermal_zone_device_ops tzd_ops = {
 	.get_temp = pch_thermal_get_temp,
-	.get_trip_type = pch_get_trip_type,
-	.get_trip_temp = pch_get_trip_temp,
 	.critical = pch_critical,
 };
 
@@ -423,8 +372,9 @@ static int intel_pch_thermal_probe(struct pci_dev *pdev,
 	if (err)
 		goto error_cleanup;
 
-	ptd->tzd = thermal_zone_device_register(bi->name, nr_trips, 0, ptd,
-						&tzd_ops, NULL, 0, 0);
+	ptd->tzd = thermal_zone_device_register_with_trips(bi->name, ptd->trips,
+							   nr_trips, 0, ptd,
+							   &tzd_ops, NULL, 0, 0);
 	if (IS_ERR(ptd->tzd)) {
 		dev_err(&pdev->dev, "Failed to register thermal zone %s\n",
 			bi->name);
-- 
2.34.1

[PATCH v5 3/3] thermal/drivers/intel: Use generic trip points int340x

[Daniel Lezcano]

The thermal framework gives the possibility to register the trip
points with the thermal zone. When that is done, no get_trip_* ops are
needed and they can be removed.

Convert the ops content logic into generic trip points and register
them with the thermal zone.

In order to consolidate the code, use the ACPI thermal framework API
to fill the generic trip point from the ACPI tables.

It has been tested on a Intel i7-8650U - x280 with the INT3400, the
PCH, ACPITZ, and x86_pkg_temp. No regression observed so far.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
 .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++--------------
 .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
 3 files changed, 43 insertions(+), 145 deletions(-)

diff --git a/drivers/thermal/intel/int340x_thermal/Kconfig b/drivers/thermal/intel/int340x_thermal/Kconfig
index 5d046de96a5d..b7072d37101d 100644
--- a/drivers/thermal/intel/int340x_thermal/Kconfig
+++ b/drivers/thermal/intel/int340x_thermal/Kconfig
@@ -9,6 +9,7 @@ config INT340X_THERMAL
 	select THERMAL_GOV_USER_SPACE
 	select ACPI_THERMAL_REL
 	select ACPI_FAN
+	select THERMAL_ACPI
 	select INTEL_SOC_DTS_IOSF_CORE
 	select PROC_THERMAL_MMIO_RAPL if POWERCAP
 	help
diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
index 228f44260b27..2a294862d673 100644
--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
+++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
@@ -37,65 +37,6 @@ static int int340x_thermal_get_zone_temp(struct thermal_zone_device *zone,
 	return 0;
 }
 
-static int int340x_thermal_get_trip_temp(struct thermal_zone_device *zone,
-					 int trip, int *temp)
-{
-	struct int34x_thermal_zone *d = zone->devdata;
-	int i;
-
-	if (trip < d->aux_trip_nr)
-		*temp = d->aux_trips[trip];
-	else if (trip == d->crt_trip_id)
-		*temp = d->crt_temp;
-	else if (trip == d->psv_trip_id)
-		*temp = d->psv_temp;
-	else if (trip == d->hot_trip_id)
-		*temp = d->hot_temp;
-	else {
-		for (i = 0; i < INT340X_THERMAL_MAX_ACT_TRIP_COUNT; i++) {
-			if (d->act_trips[i].valid &&
-			    d->act_trips[i].id == trip) {
-				*temp = d->act_trips[i].temp;
-				break;
-			}
-		}
-		if (i == INT340X_THERMAL_MAX_ACT_TRIP_COUNT)
-			return -EINVAL;
-	}
-
-	return 0;
-}
-
-static int int340x_thermal_get_trip_type(struct thermal_zone_device *zone,
-					 int trip,
-					 enum thermal_trip_type *type)
-{
-	struct int34x_thermal_zone *d = zone->devdata;
-	int i;
-
-	if (trip < d->aux_trip_nr)
-		*type = THERMAL_TRIP_PASSIVE;
-	else if (trip == d->crt_trip_id)
-		*type = THERMAL_TRIP_CRITICAL;
-	else if (trip == d->hot_trip_id)
-		*type = THERMAL_TRIP_HOT;
-	else if (trip == d->psv_trip_id)
-		*type = THERMAL_TRIP_PASSIVE;
-	else {
-		for (i = 0; i < INT340X_THERMAL_MAX_ACT_TRIP_COUNT; i++) {
-			if (d->act_trips[i].valid &&
-			    d->act_trips[i].id == trip) {
-				*type = THERMAL_TRIP_ACTIVE;
-				break;
-			}
-		}
-		if (i == INT340X_THERMAL_MAX_ACT_TRIP_COUNT)
-			return -EINVAL;
-	}
-
-	return 0;
-}
-
 static int int340x_thermal_set_trip_temp(struct thermal_zone_device *zone,
 				      int trip, int temp)
 {
@@ -109,25 +50,6 @@ static int int340x_thermal_set_trip_temp(struct thermal_zone_device *zone,
 	if (ACPI_FAILURE(status))
 		return -EIO;
 
-	d->aux_trips[trip] = temp;
-
-	return 0;
-}
-
-
-static int int340x_thermal_get_trip_hyst(struct thermal_zone_device *zone,
-		int trip, int *temp)
-{
-	struct int34x_thermal_zone *d = zone->devdata;
-	acpi_status status;
-	unsigned long long hyst;
-
-	status = acpi_evaluate_integer(d->adev->handle, "GTSH", NULL, &hyst);
-	if (ACPI_FAILURE(status))
-		*temp = 0;
-	else
-		*temp = hyst * 100;
-
 	return 0;
 }
 
@@ -138,58 +60,36 @@ static void int340x_thermal_critical(struct thermal_zone_device *zone)
 
 static struct thermal_zone_device_ops int340x_thermal_zone_ops = {
 	.get_temp       = int340x_thermal_get_zone_temp,
-	.get_trip_temp	= int340x_thermal_get_trip_temp,
-	.get_trip_type	= int340x_thermal_get_trip_type,
 	.set_trip_temp	= int340x_thermal_set_trip_temp,
-	.get_trip_hyst =  int340x_thermal_get_trip_hyst,
 	.critical	= int340x_thermal_critical,
 };
 
-static int int340x_thermal_get_trip_config(acpi_handle handle, char *name,
-				      int *temp)
-{
-	unsigned long long r;
-	acpi_status status;
-
-	status = acpi_evaluate_integer(handle, name, NULL, &r);
-	if (ACPI_FAILURE(status))
-		return -EIO;
-
-	*temp = deci_kelvin_to_millicelsius(r);
-
-	return 0;
-}
-
 int int340x_thermal_read_trips(struct int34x_thermal_zone *int34x_zone)
 {
-	int trip_cnt = int34x_zone->aux_trip_nr;
-	int i;
+	int trip_cnt;
+	int i, ret;
+
+	trip_cnt = int34x_zone->aux_trip_nr;
 
-	int34x_zone->crt_trip_id = -1;
-	if (!int340x_thermal_get_trip_config(int34x_zone->adev->handle, "_CRT",
-					     &int34x_zone->crt_temp))
-		int34x_zone->crt_trip_id = trip_cnt++;
+	ret = thermal_acpi_trip_crit(int34x_zone->adev, &int34x_zone->trips[trip_cnt]);
+	if (!ret)
+		trip_cnt++;
 
-	int34x_zone->hot_trip_id = -1;
-	if (!int340x_thermal_get_trip_config(int34x_zone->adev->handle, "_HOT",
-					     &int34x_zone->hot_temp))
-		int34x_zone->hot_trip_id = trip_cnt++;
+	ret = thermal_acpi_trip_hot(int34x_zone->adev, &int34x_zone->trips[trip_cnt]);
+	if (!ret)
+		trip_cnt++;
 
-	int34x_zone->psv_trip_id = -1;
-	if (!int340x_thermal_get_trip_config(int34x_zone->adev->handle, "_PSV",
-					     &int34x_zone->psv_temp))
-		int34x_zone->psv_trip_id = trip_cnt++;
+	ret = thermal_acpi_trip_psv(int34x_zone->adev, &int34x_zone->trips[trip_cnt]);
+	if (!ret)
+		trip_cnt++;
 
 	for (i = 0; i < INT340X_THERMAL_MAX_ACT_TRIP_COUNT; i++) {
-		char name[5] = { '_', 'A', 'C', '0' + i, '\0' };
 
-		if (int340x_thermal_get_trip_config(int34x_zone->adev->handle,
-					name,
-					&int34x_zone->act_trips[i].temp))
+		ret = thermal_acpi_trip_act(int34x_zone->adev, &int34x_zone->trips[trip_cnt], i);
+		if (ret)
 			break;
 
-		int34x_zone->act_trips[i].id = trip_cnt++;
-		int34x_zone->act_trips[i].valid = true;
+		trip_cnt++;
 	}
 
 	return trip_cnt;
@@ -208,7 +108,7 @@ struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
 	acpi_status status;
 	unsigned long long trip_cnt;
 	int trip_mask = 0;
-	int ret;
+	int i, ret;
 
 	int34x_thermal_zone = kzalloc(sizeof(*int34x_thermal_zone),
 				      GFP_KERNEL);
@@ -228,32 +128,35 @@ struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
 		int34x_thermal_zone->ops->get_temp = get_temp;
 
 	status = acpi_evaluate_integer(adev->handle, "PATC", NULL, &trip_cnt);
-	if (ACPI_FAILURE(status))
-		trip_cnt = 0;
-	else {
-		int i;
-
-		int34x_thermal_zone->aux_trips =
-			kcalloc(trip_cnt,
-				sizeof(*int34x_thermal_zone->aux_trips),
-				GFP_KERNEL);
-		if (!int34x_thermal_zone->aux_trips) {
-			ret = -ENOMEM;
-			goto err_trip_alloc;
-		}
-		trip_mask = BIT(trip_cnt) - 1;
+	if (!ACPI_FAILURE(status)) {
 		int34x_thermal_zone->aux_trip_nr = trip_cnt;
-		for (i = 0; i < trip_cnt; ++i)
-			int34x_thermal_zone->aux_trips[i] = THERMAL_TEMP_INVALID;
+		trip_mask = BIT(trip_cnt) - 1;
+	}
+
+	int34x_thermal_zone->trips = kzalloc(sizeof(*int34x_thermal_zone->trips) *
+					     (INT340X_THERMAL_MAX_TRIP_COUNT + trip_cnt),
+					      GFP_KERNEL);
+	if (!int34x_thermal_zone->trips) {
+		ret = -ENOMEM;
+		goto err_trips_alloc;
 	}
 
 	trip_cnt = int340x_thermal_read_trips(int34x_thermal_zone);
 
+	for (i = 0; i < trip_cnt; ++i)
+		int34x_thermal_zone->trips[i].hysteresis = thermal_acpi_trip_gtsh(adev);
+
+	for (i = 0; i < int34x_thermal_zone->aux_trip_nr; i++) {
+		int34x_thermal_zone->trips[i].type = THERMAL_TRIP_PASSIVE;
+		int34x_thermal_zone->trips[i].temperature = THERMAL_TEMP_INVALID;
+	}
+
 	int34x_thermal_zone->lpat_table = acpi_lpat_get_conversion_table(
 								adev->handle);
 
-	int34x_thermal_zone->zone = thermal_zone_device_register(
+	int34x_thermal_zone->zone = thermal_zone_device_register_with_trips(
 						acpi_device_bid(adev),
+						int34x_thermal_zone->trips,
 						trip_cnt,
 						trip_mask, int34x_thermal_zone,
 						int34x_thermal_zone->ops,
@@ -272,9 +175,9 @@ struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
 err_enable:
 	thermal_zone_device_unregister(int34x_thermal_zone->zone);
 err_thermal_zone:
+	kfree(int34x_thermal_zone->trips);
 	acpi_lpat_free_conversion_table(int34x_thermal_zone->lpat_table);
-	kfree(int34x_thermal_zone->aux_trips);
-err_trip_alloc:
+err_trips_alloc:
 	kfree(int34x_thermal_zone->ops);
 err_ops_alloc:
 	kfree(int34x_thermal_zone);
@@ -287,7 +190,7 @@ void int340x_thermal_zone_remove(struct int34x_thermal_zone
 {
 	thermal_zone_device_unregister(int34x_thermal_zone->zone);
 	acpi_lpat_free_conversion_table(int34x_thermal_zone->lpat_table);
-	kfree(int34x_thermal_zone->aux_trips);
+	kfree(int34x_thermal_zone->trips);
 	kfree(int34x_thermal_zone->ops);
 	kfree(int34x_thermal_zone);
 }
diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
index e28ab1ba5e06..0c2c8de92014 100644
--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
+++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
@@ -10,6 +10,7 @@
 #include <acpi/acpi_lpat.h>
 
 #define INT340X_THERMAL_MAX_ACT_TRIP_COUNT	10
+#define INT340X_THERMAL_MAX_TRIP_COUNT INT340X_THERMAL_MAX_ACT_TRIP_COUNT + 3
 
 struct active_trip {
 	int temp;
@@ -19,15 +20,8 @@ struct active_trip {
 
 struct int34x_thermal_zone {
 	struct acpi_device *adev;
-	struct active_trip act_trips[INT340X_THERMAL_MAX_ACT_TRIP_COUNT];
-	unsigned long *aux_trips;
+	struct thermal_trip *trips;
 	int aux_trip_nr;
-	int psv_temp;
-	int psv_trip_id;
-	int crt_temp;
-	int crt_trip_id;
-	int hot_temp;
-	int hot_trip_id;
 	struct thermal_zone_device *zone;
 	struct thermal_zone_device_ops *ops;
 	void *priv_data;
-- 
2.34.1

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

Hi,

On 13/01/2023 19:02, Daniel Lezcano wrote:
> Recently sent as a RFC, the thermal ACPI for generic trip points is a set of
> functions to fill the generic trip points structure which will become the
> standard structure for the thermal framework and its users.
> 
> Different Intel drivers and the ACPI thermal driver are using the ACPI tables to
> get the thermal zone information. As those are getting the same information,
> providing this set of ACPI function with the generic trip points will
> consolidate the code.
> 
> Also, the Intel PCH and the Intel 34xx drivers are converted to use the generic
> trip points relying on the ACPI generic trip point parsing functions.
> 
> These changes have been tested on a Thinkpad Lenovo x280 with the PCH and
> INT34xx drivers. No regression have been observed, the trip points remain the
> same for what is described on this system.

Are we ok with this series ?

Sorry for insisting but I would like to go forward with the generic 
thermal trip work. There are more patches pending depending on this series.

Thanks
   -- Daniel

> Changelog:
>   - V5:
>     - Fixed GTSH unit conversion, deciK -> milli C
> 
>   - V4:
>     - Fixed Kconfig option dependency, select THERMAL_ACPI if ACPI is set
>       only for the PCH driver
> 
>   - V3:
>     - Took into account Rafael's comments
>     - Used a silence option THERMAL_ACPI in order to stay consistent
>       with THERMAL_OF. It is up to the API user to select the option.
> 
>   - V2:
>     - Fix the thermal ACPI patch where the thermal_acpi.c was not included in
>       the series
>     - Provide a couple of users of this API which could have been tested on a
>       real system
> 
> Daniel Lezcano (3):
>    thermal/acpi: Add ACPI trip point routines
>    thermal/drivers/intel: Use generic trip points for intel_pch
>    thermal/drivers/intel: Use generic trip points int340x
> 
>   drivers/thermal/Kconfig                       |   4 +
>   drivers/thermal/Makefile                      |   1 +
>   drivers/thermal/intel/Kconfig                 |   1 +
>   drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
>   .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++-----------
>   .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
>   drivers/thermal/intel/intel_pch_thermal.c     |  88 ++------
>   drivers/thermal/thermal_acpi.c                | 210 ++++++++++++++++++
>   include/linux/thermal.h                       |   8 +
>   9 files changed, 286 insertions(+), 214 deletions(-)
>   create mode 100644 drivers/thermal/thermal_acpi.c
> 

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Zhang, Rui]

On Wed, 2023-01-18 at 10:53 +0100, Daniel Lezcano wrote:
> Hi,
> 
> On 13/01/2023 19:02, Daniel Lezcano wrote:
> > Recently sent as a RFC, the thermal ACPI for generic trip points is
> > a set of
> > functions to fill the generic trip points structure which will
> > become the
> > standard structure for the thermal framework and its users.
> > 
> > Different Intel drivers and the ACPI thermal driver are using the
> > ACPI tables to
> > get the thermal zone information. As those are getting the same
> > information,
> > providing this set of ACPI function with the generic trip points
> > will
> > consolidate the code.
> > 
> > Also, the Intel PCH and the Intel 34xx drivers are converted to use
> > the generic
> > trip points relying on the ACPI generic trip point parsing
> > functions.
> > 
> > These changes have been tested on a Thinkpad Lenovo x280 with the
> > PCH and
> > INT34xx drivers. No regression have been observed, the trip points
> > remain the
> > same for what is described on this system.
> 
> Are we ok with this series ?
> 
> Sorry for insisting but I would like to go forward with the generic 
> thermal trip work. There are more patches pending depending on this
> series.

The whole series looks good to me.

Reviwed-by: Zhang Rui <rui.zhang@intel.com>

But we'd better wait for the thermald test result from Srinvias.

thanks,
rui
> 
> Thanks
>    -- Daniel
> 
> > Changelog:
> >   - V5:
> >     - Fixed GTSH unit conversion, deciK -> milli C
> > 
> >   - V4:
> >     - Fixed Kconfig option dependency, select THERMAL_ACPI if ACPI
> > is set
> >       only for the PCH driver
> > 
> >   - V3:
> >     - Took into account Rafael's comments
> >     - Used a silence option THERMAL_ACPI in order to stay
> > consistent
> >       with THERMAL_OF. It is up to the API user to select the
> > option.
> > 
> >   - V2:
> >     - Fix the thermal ACPI patch where the thermal_acpi.c was not
> > included in
> >       the series
> >     - Provide a couple of users of this API which could have been
> > tested on a
> >       real system
> > 
> > Daniel Lezcano (3):
> >    thermal/acpi: Add ACPI trip point routines
> >    thermal/drivers/intel: Use generic trip points for intel_pch
> >    thermal/drivers/intel: Use generic trip points int340x
> > 
> >   drivers/thermal/Kconfig                       |   4 +
> >   drivers/thermal/Makefile                      |   1 +
> >   drivers/thermal/intel/Kconfig                 |   1 +
> >   drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
> >   .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++---------
> > --
> >   .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
> >   drivers/thermal/intel/intel_pch_thermal.c     |  88 ++------
> >   drivers/thermal/thermal_acpi.c                | 210
> > ++++++++++++++++++
> >   include/linux/thermal.h                       |   8 +
> >   9 files changed, 286 insertions(+), 214 deletions(-)
> >   create mode 100644 drivers/thermal/thermal_acpi.c
> > 

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

On 18/01/2023 14:48, Zhang, Rui wrote:
> On Wed, 2023-01-18 at 10:53 +0100, Daniel Lezcano wrote:
>> Hi,
>>
>> On 13/01/2023 19:02, Daniel Lezcano wrote:
>>> Recently sent as a RFC, the thermal ACPI for generic trip points is
>>> a set of
>>> functions to fill the generic trip points structure which will
>>> become the
>>> standard structure for the thermal framework and its users.
>>>
>>> Different Intel drivers and the ACPI thermal driver are using the
>>> ACPI tables to
>>> get the thermal zone information. As those are getting the same
>>> information,
>>> providing this set of ACPI function with the generic trip points
>>> will
>>> consolidate the code.
>>>
>>> Also, the Intel PCH and the Intel 34xx drivers are converted to use
>>> the generic
>>> trip points relying on the ACPI generic trip point parsing
>>> functions.
>>>
>>> These changes have been tested on a Thinkpad Lenovo x280 with the
>>> PCH and
>>> INT34xx drivers. No regression have been observed, the trip points
>>> remain the
>>> same for what is described on this system.
>>
>> Are we ok with this series ?
>>
>> Sorry for insisting but I would like to go forward with the generic
>> thermal trip work. There are more patches pending depending on this
>> series.
> 
> The whole series looks good to me.
> 
> Reviwed-by: Zhang Rui <rui.zhang@intel.com>
> 
> But we'd better wait for the thermald test result from Srinvias.

Sure, thanks for the review !


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

On Wed, 2023-01-18 at 13:48 +0000, Zhang, Rui wrote:
> On Wed, 2023-01-18 at 10:53 +0100, Daniel Lezcano wrote:
> > Hi,
> > 
> > On 13/01/2023 19:02, Daniel Lezcano wrote:
> > > Recently sent as a RFC, the thermal ACPI for generic trip points
> > > is
> > > a set of
> > > functions to fill the generic trip points structure which will
> > > become the
> > > standard structure for the thermal framework and its users.
> > > 
> > > Different Intel drivers and the ACPI thermal driver are using the
> > > ACPI tables to
> > > get the thermal zone information. As those are getting the same
> > > information,
> > > providing this set of ACPI function with the generic trip points
> > > will
> > > consolidate the code.
> > > 
> > > Also, the Intel PCH and the Intel 34xx drivers are converted to
> > > use
> > > the generic
> > > trip points relying on the ACPI generic trip point parsing
> > > functions.
> > > 
> > > These changes have been tested on a Thinkpad Lenovo x280 with the
> > > PCH and
> > > INT34xx drivers. No regression have been observed, the trip
> > > points
> > > remain the
> > > same for what is described on this system.
> > 
> > Are we ok with this series ?
> > 
> > Sorry for insisting but I would like to go forward with the generic
> > thermal trip work. There are more patches pending depending on this
> > series.
> 
> The whole series looks good to me.
> 
> Reviwed-by: Zhang Rui <rui.zhang@intel.com>
> 
> But we'd better wait for the thermald test result from Srinvias.

A quick test show that things still work with thermald and these
changes.

Thanks,
Srinivas

> 
> thanks,
> rui
> > 
> > Thanks
> >    -- Daniel
> > 
> > > Changelog:
> > >   - V5:
> > >     - Fixed GTSH unit conversion, deciK -> milli C
> > > 
> > >   - V4:
> > >     - Fixed Kconfig option dependency, select THERMAL_ACPI if
> > > ACPI
> > > is set
> > >       only for the PCH driver
> > > 
> > >   - V3:
> > >     - Took into account Rafael's comments
> > >     - Used a silence option THERMAL_ACPI in order to stay
> > > consistent
> > >       with THERMAL_OF. It is up to the API user to select the
> > > option.
> > > 
> > >   - V2:
> > >     - Fix the thermal ACPI patch where the thermal_acpi.c was not
> > > included in
> > >       the series
> > >     - Provide a couple of users of this API which could have been
> > > tested on a
> > >       real system
> > > 
> > > Daniel Lezcano (3):
> > >    thermal/acpi: Add ACPI trip point routines
> > >    thermal/drivers/intel: Use generic trip points for intel_pch
> > >    thermal/drivers/intel: Use generic trip points int340x
> > > 
> > >   drivers/thermal/Kconfig                       |   4 +
> > >   drivers/thermal/Makefile                      |   1 +
> > >   drivers/thermal/intel/Kconfig                 |   1 +
> > >   drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
> > >   .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++-------
> > > --
> > > --
> > >   .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
> > >   drivers/thermal/intel/intel_pch_thermal.c     |  88 ++------
> > >   drivers/thermal/thermal_acpi.c                | 210
> > > ++++++++++++++++++
> > >   include/linux/thermal.h                       |   8 +
> > >   9 files changed, 286 insertions(+), 214 deletions(-)
> > >   create mode 100644 drivers/thermal/thermal_acpi.c
> > > 

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

Hi Srinivas,

On 18/01/2023 20:01, srinivas pandruvada wrote:

[ ... ]

>> The whole series looks good to me.
>>
>> Reviwed-by: Zhang Rui <rui.zhang@intel.com>
>>
>> But we'd better wait for the thermald test result from Srinvias.
> 
> A quick test show that things still work with thermald and these
> changes.

Thanks for testing. Shall I consider as Tested-by or do you want to test 
more ?


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

On Wed, 2023-01-18 at 11:01 -0800, srinivas pandruvada wrote:
> On Wed, 2023-01-18 at 13:48 +0000, Zhang, Rui wrote:
> > On Wed, 2023-01-18 at 10:53 +0100, Daniel Lezcano wrote:
> > > Hi,
> > > 
> > > On 13/01/2023 19:02, Daniel Lezcano wrote:
> > > > Recently sent as a RFC, the thermal ACPI for generic trip
> > > > points
> > > > is
> > > > a set of
> > > > functions to fill the generic trip points structure which will
> > > > become the
> > > > standard structure for the thermal framework and its users.
> > > > 
> > > > Different Intel drivers and the ACPI thermal driver are using
> > > > the
> > > > ACPI tables to
> > > > get the thermal zone information. As those are getting the same
> > > > information,
> > > > providing this set of ACPI function with the generic trip
> > > > points
> > > > will
> > > > consolidate the code.
> > > > 
> > > > Also, the Intel PCH and the Intel 34xx drivers are converted to
> > > > use
> > > > the generic
> > > > trip points relying on the ACPI generic trip point parsing
> > > > functions.
> > > > 
> > > > These changes have been tested on a Thinkpad Lenovo x280 with
> > > > the
> > > > PCH and
> > > > INT34xx drivers. No regression have been observed, the trip
> > > > points
> > > > remain the
> > > > same for what is described on this system.
> > > 
> > > Are we ok with this series ?
> > > 
> > > Sorry for insisting but I would like to go forward with the
> > > generic
> > > thermal trip work. There are more patches pending depending on
> > > this
> > > series.
> > 
> > The whole series looks good to me.
> > 
> > Reviwed-by: Zhang Rui <rui.zhang@intel.com>
> > 
> > But we'd better wait for the thermald test result from Srinvias.
> 
> A quick test show that things still work with thermald and these
> changes.

But I have a question. In some devices trip point temperature is not
static. When hardware changes, we get notification. For example
INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
Currently get_trip can get the latest changed value. But if we
preregister, we need some mechanism to update them.

Thanks,
Srinivas



> Thanks,
> Srinivas
> 
> > 
> > thanks,
> > rui
> > > 
> > > Thanks
> > >    -- Daniel
> > > 
> > > > Changelog:
> > > >   - V5:
> > > >     - Fixed GTSH unit conversion, deciK -> milli C
> > > > 
> > > >   - V4:
> > > >     - Fixed Kconfig option dependency, select THERMAL_ACPI if
> > > > ACPI
> > > > is set
> > > >       only for the PCH driver
> > > > 
> > > >   - V3:
> > > >     - Took into account Rafael's comments
> > > >     - Used a silence option THERMAL_ACPI in order to stay
> > > > consistent
> > > >       with THERMAL_OF. It is up to the API user to select the
> > > > option.
> > > > 
> > > >   - V2:
> > > >     - Fix the thermal ACPI patch where the thermal_acpi.c was
> > > > not
> > > > included in
> > > >       the series
> > > >     - Provide a couple of users of this API which could have
> > > > been
> > > > tested on a
> > > >       real system
> > > > 
> > > > Daniel Lezcano (3):
> > > >    thermal/acpi: Add ACPI trip point routines
> > > >    thermal/drivers/intel: Use generic trip points for intel_pch
> > > >    thermal/drivers/intel: Use generic trip points int340x
> > > > 
> > > >   drivers/thermal/Kconfig                       |   4 +
> > > >   drivers/thermal/Makefile                      |   1 +
> > > >   drivers/thermal/intel/Kconfig                 |   1 +
> > > >   drivers/thermal/intel/int340x_thermal/Kconfig |   1 +
> > > >   .../int340x_thermal/int340x_thermal_zone.c    | 177 ++++-----
> > > > --
> > > > --
> > > > --
> > > >   .../int340x_thermal/int340x_thermal_zone.h    |  10 +-
> > > >   drivers/thermal/intel/intel_pch_thermal.c     |  88 ++------
> > > >   drivers/thermal/thermal_acpi.c                | 210
> > > > ++++++++++++++++++
> > > >   include/linux/thermal.h                       |   8 +
> > > >   9 files changed, 286 insertions(+), 214 deletions(-)
> > > >   create mode 100644 drivers/thermal/thermal_acpi.c
> > > > 
> 

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

On 18/01/2023 20:16, srinivas pandruvada wrote:

[ ... ]

>>> But we'd better wait for the thermald test result from Srinvias.
>>
>> A quick test show that things still work with thermald and these
>> changes.
> 
> But I have a question. In some devices trip point temperature is not
> static. When hardware changes, we get notification. For example
> INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> Currently get_trip can get the latest changed value. But if we
> preregister, we need some mechanism to update them.

When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we call 
int340x_thermal_read_trips() which in turn updates the trip points.



-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> On 18/01/2023 20:16, srinivas pandruvada wrote:
> 
> [ ... ]
> 
> > > > But we'd better wait for the thermald test result from
> > > > Srinvias.
> > > 
> > > A quick test show that things still work with thermald and these
> > > changes.
> > 
> > But I have a question. In some devices trip point temperature is
> > not
> > static. When hardware changes, we get notification. For example
> > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > Currently get_trip can get the latest changed value. But if we
> > preregister, we need some mechanism to update them.
> 
> When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we
> call 
> int340x_thermal_read_trips() which in turn updates the trip points.
> 

Not sure how we handle concurrency here when driver can freely update
trips while thermal core is using trips.


Thanks,
Srinivas



> 
> 

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

On 18/01/2023 21:53, srinivas pandruvada wrote:
> On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
>> On 18/01/2023 20:16, srinivas pandruvada wrote:
>>
>> [ ... ]
>>
>>>>> But we'd better wait for the thermald test result from
>>>>> Srinvias.
>>>>
>>>> A quick test show that things still work with thermald and these
>>>> changes.
>>>
>>> But I have a question. In some devices trip point temperature is
>>> not
>>> static. When hardware changes, we get notification. For example
>>> INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
>>> Currently get_trip can get the latest changed value. But if we
>>> preregister, we need some mechanism to update them.
>>
>> When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we
>> call
>> int340x_thermal_read_trips() which in turn updates the trip points.
>>
> 
> Not sure how we handle concurrency here when driver can freely update
> trips while thermal core is using trips.

Don't we have the same race without this patch ? The thermal core can 
call get_trip_temp() while there is an update, no ?

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
> On 18/01/2023 21:53, srinivas pandruvada wrote:
> > On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> > > On 18/01/2023 20:16, srinivas pandruvada wrote:
> > > 
> > > [ ... ]
> > > 
> > > > > > But we'd better wait for the thermald test result from
> > > > > > Srinvias.
> > > > > 
> > > > > A quick test show that things still work with thermald and
> > > > > these
> > > > > changes.
> > > > 
> > > > But I have a question. In some devices trip point temperature
> > > > is
> > > > not
> > > > static. When hardware changes, we get notification. For example
> > > > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > > > Currently get_trip can get the latest changed value. But if we
> > > > preregister, we need some mechanism to update them.
> > > 
> > > When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we
> > > call
> > > int340x_thermal_read_trips() which in turn updates the trip
> > > points.
> > > 
> > 
> > Not sure how we handle concurrency here when driver can freely
> > update
> > trips while thermal core is using trips.
> 
> Don't we have the same race without this patch ? The thermal core can
> call get_trip_temp() while there is an update, no ?
Yes it is. But I can add a mutex locally here to solve.
But not any longer.

I think you need some thermal_zone_read_lock/unlock() in core, which
can use rcu. Even mutex is fine as there will be no contention as
updates to trips will be rare.

Thanks,
Srinivas

> 

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Daniel Lezcano]

On 18/01/2023 22:16, srinivas pandruvada wrote:
> On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
>> On 18/01/2023 21:53, srinivas pandruvada wrote:
>>> On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
>>>> On 18/01/2023 20:16, srinivas pandruvada wrote:
>>>>
>>>> [ ... ]
>>>>
>>>>>>> But we'd better wait for the thermald test result from
>>>>>>> Srinvias.
>>>>>>
>>>>>> A quick test show that things still work with thermald and
>>>>>> these
>>>>>> changes.
>>>>>
>>>>> But I have a question. In some devices trip point temperature
>>>>> is
>>>>> not
>>>>> static. When hardware changes, we get notification. For example
>>>>> INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
>>>>> Currently get_trip can get the latest changed value. But if we
>>>>> preregister, we need some mechanism to update them.
>>>>
>>>> When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we
>>>> call
>>>> int340x_thermal_read_trips() which in turn updates the trip
>>>> points.
>>>>
>>>
>>> Not sure how we handle concurrency here when driver can freely
>>> update
>>> trips while thermal core is using trips.
>>
>> Don't we have the same race without this patch ? The thermal core can
>> call get_trip_temp() while there is an update, no ?
> Yes it is. But I can add a mutex locally here to solve.
> But not any longer.
> 
> I think you need some thermal_zone_read_lock/unlock() in core, which
> can use rcu. Even mutex is fine as there will be no contention as
> updates to trips will be rare.

I was planning to provide a thermal_trips_update(tz, trips) and from 
there handle the locking.

As the race was already existing, can we postpone this change after the 
generic trip points changes?

There is still a lot of work to do to consolidate the code. One of them 
is to provide a generic function to browse the trip points and ensure 
the code is using it instead of directly inspect the thermal zone 
internals structure.

I'm almost there but I need the remaining Intel drivers changes to be 
merged (as well as ACPI which is finished but depending on this series).

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

On Wed, 2023-01-18 at 23:14 +0100, Daniel Lezcano wrote:
> On 18/01/2023 22:16, srinivas pandruvada wrote:
> > On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
> > > On 18/01/2023 21:53, srinivas pandruvada wrote:
> > > > On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> > > > > On 18/01/2023 20:16, srinivas pandruvada wrote:
> > > > > 
> > > > > [ ... ]
> > > > > 
> > > > > > > > But we'd better wait for the thermald test result from
> > > > > > > > Srinvias.
> > > > > > > 
> > > > > > > A quick test show that things still work with thermald
> > > > > > > and
> > > > > > > these
> > > > > > > changes.
> > > > > > 
> > > > > > But I have a question. In some devices trip point
> > > > > > temperature
> > > > > > is
> > > > > > not
> > > > > > static. When hardware changes, we get notification. For
> > > > > > example
> > > > > > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > > > > > Currently get_trip can get the latest changed value. But if
> > > > > > we
> > > > > > preregister, we need some mechanism to update them.
> > > > > 
> > > > > When the notification INT3403_PERF_TRIP_POINT_CHANGED
> > > > > happens, we
> > > > > call
> > > > > int340x_thermal_read_trips() which in turn updates the trip
> > > > > points.
> > > > > 
> > > > 
> > > > Not sure how we handle concurrency here when driver can freely
> > > > update
> > > > trips while thermal core is using trips.
> > > 
> > > Don't we have the same race without this patch ? The thermal core
> > > can
> > > call get_trip_temp() while there is an update, no ?
> > Yes it is. But I can add a mutex locally here to solve.
> > But not any longer.
> > 
> > I think you need some thermal_zone_read_lock/unlock() in core,
> > which
> > can use rcu. Even mutex is fine as there will be no contention as
> > updates to trips will be rare.
> 
> I was planning to provide a thermal_trips_update(tz, trips) and from 
> there handle the locking.
> 
> As the race was already existing, can we postpone this change after
> the 
> generic trip points changes?
I think so.

> 
> There is still a lot of work to do to consolidate the code. One of
> them 
> is to provide a generic function to browse the trip points and ensure
> the code is using it instead of directly inspect the thermal zone 
> internals structure.
> 
> I'm almost there but I need the remaining Intel drivers changes to be
> merged (as well as ACPI which is finished but depending on this
> series).
> 
Sounds good.

You can add my tested by for this.

Thanks,
Srinivas

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Rafael J. Wysocki]

On Thu, Jan 19, 2023 at 12:04 AM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Wed, 2023-01-18 at 23:14 +0100, Daniel Lezcano wrote:
> > On 18/01/2023 22:16, srinivas pandruvada wrote:
> > > On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
> > > > On 18/01/2023 21:53, srinivas pandruvada wrote:
> > > > > On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> > > > > > On 18/01/2023 20:16, srinivas pandruvada wrote:
> > > > > >
> > > > > > [ ... ]
> > > > > >
> > > > > > > > > But we'd better wait for the thermald test result from
> > > > > > > > > Srinvias.
> > > > > > > >
> > > > > > > > A quick test show that things still work with thermald
> > > > > > > > and
> > > > > > > > these
> > > > > > > > changes.
> > > > > > >
> > > > > > > But I have a question. In some devices trip point
> > > > > > > temperature
> > > > > > > is
> > > > > > > not
> > > > > > > static. When hardware changes, we get notification. For
> > > > > > > example
> > > > > > > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > > > > > > Currently get_trip can get the latest changed value. But if
> > > > > > > we
> > > > > > > preregister, we need some mechanism to update them.
> > > > > >
> > > > > > When the notification INT3403_PERF_TRIP_POINT_CHANGED
> > > > > > happens, we
> > > > > > call
> > > > > > int340x_thermal_read_trips() which in turn updates the trip
> > > > > > points.
> > > > > >
> > > > >
> > > > > Not sure how we handle concurrency here when driver can freely
> > > > > update
> > > > > trips while thermal core is using trips.
> > > >
> > > > Don't we have the same race without this patch ? The thermal core
> > > > can
> > > > call get_trip_temp() while there is an update, no ?
> > > Yes it is. But I can add a mutex locally here to solve.
> > > But not any longer.
> > >
> > > I think you need some thermal_zone_read_lock/unlock() in core,
> > > which
> > > can use rcu. Even mutex is fine as there will be no contention as
> > > updates to trips will be rare.
> >
> > I was planning to provide a thermal_trips_update(tz, trips) and from
> > there handle the locking.
> >
> > As the race was already existing, can we postpone this change after
> > the
> > generic trip points changes?
> I think so.

Well, what if this bug is reported by a user and a fix needs to be
backported to "stable"?

Are we going to backport the whole framework redesign along with it?

Or is this extremely unlikely?

Re: [PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Rafael J. Wysocki]

On Fri, Jan 13, 2023 at 7:02 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> The ACPI specification describes the trip points, the device tree
> bindings as well.
>
> The OF code uses the generic trip point structures.
>
> The ACPI has their own trip points structure and uses the get_trip_*
> ops to retrieve them.
>
> We can do the same as the OF code and create a set of ACPI functions
> to retrieve a trip point description. Having a common code for ACPI
> will help to cleanup the remaining Intel drivers and get rid of the
> get_trip_* functions.
>
> These changes add the ACPI thermal calls to retrieve the basic
> information we need to be reused in the thermal ACPI and Intel
> drivers.
>
> The different ACPI functions have the generic trip point structure
> passed as parameter where it is filled.
>
> This structure aims to be the one used by all the thermal drivers and
> the thermal framework.
>
> After this series, a couple of Intel drivers and the ACPI thermal
> driver will still have their own trip points definition but a new
> series on top of this one will finish the conversion to the generic
> trip point handling.
>
> This series depends on the generic trip point added to the thermal
> framework and available in the thermal/linux-next branch.
>
>  https://lkml.org/lkml/2022/10/3/456
>
> It has been tested on a Intel i7-8650U - x280 with the INT3400, the
> PCH, ACPITZ, and x86_pkg_temp. No regression observed so far.

Some names of the functions defined below can be less cryptic IMO.
Please see the following comments.

> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>  drivers/thermal/Kconfig        |   4 +
>  drivers/thermal/Makefile       |   1 +
>  drivers/thermal/thermal_acpi.c | 209 +++++++++++++++++++++++++++++++++
>  include/linux/thermal.h        |   8 ++
>  4 files changed, 222 insertions(+)
>  create mode 100644 drivers/thermal/thermal_acpi.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e052dae614eb..eaeb2b2ee6e9 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -76,6 +76,10 @@ config THERMAL_OF
>           Say 'Y' here if you need to build thermal infrastructure
>           based on device tree.
>
> +config THERMAL_ACPI
> +       depends on ACPI
> +       bool
> +
>  config THERMAL_WRITABLE_TRIPS
>         bool "Enable writable trip points"
>         help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 2506c6c8ca83..60f0dfa9aae2 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -13,6 +13,7 @@ thermal_sys-$(CONFIG_THERMAL_NETLINK)         += thermal_netlink.o
>  # interface to/from other layers providing sensors
>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>  thermal_sys-$(CONFIG_THERMAL_OF)               += thermal_of.o
> +thermal_sys-$(CONFIG_THERMAL_ACPI)             += thermal_acpi.o
>
>  # governors
>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += gov_fair_share.o
> diff --git a/drivers/thermal/thermal_acpi.c b/drivers/thermal/thermal_acpi.c
> new file mode 100644
> index 000000000000..ef6f10713650
> --- /dev/null
> +++ b/drivers/thermal/thermal_acpi.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2022 Linaro Limited
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * ACPI thermal configuration
> + */
> +#include <linux/acpi.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/units.h>
> +#include <uapi/linux/thermal.h>
> +
> +#include "thermal_core.h"
> +
> +/*
> + * An hysteresis value below zero is invalid and we can consider a
> + * value greater than 20°K/°C is invalid too.
> + */
> +#define HYSTERESIS_MIN_DECIK   0
> +#define HYSTERESIS_MAX_DECIK   200

If the full word "hysteresis" is used here, it should also be used in
the hysteresis-related names below.

I would use the "hyst" abbreviation here and elsewhere where applicable.

> +
> +/*
> + * Minimum temperature for full military grade is 218°K (-55°C) and
> + * max temperature is 448°K (175°C). We can consider those values as
> + * the boundaries for the [trips] temperature returned by the
> + * firmware. Any values out of these boundaries can be considered
> + * bogus and we can assume the firmware has no data to provide.
> + */
> +#define TEMPERATURE_MIN_DECIK  2180
> +#define TEMPERATURE_MAX_DECIK  4480

Like the above, but regarding "temperature" and "temp" instead of
"hysteresis" and "hyst", respectively.

> +
> +static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
> +                                              char *object, int *temperature)

So this would become thermal_acpi_get_temp_object(). or even
thermal_acpi_get_temp() because it really returns the temperature
value.

I also don't particularly like returning values via pointers, which is
entirely avoidable here, because the temperature value obtained from
the ACPI control methods must be a positive number.

So I would make it

static int thermal_acpi_get_temp(struct acpi_device *adev, char *object_name)
{

which would be consistent with the definition of the hysteresis
function below (which returns the value directly).

> +{
> +       unsigned long long temp;
> +       acpi_status status;
> +
> +       status = acpi_evaluate_integer(adev->handle, object, NULL, &temp);
> +       if (ACPI_FAILURE(status)) {
> +               acpi_handle_debug(adev->handle, "No temperature object '%s'\n", object);

This message may not be true, because status need not be AE_NOT_FOUND.

> +               return -ENODEV;
> +       }
> +
> +       if (temp < TEMPERATURE_MIN_DECIK || temp >= TEMPERATURE_MAX_DECIK) {
> +               acpi_handle_info(adev->handle, "Invalid temperature '%llu deci°K' for object '%s'\n",
> +                                temp, object);

I think that the message can be debug-level as well and I would just
say "Invalid value %llu returned by %s\n" in it.

> +               return -ENODATA;

And I'm not sure if the difference between -ENODEV and -ENODATA
matters here.  Maybe return -ENODATA in all error cases?

> +       }
> +
> +       *temperature = deci_kelvin_to_millicelsius(temp);
> +
> +       return 0;
> +}
> +
> +/**
> + * thermal_acpi_trip_gtsh() - Get the global hysteresis value

thermal_acpi_global_hyst() please.

> + * @adev: the acpi device to get the description from
> + *
> + * Get the global hysteresis value for the trip points. If any call
> + * fail, we shall return a zero hysteresis value.
> + *
> + * Return: An integer between %HYSTERESIS_MIN_DECIK and %HYSTERESIS_MAX_DECIK
> + */
> +int thermal_acpi_trip_gtsh(struct acpi_device *adev)
> +{
> +       unsigned long long hyst;
> +       acpi_status status;
> +
> +       status = acpi_evaluate_integer(adev->handle, "GTSH", NULL, &hyst);

GTSH is not a standard ACPI thing.

AFAICS, it's int3403 specific, so using it in a generic ACPI library
is questionable.

> +       if (ACPI_FAILURE(status))
> +               return 0;
> +
> +       if (hyst < HYSTERESIS_MIN_DECIK || hyst >= HYSTERESIS_MAX_DECIK) {
> +               acpi_handle_info(adev->handle, "Invalid hysteresis '%llu deci°K' for object 'GTSH'\n",
> +                                hyst);
> +               return 0;
> +       }
> +
> +       return deci_kelvin_to_millicelsius(hyst);
> +}
> +EXPORT_SYMBOL_GPL(thermal_acpi_trip_gtsh);
> +
> +/**
> + * thermal_acpi_trip_act() - Get the specified active trip point

thermal_acpi_active_trip_temp, please.

> + * @adev: the acpi device to get the description from

Please spell ACPI in capitals in all comments.

And I would say

@adev: Thermal zone ACPI device object

> + * @trip: a &struct thermal_trip to be filled if the function succeed

@trip: Trip point structure to be populated on success

> + * @id: an integer speciyfing the active trip point id

@id: Active cooling level (0 - 9)

> + *
> + * The function calls the ACPI framework to get the "_ACTx" objects
> + * which describe the active trip points.

No, it doesn't do that.  What it really does can be described as

"Evaluate the _ACx object for the thermal zone represented by @adev to
obtain the temperature of the active cooling trip point corresponding
to the active cooling level given by @id and initialize @trip as an
active trip point using that temperature value"

> The @id builds the "_ACTx"
> + * string with the numbered active trip point name. Then it fills the
> + * @trip structure with the information retrieved from those objects.
> + *
> + * Return:
> + * * 0 - Success
> + * * -ENODEV - Failed to retrieve the ACPI object
> + * * -ENODATA - The ACPI object value appears to be inconsistent
> + */
> +int thermal_acpi_trip_act(struct acpi_device *adev,
> +                         struct thermal_trip *trip, int id)
> +{
> +       char name[5];

char name[] = "_AC0";

> +       int ret;

int temp;

if (id < 0 || id > 9)
        return -EINVAL;

name[3] += id;

> +
> +       sprintf(name, "_AC%d", id);
> +
> +       ret = thermal_acpi_get_temperature_object(adev, name, &trip->temperature);
> +       if (ret)
> +               return ret;

temp = thermal_acpi_get_temp(adev, name);
if (temp < 0)
        return temp;

trip->temperature = temp;

And analogously below.

> +
> +       trip->hysteresis = 0;
> +       trip->type = THERMAL_TRIP_ACTIVE;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_acpi_trip_act);
> +
> +/**
> + * thermal_acpi_trip_psv() - Get the passive trip point

thermal_acpi_passive_trip_temp, please.

> + * @adev: the acpi device to get the description from
> + * @trip: a &struct thermal_trip to be filled if the function succeed

The same comments as above apply.

> + *
> + * The function calls the ACPI framework to get the "_PSV" object
> + * which describe the passive trip point. Then it fills the @trip
> + * structure with the information retrieved from those objects.

"Evaluate the _PSV object for the thermal zone represented by @adev to
obtain the temperature of the passive cooling trip point and
initialize @trip as a passive trip point using that temperature
value."

> + *
> + * Return:
> + * * 0 - Success
> + * * -ENODEV - Failed to retrieve the ACPI object
> + * * -ENODATA - The ACPI object value appears to be inconsistent
> + */
> +int thermal_acpi_trip_psv(struct acpi_device *adev, struct thermal_trip *trip)
> +{
> +       int ret;
> +
> +       ret = thermal_acpi_get_temperature_object(adev, "_PSV", &trip->temperature);
> +       if (ret)
> +               return ret;
> +
> +       trip->hysteresis = 0;
> +       trip->type = THERMAL_TRIP_PASSIVE;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_acpi_trip_psv);
> +
> +/**
> + * thermal_acpi_trip_hot() - Get the near critical trip point

thermal_acpi_hot_trip_temp, please.

> + * @adev: the acpi device to get the description from
> + * @trip: a &struct thermal_trip to be filled if the function succeed

The same comments as above apply.

> + *
> + * The function calls the ACPI framework to get the "_HOT" object
> + * which describe the hot trip point. Then it fills the @trip
> + * structure with the information retrieved from those objects.

"Evaluate the _HOT object for the thermal zone represented by @adev to
obtain the temperature of the trip point at which the system is
expected to be put into the S4 sleep state and initialize @trip as a
hot trip point using that temperature value."

> + *
> + * Return:
> + * * 0 - Success
> + * * -ENODEV - Failed to retrieve the ACPI object
> + * * -ENODATA - The ACPI object appears to be inconsistent
> + */
> +int thermal_acpi_trip_hot(struct acpi_device *adev, struct thermal_trip *trip)
> +{
> +       int ret;
> +
> +       ret = thermal_acpi_get_temperature_object(adev, "_HOT", &trip->temperature);
> +       if (ret)
> +               return ret;
> +
> +       trip->hysteresis = 0;
> +       trip->type = THERMAL_TRIP_HOT;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_acpi_trip_hot);
> +
> +/**
> + * thermal_acpi_trip_crit() - Get the critical trip point

thermal_acpi_crit_trip_temp, please.

> + * @adev: the acpi device to get the description from
> + * @trip: a &struct thermal_trip to be filled if the function succeed

The same comments as above apply.

> + *
> + * The function calls the ACPI framework to get the "_CRT" object
> + * which describe the critical trip point. Then it fills the @trip
> + * structure with the information retrieved from this object.

"Evaluate the _CRT object for the thermal zone represented by @adev to
obtain the temperature of the critical cooling trip point and
initialize @trip as a critical trip point using that temperature
value."

> + *
> + * Return:
> + * * 0 - Success
> + * * -ENODEV - Failed to retrieve the ACPI object
> + * * -ENODATA - The ACPI object value appears to be inconsistent
> + */
> +int thermal_acpi_trip_crit(struct acpi_device *adev, struct thermal_trip *trip)
> +{
> +       int ret;
> +
> +       ret = thermal_acpi_get_temperature_object(adev, "_CRT", &trip->temperature);
> +       if (ret)
> +               return ret;
> +
> +       /*
> +        * The hysteresis value has no sense here because critical
> +        * trip point has no u-turn
> +        */
> +       trip->hysteresis = 0;
> +       trip->type = THERMAL_TRIP_CRITICAL;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_acpi_trip_crit);
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 30353e4b1424..ba2d5d4c23e2 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -334,6 +334,14 @@ static inline void devm_thermal_of_zone_unregister(struct device *dev,
>  }
>  #endif
>
> +#ifdef CONFIG_THERMAL_ACPI
> +int thermal_acpi_trip_gtsh(struct acpi_device *adev);
> +int thermal_acpi_trip_crit(struct acpi_device *adev, struct thermal_trip *trip);
> +int thermal_acpi_trip_hot(struct acpi_device *adev, struct thermal_trip *trip);
> +int thermal_acpi_trip_psv(struct acpi_device *adev, struct thermal_trip *trip);
> +int thermal_acpi_trip_act(struct acpi_device *adev, struct thermal_trip *trip, int id);
> +#endif
> +
>  int __thermal_zone_get_trip(struct thermal_zone_device *tz, int trip_id,
>                             struct thermal_trip *trip);
>  int thermal_zone_get_trip(struct thermal_zone_device *tz, int trip_id,
> --

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[srinivas pandruvada]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

On Thu, 2023-01-19 at 13:17 +0100, Rafael J. Wysocki wrote:
> On Thu, Jan 19, 2023 at 12:04 AM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > 
> > On Wed, 2023-01-18 at 23:14 +0100, Daniel Lezcano wrote:
> > > On 18/01/2023 22:16, srinivas pandruvada wrote:
> > > > On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
> > > > > On 18/01/2023 21:53, srinivas pandruvada wrote:
> > > > > > On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> > > > > > > On 18/01/2023 20:16, srinivas pandruvada wrote:
> > > > > > > 
> > > > > > > [ ... ]
> > > > > > > 
> > > > > > > > > > But we'd better wait for the thermald test result
> > > > > > > > > > from
> > > > > > > > > > Srinvias.
> > > > > > > > > 
> > > > > > > > > A quick test show that things still work with
> > > > > > > > > thermald
> > > > > > > > > and
> > > > > > > > > these
> > > > > > > > > changes.
> > > > > > > > 
> > > > > > > > But I have a question. In some devices trip point
> > > > > > > > temperature
> > > > > > > > is
> > > > > > > > not
> > > > > > > > static. When hardware changes, we get notification. For
> > > > > > > > example
> > > > > > > > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > > > > > > > Currently get_trip can get the latest changed value.
> > > > > > > > But if
> > > > > > > > we
> > > > > > > > preregister, we need some mechanism to update them.
> > > > > > > 
> > > > > > > When the notification INT3403_PERF_TRIP_POINT_CHANGED
> > > > > > > happens, we
> > > > > > > call
> > > > > > > int340x_thermal_read_trips() which in turn updates the
> > > > > > > trip
> > > > > > > points.
> > > > > > > 
> > > > > > 
> > > > > > Not sure how we handle concurrency here when driver can
> > > > > > freely
> > > > > > update
> > > > > > trips while thermal core is using trips.
> > > > > 
> > > > > Don't we have the same race without this patch ? The thermal
> > > > > core
> > > > > can
> > > > > call get_trip_temp() while there is an update, no ?
> > > > Yes it is. But I can add a mutex locally here to solve.
> > > > But not any longer.
> > > > 
> > > > I think you need some thermal_zone_read_lock/unlock() in core,
> > > > which
> > > > can use rcu. Even mutex is fine as there will be no contention
> > > > as
> > > > updates to trips will be rare.
> > > 
> > > I was planning to provide a thermal_trips_update(tz, trips) and
> > > from
> > > there handle the locking.
> > > 
> > > As the race was already existing, can we postpone this change
> > > after
> > > the
> > > generic trip points changes?
> > I think so.
> 
> Well, what if this bug is reported by a user and a fix needs to be
> backported to "stable"?
> 
> Are we going to backport the whole framework redesign along with it?
> 
> Or is this extremely unlikely?
These trips are read at the start of DTT/Thermald and will be read once
after notification is received. So extremely unlikely. 
But we can add the patch before this series to address this issue,
which can be marked stable. I can submit this.

Thanks,
Srinivas


[-- Attachment #2: 0001-thermal-int340x-Protect-trip-temperature-from-dynami.patch --]
[-- Type: text/x-patch, Size: 4309 bytes --]

From 2157c15ab856585c421119ac4587747311cb2a99 Mon Sep 17 00:00:00 2001
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: Thu, 19 Jan 2023 08:37:15 -0800
Subject: [PATCH] thermal: int340x: Protect trip temperature from dynamic
 update

Trip temperatures are read using ACPI methods and stored in the memory
during zone initializtion and when the firmware sends a notification for
change. This trip temperature is returned when the thermal core calls via
callback get_trip_temp().

But it is possible that while updating the memory copy of the trips when
the firmware sends a notification for change, thermal core is reading the
trip temperature via the callback get_trip_temp(). This may return invalid
trip temperature.

To address this add a mutex to protect the invalid temperature reads in
the callback get_trip_temp() and int340x_thermal_read_trips().

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 .../intel/int340x_thermal/int340x_thermal_zone.c | 16 +++++++++++++++-
 .../intel/int340x_thermal/int340x_thermal_zone.h |  1 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
index 62c0aa5d0783..fd9080640e03 100644
--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
+++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
@@ -49,6 +49,8 @@ static int int340x_thermal_get_trip_temp(struct thermal_zone_device *zone,
 	if (d->override_ops && d->override_ops->get_trip_temp)
 		return d->override_ops->get_trip_temp(zone, trip, temp);
 
+	mutex_lock(&d->trip_mutex);
+
 	if (trip < d->aux_trip_nr)
 		*temp = d->aux_trips[trip];
 	else if (trip == d->crt_trip_id)
@@ -65,10 +67,14 @@ static int int340x_thermal_get_trip_temp(struct thermal_zone_device *zone,
 				break;
 			}
 		}
-		if (i == INT340X_THERMAL_MAX_ACT_TRIP_COUNT)
+		if (i == INT340X_THERMAL_MAX_ACT_TRIP_COUNT) {
+			mutex_unlock(&d->trip_mutex);
 			return -EINVAL;
+		}
 	}
 
+	mutex_unlock(&d->trip_mutex);
+
 	return 0;
 }
 
@@ -180,6 +186,8 @@ int int340x_thermal_read_trips(struct int34x_thermal_zone *int34x_zone)
 	int trip_cnt = int34x_zone->aux_trip_nr;
 	int i;
 
+	mutex_lock(&int34x_zone->trip_mutex);
+
 	int34x_zone->crt_trip_id = -1;
 	if (!int340x_thermal_get_trip_config(int34x_zone->adev->handle, "_CRT",
 					     &int34x_zone->crt_temp))
@@ -207,6 +215,8 @@ int int340x_thermal_read_trips(struct int34x_thermal_zone *int34x_zone)
 		int34x_zone->act_trips[i].valid = true;
 	}
 
+	mutex_unlock(&int34x_zone->trip_mutex);
+
 	return trip_cnt;
 }
 EXPORT_SYMBOL_GPL(int340x_thermal_read_trips);
@@ -230,6 +240,8 @@ struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
 	if (!int34x_thermal_zone)
 		return ERR_PTR(-ENOMEM);
 
+	mutex_init(&int34x_thermal_zone->trip_mutex);
+
 	int34x_thermal_zone->adev = adev;
 	int34x_thermal_zone->override_ops = override_ops;
 
@@ -281,6 +293,7 @@ struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
 	acpi_lpat_free_conversion_table(int34x_thermal_zone->lpat_table);
 	kfree(int34x_thermal_zone->aux_trips);
 err_trip_alloc:
+	mutex_destroy(&int34x_thermal_zone->trip_mutex);
 	kfree(int34x_thermal_zone);
 	return ERR_PTR(ret);
 }
@@ -292,6 +305,7 @@ void int340x_thermal_zone_remove(struct int34x_thermal_zone
 	thermal_zone_device_unregister(int34x_thermal_zone->zone);
 	acpi_lpat_free_conversion_table(int34x_thermal_zone->lpat_table);
 	kfree(int34x_thermal_zone->aux_trips);
+	mutex_destroy(&int34x_thermal_zone->trip_mutex);
 	kfree(int34x_thermal_zone);
 }
 EXPORT_SYMBOL_GPL(int340x_thermal_zone_remove);
diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
index 3b4971df1b33..8f9872afd0d3 100644
--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
+++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.h
@@ -32,6 +32,7 @@ struct int34x_thermal_zone {
 	struct thermal_zone_device_ops *override_ops;
 	void *priv_data;
 	struct acpi_lpat_conversion_table *lpat_table;
+	struct mutex trip_mutex;
 };
 
 struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *,
-- 
2.38.1

Re: [PATCH v5 0/3] Thermal ACPI APIs for generic trip points

[Rafael J. Wysocki]

On Thu, Jan 19, 2023 at 5:58 PM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Thu, 2023-01-19 at 13:17 +0100, Rafael J. Wysocki wrote:
> > On Thu, Jan 19, 2023 at 12:04 AM srinivas pandruvada
> > <srinivas.pandruvada@linux.intel.com> wrote:
> > >
> > > On Wed, 2023-01-18 at 23:14 +0100, Daniel Lezcano wrote:
> > > > On 18/01/2023 22:16, srinivas pandruvada wrote:
> > > > > On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
> > > > > > On 18/01/2023 21:53, srinivas pandruvada wrote:
> > > > > > > On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
> > > > > > > > On 18/01/2023 20:16, srinivas pandruvada wrote:
> > > > > > > >
> > > > > > > > [ ... ]
> > > > > > > >
> > > > > > > > > > > But we'd better wait for the thermald test result
> > > > > > > > > > > from
> > > > > > > > > > > Srinvias.
> > > > > > > > > >
> > > > > > > > > > A quick test show that things still work with
> > > > > > > > > > thermald
> > > > > > > > > > and
> > > > > > > > > > these
> > > > > > > > > > changes.
> > > > > > > > >
> > > > > > > > > But I have a question. In some devices trip point
> > > > > > > > > temperature
> > > > > > > > > is
> > > > > > > > > not
> > > > > > > > > static. When hardware changes, we get notification. For
> > > > > > > > > example
> > > > > > > > > INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
> > > > > > > > > Currently get_trip can get the latest changed value.
> > > > > > > > > But if
> > > > > > > > > we
> > > > > > > > > preregister, we need some mechanism to update them.
> > > > > > > >
> > > > > > > > When the notification INT3403_PERF_TRIP_POINT_CHANGED
> > > > > > > > happens, we
> > > > > > > > call
> > > > > > > > int340x_thermal_read_trips() which in turn updates the
> > > > > > > > trip
> > > > > > > > points.
> > > > > > > >
> > > > > > >
> > > > > > > Not sure how we handle concurrency here when driver can
> > > > > > > freely
> > > > > > > update
> > > > > > > trips while thermal core is using trips.
> > > > > >
> > > > > > Don't we have the same race without this patch ? The thermal
> > > > > > core
> > > > > > can
> > > > > > call get_trip_temp() while there is an update, no ?
> > > > > Yes it is. But I can add a mutex locally here to solve.
> > > > > But not any longer.
> > > > >
> > > > > I think you need some thermal_zone_read_lock/unlock() in core,
> > > > > which
> > > > > can use rcu. Even mutex is fine as there will be no contention
> > > > > as
> > > > > updates to trips will be rare.
> > > >
> > > > I was planning to provide a thermal_trips_update(tz, trips) and
> > > > from
> > > > there handle the locking.
> > > >
> > > > As the race was already existing, can we postpone this change
> > > > after
> > > > the
> > > > generic trip points changes?
> > > I think so.
> >
> > Well, what if this bug is reported by a user and a fix needs to be
> > backported to "stable"?
> >
> > Are we going to backport the whole framework redesign along with it?
> >
> > Or is this extremely unlikely?
> These trips are read at the start of DTT/Thermald and will be read once
> after notification is received. So extremely unlikely.
> But we can add the patch before this series to address this issue,
> which can be marked stable. I can submit this.

Looks reasonable to me.

Re: [PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Daniel Lezcano]

Hi Rafael,


On 19/01/2023 14:15, Rafael J. Wysocki wrote:

[ ... ]

>> +static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
>> +                                              char *object, int *temperature)
> 
> So this would become thermal_acpi_get_temp_object(). or even
> thermal_acpi_get_temp() because it really returns the temperature
> value.
> 
> I also don't particularly like returning values via pointers, which is
> entirely avoidable here, because the temperature value obtained from
> the ACPI control methods must be a positive number.
> 
> So I would make it
> 
> static int thermal_acpi_get_temp(struct acpi_device *adev, char *object_name)
> {

We are converting decikelvin -> millicelsius. Even it is very unlikely, 
the result could be less than zero (eg. -1°C). We won't be able to 
differentiate -ENODATA with a negative value, no ?

In the future, it is possible we will have to deal with cold trip points 
in order to warm a board. May be we should don't care for now ?


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Rafael J. Wysocki]

On Fri, Jan 20, 2023 at 7:08 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
>
> Hi Rafael,
>
>
> On 19/01/2023 14:15, Rafael J. Wysocki wrote:
>
> [ ... ]
>
> >> +static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
> >> +                                              char *object, int *temperature)
> >
> > So this would become thermal_acpi_get_temp_object(). or even
> > thermal_acpi_get_temp() because it really returns the temperature
> > value.
> >
> > I also don't particularly like returning values via pointers, which is
> > entirely avoidable here, because the temperature value obtained from
> > the ACPI control methods must be a positive number.
> >
> > So I would make it
> >
> > static int thermal_acpi_get_temp(struct acpi_device *adev, char *object_name)
> > {
>
> We are converting decikelvin -> millicelsius. Even it is very unlikely,
> the result could be less than zero (eg. -1°C). We won't be able to
> differentiate -ENODATA with a negative value, no ?
>
> In the future, it is possible we will have to deal with cold trip points
> in order to warm a board. May be we should don't care for now ?

My point is that the ACPI specification mandates that the return
values be in deciK and so always non-negative.

Re: [PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Daniel Lezcano]

On 20/01/2023 19:15, Rafael J. Wysocki wrote:
> On Fri, Jan 20, 2023 at 7:08 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>>
>> Hi Rafael,
>>
>>
>> On 19/01/2023 14:15, Rafael J. Wysocki wrote:
>>
>> [ ... ]
>>
>>>> +static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
>>>> +                                              char *object, int *temperature)
>>>
>>> So this would become thermal_acpi_get_temp_object(). or even
>>> thermal_acpi_get_temp() because it really returns the temperature
>>> value.
>>>
>>> I also don't particularly like returning values via pointers, which is
>>> entirely avoidable here, because the temperature value obtained from
>>> the ACPI control methods must be a positive number.
>>>
>>> So I would make it
>>>
>>> static int thermal_acpi_get_temp(struct acpi_device *adev, char *object_name)
>>> {
>>
>> We are converting decikelvin -> millicelsius. Even it is very unlikely,
>> the result could be less than zero (eg. -1°C). We won't be able to
>> differentiate -ENODATA with a negative value, no ?
>>
>> In the future, it is possible we will have to deal with cold trip points
>> in order to warm a board. May be we should don't care for now ?
> 
> My point is that the ACPI specification mandates that the return
> values be in deciK and so always non-negative.

I understand that but the code does:

static int thermal_acpi_get_temp(struct acpi_device *adev, char 
*object_name)
{
	...

	return deci_kelvin_to_millicelsius(temp);
}

All the callers do:

...

         ret = thermal_acpi_get_temp(adev, name);
         if (ret < 0)
		return ret;
	/* This could be an error
	 * or negative millicelsius temperature
	 */

	/* here we already have millicelsius */
         trip->temperature = ret;
...

So I guess we want to do:

...

         ret = thermal_acpi_get_temp(adev, name);
         if (ret < 0)
		return ret;

	/* we convert here instead in thermal_acpi_get_temp() */
         trip->temperature = deci_kelvin_to_millicelsius(ret);
...

Sounds good ?


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v5 1/3] thermal/acpi: Add ACPI trip point routines

[Rafael J. Wysocki]

On Fri, Jan 20, 2023 at 7:27 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 20/01/2023 19:15, Rafael J. Wysocki wrote:
> > On Fri, Jan 20, 2023 at 7:08 PM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> >>
> >>
> >> Hi Rafael,
> >>
> >>
> >> On 19/01/2023 14:15, Rafael J. Wysocki wrote:
> >>
> >> [ ... ]
> >>
> >>>> +static int thermal_acpi_get_temperature_object(struct acpi_device *adev,
> >>>> +                                              char *object, int *temperature)
> >>>
> >>> So this would become thermal_acpi_get_temp_object(). or even
> >>> thermal_acpi_get_temp() because it really returns the temperature
> >>> value.
> >>>
> >>> I also don't particularly like returning values via pointers, which is
> >>> entirely avoidable here, because the temperature value obtained from
> >>> the ACPI control methods must be a positive number.
> >>>
> >>> So I would make it
> >>>
> >>> static int thermal_acpi_get_temp(struct acpi_device *adev, char *object_name)
> >>> {
> >>
> >> We are converting decikelvin -> millicelsius. Even it is very unlikely,
> >> the result could be less than zero (eg. -1°C). We won't be able to
> >> differentiate -ENODATA with a negative value, no ?
> >>
> >> In the future, it is possible we will have to deal with cold trip points
> >> in order to warm a board. May be we should don't care for now ?
> >
> > My point is that the ACPI specification mandates that the return
> > values be in deciK and so always non-negative.
>
> I understand that but the code does:
>
> static int thermal_acpi_get_temp(struct acpi_device *adev, char
> *object_name)
> {
>         ...
>
>         return deci_kelvin_to_millicelsius(temp);
> }
>
> All the callers do:
>
> ...
>
>          ret = thermal_acpi_get_temp(adev, name);
>          if (ret < 0)
>                 return ret;
>         /* This could be an error
>          * or negative millicelsius temperature
>          */
>
>         /* here we already have millicelsius */
>          trip->temperature = ret;
> ...
>
> So I guess we want to do:
>
> ...
>
>          ret = thermal_acpi_get_temp(adev, name);
>          if (ret < 0)
>                 return ret;
>
>         /* we convert here instead in thermal_acpi_get_temp() */
>          trip->temperature = deci_kelvin_to_millicelsius(ret);
> ...
>
> Sounds good ?

Yes, it does.  Convert when it is known to be valid.