Linux-ARM-MSM Archive on lore.kernel.org
 help / color / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
Cc: "josef@toxicpanda.com" <josef@toxicpanda.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"pmladek@suse.com" <pmladek@suse.com>,
	linux-power <linux-power@fi.rohmeurope.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"kai.heng.feng@canonical.com" <kai.heng.feng@canonical.com>,
	"mcroce@microsoft.com" <mcroce@microsoft.com>,
	"amitk@kernel.org" <amitk@kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
	"agross@kernel.org" <agross@kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH v8 03/10] thermal: Use generic HW-protection shutdown API
Date: Thu, 22 Apr 2021 09:27:37 +0000
Message-ID: <13ede9c1a755300f90c0e2f454cb12ee7a89e3ac.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <c9b61f91-301b-92a2-f5e7-e8b8e2373040@linaro.org>

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


  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 11:46 [PATCH v8 00/10] Extend regulator notification support Matti Vaittinen
2021-04-19 11:48 ` [PATCH v8 01/10] dt_bindings: Add protection limit properties Matti Vaittinen
2021-04-19 11:48 ` [PATCH v8 02/10] reboot: Add hardware protection power-off Matti Vaittinen
2021-04-19 11:49 ` [PATCH v8 03/10] thermal: Use generic HW-protection shutdown API Matti Vaittinen
2021-04-22  8:10   ` Daniel Lezcano
2021-04-22  9:27     ` Vaittinen, Matti [this message]
2021-04-19 11:49 ` [PATCH v8 04/10] regulator: add warning flags Matti Vaittinen
2021-04-19 11:50 ` [PATCH v8 05/10] regulator: IRQ based event/error notification helpers Matti Vaittinen
2021-04-19 11:50 ` [PATCH v8 06/10] regulator: add property parsing and callbacks to set protection limits Matti Vaittinen
2021-04-19 11:50 ` [PATCH v8 07/10] dt-bindings: regulator: bd9576 add FET ON-resistance for OCW Matti Vaittinen
2021-04-19 11:51 ` [PATCH v8 08/10] regulator: bd9576: Support error reporting Matti Vaittinen
2021-04-19 11:51 ` [PATCH v8 09/10] regulator: bd9576: Fix the driver name in id table Matti Vaittinen
2021-04-19 11:52 ` [PATCH v8 10/10] MAINTAINERS: Add reviewer for regulator irq_helpers Matti Vaittinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13ede9c1a755300f90c0e2f454cb12ee7a89e3ac.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=agross@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=amitk@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=keescook@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-power@fi.rohmeurope.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mcroce@microsoft.com \
    --cc=pmladek@suse.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robh+dt@kernel.org \
    --cc=rppt@kernel.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-MSM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-msm/0 linux-arm-msm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-msm linux-arm-msm/ https://lore.kernel.org/linux-arm-msm \
		linux-arm-msm@vger.kernel.org
	public-inbox-index linux-arm-msm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-arm-msm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git