All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Wim Van Sebroeck <wim@iguana.be>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Will Deacon <Will.Deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Heiko Stuebner <heiko@sntech.de>,
	Jonas Jensen <jonas.jensen@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC PATCH 0/6] kernel: Add support for restart notifier call chain
Date: Tue, 01 Jul 2014 06:45:24 -0700	[thread overview]
Message-ID: <53B2BB74.7050300@roeck-us.net> (raw)
In-Reply-To: <20140701112413.GQ18313@arm.com>

On 07/01/2014 04:24 AM, Catalin Marinas wrote:
> On Mon, Jun 30, 2014 at 09:28:51PM +0100, Guenter Roeck wrote:
>> On Mon, Jun 30, 2014 at 08:59:47PM +0100, Russell King - ARM Linux wrote:
>>> On Mon, Jun 30, 2014 at 12:11:33PM -0700, Guenter Roeck wrote:
>>>> Various drivers implement architecture and/or device specific means
>>>> to restart (reset) the system. Various mechanisms have been implemented
>>>> to support those schemes. The best known mechanism is arm_pm_restart,
>>>> which is a function pointer to be set either from platform specific code
>>>> or from drivers. Another mechanism is to use hardware watchdogs to issue
>>>> a reset; this mechanism is used if there is no other method available
>>>> to reset a board or system. Two examples are alim7101_wdt, which currently
>>>> uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
>>>> the arm_pm_restart function.
>>>>
>>>> The existing mechanisms have a number of drawbacks. Typically only one scheme
>>>> to restart the system is supported (at least if arm_pm_restart is used).
>>>> At least in theory there can be mutliple means to restart the system, some of
>>>> which may be less desirable (for example one mechanism may only reset the CPU,
>>>> while another may reset the entire system). Using arm_pm_restart can also be
>>>> racy if the function pointer is set from a driver, as the driver may be in
>>>> the process of being unloaded when arm_pm_restart is called.
>>>> Using the reboot notifier is always racy, as it is unknown if and when
>>>> other functions using the reboot notifier have completed execution
>>>> by the time the watchdog fires.
>>>>
>>>> To solve the problem, introduce a system restart notifier. This notifier
>>>> is expected to be called from the architecture specific machine_restart()
>>>> function. Drivers providing system restart functionality (such as the watchdog
>>>> drivers mentioned above) are expected to register with this notifier.
>>>>
>>>> Patch 1 of this series implements the notifier function. Patches 2 and 3
>>>> implement calling the notifier chain from arm and arm64 restart code.
>>>> Patch 4 and 5 convert existing restart handlers in the watchdog subsystem
>>>> to use the restart notifier. Patch 6 unexports arm_pm_restart to ensure
>>>> that no one gets the idea to implement a restart handler as module.
>>>
>>> I think you need to restructure stuff somewhat, because I think
>>> you've missed drivers/power/reset/ entirely, or at least you've
>>> missed drivers/power/reset/restart-poweroff.c which calls
>>> arm_pm_restart directly.  I'm not quite sure how we ended up with
>>> that...
>>
>> Yes, guess I missed (and did not really expect) that arm_pm_restart
>> is called from multiple places.
>
> Most of the ARM-specific code in drivers/power/reset/ consists of SoC
> power-off/restart back-ends (e.g. vexpress-poweroff.c). Since there is
> no generic pm_restart, we continued to use arm_pm_restart (also for
> arm64 since we share some of the drivers). Maybe some driver model here
> would help.
>
>> What is restart-poweroff supposed to do in the first place, and why
>> doesn't it call machine_restart() ? If it is what I think it is, ie
>> a fallback for pm_power_off, it could be made generic and does not
>> really have to depend on ARM.
>
> I think this one pretends to do a power-off via restart. It could call
> machine_restart() but this only passes the default reboot_mode to
> arm_pm_restart().
>

Unless one sets reboot_mode first. See my proposed patch in
https://lkml.org/lkml/2014/6/30/792.

Guenter


WARNING: multiple messages have this Message-ID (diff)
From: linux@roeck-us.net (Guenter Roeck)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/6] kernel: Add support for restart notifier call chain
Date: Tue, 01 Jul 2014 06:45:24 -0700	[thread overview]
Message-ID: <53B2BB74.7050300@roeck-us.net> (raw)
In-Reply-To: <20140701112413.GQ18313@arm.com>

