public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: linux@roeck-us•net (Guenter Roeck)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v7 00/11] kernel: Add support for restart handler call chain
Date: Sat, 23 Aug 2014 17:17:55 -0700	[thread overview]
Message-ID: <53F92F33.3040704@roeck-us.net> (raw)
In-Reply-To: <1868939.JnM9WCSHq4@diego>

On 08/23/2014 04:00 PM, Heiko St?bner wrote:
> Am Samstag, 23. August 2014, 09:35:05 schrieb Guenter Roeck:
>> On Tue, Aug 19, 2014 at 05:45:27PM -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. Several other restart drivers for
>>> arm, all directly calling arm_pm_restart, are in the process of being
>>> integrated into the kernel. All those drivers would benefit from the new
>>> API.
>>>
>>> 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 multiple 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.
>>>
>>> Introduce a system restart handler call chain to solve the described
>>> problems. This call chain is expected to be executed 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 call chain. By using the
>>> priority field in the notifier block, callers can control restart handler
>>> execution sequence and thus ensure that the restart handler with the
>>> optimal restart capabilities for a given system is called first.
>>>
>>> Since the first revision of this patchset, a number of separate patch
>>> submissions have been made which either depend on it or could make use of
>>> it.
>>>
>>> http://www.spinics.net/linux/lists/arm-kernel/msg344796.html
>>>
>>> 	registers three notifiers.
>>>
>>> https://lkml.org/lkml/2014/7/8/962
>>>
>>> 	would benefit from it.
>>>
>>> Patch 1 of this series implements the restart handler function. Patches 2
>>> and 3 implement calling the restart handler chain from arm and arm64
>>> restart code.
>>>
>>> Patch 4 modifies the restart-poweroff driver to no longer call
>>> arm_pm_restart directly but machine_restart. This is done to avoid
>>> calling arm_pm_restart from more than one place. The change makes the
>>> driver architecture independent, so it would be possible to drop the arm
>>> dependency from its Kconfig entry.
>>>
>>> Patch 5 and 6 convert existing restart handlers in the watchdog subsystem
>>> to use the restart handler. Patch 7 unexports arm_pm_restart to ensure
>>> that no one gets the idea to implement a restart handler as module.
>>>
>>> The entire patch series, including additional patches depending on it,
>>> is available from
>>> https://git.kernel.org/cgit/linux/kernel/git/groeck/linux-staging.git/
>>> in branch 'restart-staging'.
>>
>> Hi Andrew,
>>
>> I think this series is ready for upstream integration. Question now
>> is how we should proceed to get it actually integrated.
>>
>> I can see a number of options:
>> - You take patch #1, the rest goes in through maintainer trees.
>
> I don't think you can split the patches like this. Patch1 introduces
> (un)register_restart_handler functions used by later patches in the series.
> You therefore cannot really split the series, as otherwise you would get build
> failures in the individual trees.
>
No, it would simply delay integration of the entire series by a release
or two. First two patches go in first, then #3 and #4, then the rest.

I don't like that option too much either, but it is better than nothing.

Guenter

  reply	other threads:[~2014-08-24  0:17 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20  0:45 [PATCH v7 00/11] kernel: Add support for restart handler call chain Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 01/11] kernel: Add support for kernel " Guenter Roeck
2014-08-21  4:08   ` Doug Anderson
2014-08-20  0:45 ` [PATCH v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart Guenter Roeck
2014-08-21  4:10   ` Doug Anderson
2014-08-21  4:42     ` Guenter Roeck
2014-08-21 19:30       ` Doug Anderson
2014-08-21 20:11         ` Guenter Roeck
2014-08-21 20:39   ` Sebastian Reichel
2014-08-23 17:20     ` Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 03/11] arm64: Support restart through restart handler call chain Guenter Roeck
2014-08-21  4:13   ` Doug Anderson
2014-08-20  0:45 ` [PATCH v7 04/11] arm: " Guenter Roeck
2014-08-21  4:11   ` Doug Anderson
2014-08-22  1:32   ` Andreas Färber
2014-08-22  2:19     ` Guenter Roeck
2014-08-23 17:11       ` Andreas Färber
2014-08-20  0:45 ` [PATCH v7 05/11] watchdog: moxart: Register restart handler with kernel restart handler Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 06/11] watchdog: alim7101: " Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 07/11] watchdog: sunxi: " Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 08/11] arm/arm64: Unexport restart handlers Guenter Roeck
2014-08-21  4:12   ` Doug Anderson
2014-12-04 13:36   ` Geert Uytterhoeven
2014-12-04 14:26     ` Guenter Roeck
2014-12-04 14:44       ` Geert Uytterhoeven
2014-12-04 14:51         ` Guenter Roeck
2014-12-04 15:06           ` Arnd Bergmann
2014-12-04 16:11             ` Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 09/11] watchdog: s3c2410: add restart handler Guenter Roeck
2014-08-20  0:45 ` [PATCH v7 10/11] clk: samsung: register restart handlers for s3c2412 and s3c2443 Guenter Roeck
2014-09-03 19:05   ` Mike Turquette
2014-08-20  0:45 ` [PATCH v7 11/11] clk: rockchip: add restart handler Guenter Roeck
2014-08-21  4:15   ` Doug Anderson
2014-08-21  8:18     ` Heiko Stübner
2014-09-03 19:05   ` Mike Turquette
2014-08-23 16:35 ` [PATCH v7 00/11] kernel: Add support for restart handler call chain Guenter Roeck
2014-08-23 23:00   ` Heiko Stübner
2014-08-24  0:17     ` Guenter Roeck [this message]
2014-09-19 12:54 ` Pramod Gurav
2014-09-30 21:20 ` Andrew Morton
2014-09-30 22:30   ` Guenter Roeck
2014-09-30 23:40     ` Stephen Rothwell
2014-10-01  3:28       ` Guenter Roeck
2014-10-01 13:32     ` Heiko Stübner

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=53F92F33.3040704@roeck-us.net \
    --to=linux@roeck-us$(echo .)net \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox