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
