diff mbox series

[v5,1/2] dt-bindings: imx8mm-thermal: Document nxp,reboot-on-critical

Message ID 20230824165011.569386-1-festevam@gmail.com
State New
Headers show
Series [v5,1/2] dt-bindings: imx8mm-thermal: Document nxp,reboot-on-critical | expand

Commit Message

Fabio Estevam Aug. 24, 2023, 4:50 p.m. UTC
From: Fabio Estevam <festevam@denx.de>

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.

Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v4:
- None. Went back to using device tree property.

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

Comments

Krzysztof Kozlowski Aug. 24, 2023, 5:51 p.m. UTC | #1
On 24/08/2023 18:50, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> 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.
> 
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Changes since v4:
> - None. Went back to using device tree property.
> 
>  .../devicetree/bindings/thermal/imx8mm-thermal.yaml         | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
> index d2c1e4573c32..9ac70360fd35 100644
> --- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
> @@ -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

It still does not scale. If it is supposed to be DT property, you need
to solve my concerns of relying on specific implementation.

First, you need to cover all possible actions, not reverse existing OS
implementation. As I said before, If Linux decides to reboot by default,
this property becomes useless. No, it must be some sort of enum defining
desired allowed action or actions.

Second, I don't think this is specific to this particular device, so
should be rather common property shared among all thermal handlers (and
in the future any other critical-condition-handler-devices).

Best regards,
Krzysztof
Fabio Estevam Aug. 24, 2023, 9:17 p.m. UTC | #2
Hi Krzysztof,

On Thu, Aug 24, 2023 at 2:51 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> It still does not scale. If it is supposed to be DT property, you need
> to solve my concerns of relying on specific implementation.
>
> First, you need to cover all possible actions, not reverse existing OS
> implementation. As I said before, If Linux decides to reboot by default,
> this property becomes useless. No, it must be some sort of enum defining
> desired allowed action or actions.
>
> Second, I don't think this is specific to this particular device, so
> should be rather common property shared among all thermal handlers (and
> in the future any other critical-condition-handler-devices).

I got your point and it makes sense.

I tested locally with a common DT property like this:

index 4f3acdc4dec0..782cbb4ea487 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -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
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
index d2c1e4573c32..9ac70360fd35 100644
--- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
@@ -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