Re: [PATCH v8 03/10] thermal: Use generic HW-protection shutdown API

[Vaittinen, Matti]

Hi Daniel, all,

On Thu, 2021-04-22 at 10:10 +0200, Daniel Lezcano wrote:
> On 19/04/2021 13:49, Matti Vaittinen wrote:
> > The hardware shutdown function was exported from kernel/reboot for
> > other subsystems to use. Logic is copied from the thermal_core. The
> > protection mutex is replaced by an atomic_t to allow calls also
> > from
> > an IRQ context.
> > 
> > Use the exported API instead of implementing own just for the
> > thermal_core.
> 
> Can you update the documentation:
> 
> Documentation/driver-api/thermal/sysfs-api.rst
> 
> 5. thermal_emergency_poweroff
> 

I can. Problem is what to put there.

I like the fact that logic of an emergency shut-down is described. Yet,
describing in thermal_core documentation what an API hosted in
kernel/reboot does sounds like a call for documentation which may not
match implementation in the long run.

I drafted following:
diff --git a/Documentation/driver-api/thermal/sysfs-api.rst
b/Documentation/driver-api/thermal/sysfs-api.rst
index 29fdd817ddb0..a10bfe6e7293 100644
--- a/Documentation/driver-api/thermal/sysfs-api.rst
+++ b/Documentation/driver-api/thermal/sysfs-api.rst
@@ -751,20 +751,14 @@ possible.
 =============================
 
 On an event of critical trip temperature crossing. Thermal framework
-allows the system to shutdown gracefully by calling
orderly_poweroff().
-In the event of a failure of orderly_poweroff() to shut down the
system
-we are in danger of keeping the system alive at undesirably high
-temperatures. To mitigate this high risk scenario we program a work
-queue to fire after a pre-determined number of seconds to start
-an emergency shutdown of the device using the kernel_power_off()
-function. In case kernel_power_off() fails then finally
-emergency_restart() is called in the worst case.
+shuts down the system by calling hw_protection_shutdown(). The
+hw_protection_shutdown() first attempts to perform an orderly shutdown
+but accepts a delay after which it proceeds doing a forced power-off
+or an emergency_restart.
 
 The delay should be carefully profiled so as to give adequate time for
-orderly_poweroff(). In case of failure of an orderly_poweroff() the
-emergency poweroff kicks in after the delay has elapsed and shuts down
-the system.
+orderly poweroff.
 
-If set to 0 emergency poweroff will not be supported. So a carefully
-profiled non-zero positive value is a must for emergency poweroff to
be
-triggered.
+If the delay is set to 0 emergency poweroff will not be supported. So
a
+carefully profiled non-zero positive value is a must for emergency
+poweroff to be triggered.


but I'm not sure what to think about it.

Opinions/suggestions?

Best Regards
	Matti Vaittinen