[v8,1/3] dt-bindings: thermal-zones: Document critical-action

From: Fabio Estevam <festevam@denx.de>

Document the critical-action property to describe the thermal action
the OS should perform after the critical temperature is reached.

The possible values are "shutdown" and "reboot".

The motivation for introducing the critical-action property is that
different systems may need different thermal actions when the critical
temperature is reached.

For example, a desktop PC may want the OS to trigger a shutdown
when the critical temperature is reached.

However, in some embedded 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 benefit from this new property as it can check
the SoC temperature and in case the temperature is above the critical
point, it can trigger a shutdown or reboot accordingly.

Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes since v7:
- Made critical-action a property of the top-level thermal-zone node. (Rafael)

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

Hi Amit and Daniel,

On Fri, Sep 15, 2023 at 10:49 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> From: Fabio Estevam <festevam@denx.de>
>
> Document the critical-action property to describe the thermal action
> the OS should perform after the critical temperature is reached.
>
> The possible values are "shutdown" and "reboot".
>
> The motivation for introducing the critical-action property is that
> different systems may need different thermal actions when the critical
> temperature is reached.
>
> For example, a desktop PC may want the OS to trigger a shutdown
> when the critical temperature is reached.
>
> However, in some embedded 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 benefit from this new property as it can check
> the SoC temperature and in case the temperature is above the critical
> point, it can trigger a shutdown or reboot accordingly.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Could you please help review this series?

Thanks

On 16/09/2023 03:49, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Document the critical-action property to describe the thermal action
> the OS should perform after the critical temperature is reached.
> 
> The possible values are "shutdown" and "reboot".
> 
> The motivation for introducing the critical-action property is that
> different systems may need different thermal actions when the critical
> temperature is reached.
> 
> For example, a desktop PC may want the OS to trigger a shutdown
> when the critical temperature is reached.
> 
> However, in some embedded 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 benefit from this new property as it can check
> the SoC temperature and in case the temperature is above the critical
> point, it can trigger a shutdown or reboot accordingly.
> 
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> Changes since v7:
> - Made critical-action a property of the top-level thermal-zone node. (Rafael)
> 
>   .../devicetree/bindings/thermal/thermal-zones.yaml        | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> index 4f3acdc4dec0..d28f3fe1045d 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> @@ -48,6 +48,14 @@ properties:
>         platform-data regarding temperature thresholds and the mitigation actions
>         to take when the temperature crosses those thresholds.
>   
> +  critical-action:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description:
> +      The action the OS should perform after the critical temperature is reached.
> +    enum:
> +      - shutdown
> +      - reboot

Given I'm catching up the versions, I'll directly comment this series 
instead of the previous versions.

 From my POV, the critical action to be done is not per system, but per 
critical trip point, which is per thermal zone.

Putting the critical action at the thermal zone device level is 
inconsistent with the fact the thermal zone may not have a critical trip 
point described.

So, the property should be either:

  - In the critical trip point description as optional

Or

  - At the thermal zone level if there is a critical trip point 
described (I don't know how this dependency can be described)

>   patternProperties:
>     "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$":
>       type: object

On 16/09/2023 03:49, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Currently, the default mechanism is to trigger a shutdown after the
> critical temperature is reached.
> 
> In some embedded 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 support for allowing a reboot to be triggered after the
> critical temperature is reached.
> 
> If the "critical-action" devicetree property is not found, fall back to
> the shutdown action to preserve the existing default behavior.
> 
> Tested on a i.MX8MM board with the following devicetree changes:
> 
> 	thermal-zones {
> 		critical-action = "reboot";
> 	};
> 
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---

The changes are too invasive.

The driver can not set their own default critical callback because it 
will be overwritten by the changes. Moreover the changes should stay in 
thermal-of.

Basically in thermal_of_zone_register(... ops):

if (!ops->critical && trip->reboot)
	ops->critical = thermal_of_reboot();

That will result in:

  - if the driver does not specify its own critical ops, then if no 
action is in the trip point, we keep the old way (shutdown), if reboot 
property is set, then assign our own thermal-of-reboot function.



> Changes since v7:
> - Search for the 'critical-action' property in the parent thermal-zone node. (Rafael)
> 
>   drivers/thermal/thermal_core.c |  6 +++++-
>   drivers/thermal/thermal_of.c   | 16 ++++++++++++++++
>   include/linux/thermal.h        |  6 ++++++
>   3 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 0bdde1ab5d8b..bfa704516957 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -320,11 +320,15 @@ void thermal_zone_device_critical(struct thermal_zone_device *tz)
>   	 * Its a must for forced_emergency_poweroff_work to be scheduled.
>   	 */
>   	int poweroff_delay_ms = CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS;
> +	static const char *msg = "Temperature too high";
>
>   	dev_emerg(&tz->device, "%s: critical temperature reached, "
>   		  "shutting down\n", tz->type);
>   
> -	hw_protection_shutdown("Temperature too high", poweroff_delay_ms);
> +	if (tz->action == THERMAL_CRITICAL_ACTION_REBOOT)
> +		hw_protection_reboot(msg, poweroff_delay_ms);
> +	else
> +		hw_protection_shutdown(msg, poweroff_delay_ms);
>   }
>   EXPORT_SYMBOL(thermal_zone_device_critical);
>   
> diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
> index 4ca905723429..a1472a1965eb 100644
> --- a/drivers/thermal/thermal_of.c
> +++ b/drivers/thermal/thermal_of.c
> @@ -218,6 +218,20 @@ static struct device_node *of_thermal_zone_find(struct device_node *sensor, int
>   	return tz;
>   }
>   
> +static void thermal_of_get_critical_action(struct device_node *np,
> +					   enum thermal_action *action)
> +{
> +	const char *action_string;
> +	int ret;
> +
> +	ret = of_property_read_string(np->parent, "critical-action", &action_string);
> +	if (ret < 0)
> +		*action = THERMAL_CRITICAL_ACTION_SHUTDOWN;
> +
> +	if (!strcasecmp(action_string, "reboot"))
> +		*action = THERMAL_CRITICAL_ACTION_REBOOT;
> +}
> +
>   static int thermal_of_monitor_init(struct device_node *np, int *delay, int *pdelay)
>   {
>   	int ret;
> @@ -516,6 +530,8 @@ static struct thermal_zone_device *thermal_of_zone_register(struct device_node *
>   		goto out_kfree_trips;
>   	}
>   
> +	thermal_of_get_critical_action(np, &tz->action);
> +
>   	ret = thermal_zone_device_enable(tz);
>   	if (ret) {
>   		pr_err("Failed to enabled thermal zone '%s', id=%d: %d\n",
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index eb17495c8acc..8ea761bead79 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -34,6 +34,11 @@ struct thermal_cooling_device;
>   struct thermal_instance;
>   struct thermal_attr;
>   
> +enum thermal_action {
> +	THERMAL_CRITICAL_ACTION_SHUTDOWN = 0, /* shutdown when crit temperature is reached */
> +	THERMAL_CRITICAL_ACTION_REBOOT, /* reboot when crit temperature is reached */
> +};
> +
>   enum thermal_trend {
>   	THERMAL_TREND_STABLE, /* temperature is stable */
>   	THERMAL_TREND_RAISING, /* temperature is raising */
> @@ -183,6 +188,7 @@ struct thermal_zone_device {
>   	struct list_head node;
>   	struct delayed_work poll_queue;
>   	enum thermal_notify_event notify_event;
> +	enum thermal_action action;
>   };
>   
>   /**