dt-bindings: imx8mm-thermal: Document nxp,reboot-on-critical

From: Fabio Estevam <[email protected]>

Currently, after the SoC reaches the critical temperature, the board goes through a poweroff mechanism.

In some cases, such behavior does not suit well, as the board may be unattended in the field and rebooting may be a better approach.

The bootloader may also check the temperature and only allow the boot to proceed when the temperature is below a certain threshold.

Introduce the 'nxp,reboot-on-critical' property to indicate that the board will go through a reboot after the critical temperature is reached.

When this property is absent, the default behavior of forcing a shutdown is kept.

---
Changes since v4:
- None. Went back to using device tree property.

 .../devicetree/bindings/thermal/imx8mm-thermal.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

index d2c1e4573c32..9ac70360fd35 100644
@@ -32,6 +32,12 @@ properties:
   clocks:
     maxItems: 1
 
+  nxp,reboot-on-critical:
+    description: Property to indicate that the system will go through a reboot
+      after the critical temperature is reached. If absent, the system will
+      go through shutdown after the critical temperature is reached.
+    type: boolean
+
   nvmem-cells:
     maxItems: 1
     description: Phandle to the calibration data provided by ocotp

2.34.1

From: Fabio Estevam <[email protected]>

Currently, after the SoC reaches the critical temperature, the board goes through a poweroff mechanism.

In some cases, such behavior does not suit well, as the board may be unattended in the field and rebooting may be a better approach.

The bootloader may also check the temperature and only allow the boot to proceed when the temperature is below a certain threshold.

Introduce the 'nxp,reboot-on-critical' property to indicate that the board will go through a reboot after the critical temperature is reached.

When this property is absent, the default behavior of forcing a shutdown is kept.

Tested on a imx8mm-evk board.

---
Changes since v4:
- Went back to the devicetree approach.
- Populate tmu_tz_ops.critical inside probe (Daniel). Changes since v3:
- Switch to sysfs.
Changes since v2:
- Populate tmu_tz_ops.critical inside probe (Daniel). Changes since v1:
- Use module_param().

 drivers/thermal/imx8mm_thermal.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

index e89b11b3f2b9..0ca3cba33f39 100644
@@ -13,6 +13,7 @@
 #include <linux/nvmem-consumer.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/reboot.h>
 #include <linux/slab.h>
 #include <linux/thermal.h>
 

@@ -146,7 +147,7 @@ static int tmu_get_temp(struct thermal_zone_device *tz, int *temp)
 	return tmu->socdata->get_temp(sensor, temp);
 }
 
-static const struct thermal_zone_device_ops tmu_tz_ops = {
+static struct thermal_zone_device_ops tmu_tz_ops = {
 	.get_temp = tmu_get_temp,
 };
 

@@ -293,6 +294,13 @@ static int imx8mm_tmu_probe_set_calib(struct platform_device *pdev,
 	return imx8mm_tmu_probe_set_calib_v2(pdev, tmu);
 }
 
+static void tmu_critical(struct thermal_zone_device *tz)
+{
+	dev_emerg(thermal_zone_device(tz), "%s: critical temperature reached\n",
+		  thermal_zone_device_type(tz));
+	kernel_restart(NULL);
+}
+
 static int imx8mm_tmu_probe(struct platform_device *pdev)
 {
 	const struct thermal_soc_data *data;

@@ -313,6 +321,9 @@ static int imx8mm_tmu_probe(struct platform_device *pdev)
 	if (IS_ERR(tmu->base))
 		return PTR_ERR(tmu->base);
 
+	if (of_property_present(pdev->dev.of_node, "nxp,reboot-on-critical"))
+		tmu_tz_ops.critical = tmu_critical;
+
 	tmu->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(tmu->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(tmu->clk),

2.34.1

Hi Krzysztof,

I got your point and it makes sense.

I tested locally with a common DT property like this:

index 4f3acdc4dec0..782cbb4ea487 100644

@@ -75,6 +75,14 @@ patternProperties:
           framework and assumes that the thermal sensors in this zone
           support interrupts.
 
+      critical-action:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          The action that happens after the critical temperature is reached.
+          Possible values are 0 for shutdown and 1 for reboot.
+
+        enum: [ 0, 1 ]
+
       thermal-sensors:
         $ref: /schemas/types.yaml#/definitions/phandle-array
         maxItems: 1

Then in the board dts I can use:

+
+ thermal-zones {
+ cpu-thermal {
+ critical-action = <THERMAL_CRITICAL_ACTION_REBOOT>;
+ };
+ };
};

I should probably be able to post something next week.

Thanks
Thanks