On 07/01/2014 04:24 AM, Catalin Marinas wrote:
> On Mon, Jun 30, 2014 at 09:28:51PM +0100, Guenter Roeck wrote:
>> On Mon, Jun 30, 2014 at 08:59:47PM +0100, Russell King - ARM Linux wrote:
>>> On Mon, Jun 30, 2014 at 12:11:33PM -0700, Guenter Roeck wrote:
>>>> Various drivers implement architecture and/or device specific means
>>>> to restart (reset) the system. Various mechanisms have been implemented
>>>> to support those schemes. The best known mechanism is arm_pm_restart,
>>>> which is a function pointer to be set either from platform specific code
>>>> or from drivers. Another mechanism is to use hardware watchdogs to issue
>>>> a reset; this mechanism is used if there is no other method available
>>>> to reset a board or system. Two examples are alim7101_wdt, which currently
>>>> uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
>>>> the arm_pm_restart function.
>>>>
>>>> The existing mechanisms have a number of drawbacks. Typically only one scheme
>>>> to restart the system is supported (at least if arm_pm_restart is used).
>>>> At least in theory there can be mutliple means to restart the system, some of
>>>> which may be less desirable (for example one mechanism may only reset the CPU,
>>>> while another may reset the entire system). Using arm_pm_restart can also be
>>>> racy if the function pointer is set from a driver, as the driver may be in
>>>> the process of being unloaded when arm_pm_restart is called.
>>>> Using the reboot notifier is always racy, as it is unknown if and when
>>>> other functions using the reboot notifier have completed execution
>>>> by the time the watchdog fires.
>>>>
>>>> To solve the problem, introduce a system restart notifier. This notifier
>>>> is expected to be called from the architecture specific machine_restart()
>>>> function. Drivers providing system restart functionality (such as the watchdog
>>>> drivers mentioned above) are expected to register with this notifier.
>>>>
>>>> Patch 1 of this series implements the notifier function. Patches 2 and 3
>>>> implement calling the notifier chain from arm and arm64 restart code.
>>>> Patch 4 and 5 convert existing restart handlers in the watchdog subsystem
>>>> to use the restart notifier. Patch 6 unexports arm_pm_restart to ensure
>>>> that no one gets the idea to implement a restart handler as module.
>>>
>>> I think you need to restructure stuff somewhat, because I think
>>> you've missed drivers/power/reset/ entirely, or at least you've
>>> missed drivers/power/reset/restart-poweroff.c which calls
>>> arm_pm_restart directly.  I'm not quite sure how we ended up with
>>> that...
>>
>> Yes, guess I missed (and did not really expect) that arm_pm_restart
>> is called from multiple places.
>
> Most of the ARM-specific code in drivers/power/reset/ consists of SoC
> power-off/restart back-ends (e.g. vexpress-poweroff.c). Since there is
> no generic pm_restart, we continued to use arm_pm_restart (also for
> arm64 since we share some of the drivers). Maybe some driver model here
> would help.
>
>> What is restart-poweroff supposed to do in the first place, and why
>> doesn't it call machine_restart() ? If it is what I think it is, ie
>> a fallback for pm_power_off, it could be made generic and does not
>> really have to depend on ARM.
>
> I think this one pretends to do a power-off via restart. It could call
> machine_restart() but this only passes the default reboot_mode to
> arm_pm_restart().
>

Unless one sets reboot_mode first. See my proposed patch in
https://lkml.org/lkml/2014/6/30/792.

Guenter

  reply	other threads:[~2014-07-01 13:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 19:11 [RFC PATCH 0/6] kernel: Add support for restart notifier call chain Guenter Roeck
2014-06-30 19:11 ` Guenter Roeck
2014-06-30 19:11 ` [RFC PATCH 1/6] " Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-06-30 19:11 ` [RFC PATCH 2/6] arm64: Support restart through " Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-07-01  7:26   ` Maxime Ripard
2014-07-01  7:26     ` Maxime Ripard
2014-07-01 13:39     ` Guenter Roeck
2014-07-01 13:39       ` Guenter Roeck
2014-06-30 19:11 ` [RFC PATCH 3/6] arm: " Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-06-30 19:55   ` Russell King - ARM Linux
2014-06-30 19:55     ` Russell King - ARM Linux
2014-06-30 19:11 ` [RFC PATCH 4/6] watchdog: moxart: Register restart handler with restart notifier Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-06-30 19:11 ` [RFC PATCH 5/6] watchdog: alim7101: " Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-06-30 19:11 ` [RFC PATCH 6/6] arm/arm64: Unexport restart handlers Guenter Roeck
2014-06-30 19:11   ` Guenter Roeck
2014-06-30 19:59 ` [RFC PATCH 0/6] kernel: Add support for restart notifier call chain Russell King - ARM Linux
2014-06-30 19:59   ` Russell King - ARM Linux
2014-06-30 20:28   ` Guenter Roeck
2014-06-30 20:28     ` Guenter Roeck
2014-07-01 11:24     ` Catalin Marinas
2014-07-01 11:24       ` Catalin Marinas
2014-07-01 13:45       ` Guenter Roeck [this message]
2014-07-01 13:45         ` Guenter Roeck
2014-07-01 17:08         ` Catalin Marinas
2014-07-01 17:08           ` Catalin Marinas

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=53B2BB74.7050300@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Will.Deacon@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=dbaryshkov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=heiko@sntech.de \
    --cc=jonas.jensen@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=maxime.ripard@free-electrons.com \
    --cc=mingo@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=wim@iguana.be \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.