| Message ID | 20231006180453.2903342-1-festevam@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Daniel Lezcano |
| Headers | show |
| Series | [v10,1/4] dt-bindings: thermal-zones: Document critical-action | expand |
Hi Daniel, On Fri, Oct 6, 2023 at 3:05 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. Are you happy with the v10 series? Thanks
On 13/10/2023 12:39, Fabio Estevam wrote: > Hi Daniel, > > On Fri, Oct 6, 2023 at 3:05 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. > > Are you happy with the v10 series? Yes, I think they are fine except one thing. The include/linux/reboot.h is changed along with thermal*.c file. IMO it is preferable to have separate patch, I mean all reboot.h changes folded in a single patch before the thermal_*.c changes. It is actually orphaned and we should ask Matti Vaittinen <mazziesaccount@gmail.com> its acked-by as he is the author of the code you are changing. Otherwise, he will have to ack the patches which contain also thermal code which is not its area.
Hi Daniel, On Sun, Oct 15, 2023 at 6:54 PM Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > > Are you happy with the v10 series? > > Yes, I think they are fine except one thing. > > The include/linux/reboot.h is changed along with thermal*.c file. IMO it > is preferable to have separate patch, I mean all reboot.h changes folded > in a single patch before the thermal_*.c changes. It is actually I tried to follow your suggestion of putting all reboot.h changes folded in a single patch before the thermal_*.c changes, but I don't think I can do this split and maintain a logic patch separation and bisectability. > orphaned and we should ask Matti Vaittinen <mazziesaccount@gmail.com> > its acked-by as he is the author of the code you are changing. > Otherwise, he will have to ack the patches which contain also thermal > code which is not its area. The reason I haven't added Matti on Cc on the series is that get_maintainer did not list him. Added him on Cc now. Maybe Matti could help acking patches 2/4 and 3/4? Full series: https://lore.kernel.org/linux-pm/20231006180453.2903342-1-festevam@gmail.com/ https://lore.kernel.org/linux-pm/20231006180453.2903342-2-festevam@gmail.com/ https://lore.kernel.org/linux-pm/20231006180453.2903342-3-festevam@gmail.com/ https://lore.kernel.org/linux-pm/20231006180453.2903342-4-festevam@gmail.com/
Hi Daniel, Now that 6.7-rc1 is out, could you please consider taking this series? Thanks On Tue, Oct 17, 2023 at 9:37 AM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Daniel, > > On Sun, Oct 15, 2023 at 6:54 PM Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: > > > > Are you happy with the v10 series? > > > > Yes, I think they are fine except one thing. > > > > The include/linux/reboot.h is changed along with thermal*.c file. IMO it > > is preferable to have separate patch, I mean all reboot.h changes folded > > in a single patch before the thermal_*.c changes. It is actually > > I tried to follow your suggestion of putting all reboot.h changes > folded in a single patch before the thermal_*.c changes, > but I don't think I can do this split and maintain a logic patch > separation and bisectability. > > > orphaned and we should ask Matti Vaittinen <mazziesaccount@gmail.com> > > its acked-by as he is the author of the code you are changing. > > Otherwise, he will have to ack the patches which contain also thermal > > code which is not its area. > > The reason I haven't added Matti on Cc on the series is that > get_maintainer did not list him. Added him on Cc now. > > Maybe Matti could help acking patches 2/4 and 3/4? > > Full series: > > https://lore.kernel.org/linux-pm/20231006180453.2903342-1-festevam@gmail.com/ > > https://lore.kernel.org/linux-pm/20231006180453.2903342-2-festevam@gmail.com/ > > https://lore.kernel.org/linux-pm/20231006180453.2903342-3-festevam@gmail.com/ > > https://lore.kernel.org/linux-pm/20231006180453.2903342-4-festevam@gmail.com/
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 4f3acdc4dec0..f88fbafecb01 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -75,6 +75,22 @@ patternProperties: framework and assumes that the thermal sensors in this zone support interrupts. + critical-action: + $ref: /schemas/types.yaml#/definitions/string + description: | + The action the OS should perform after the critical temperature is reached. + By default the system will shutdown as a safe action to prevent damage + to the hardware, if the property is not set. + The shutdown action should be always the default and preferred one. + Choose 'reboot' with care, as the hardware may be in thermal stress, + thus leading to infinite reboots that may cause damage to the hardware. + Make sure the firmware/bootloader will act as the last resort and take + over the thermal control. + + enum: + - shutdown + - reboot + thermal-sensors: $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1