linux-mips
[Top] [All Lists]

Re: [PATCH 00/11] RFC: Common machine reset handling

To: Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 00/11] RFC: Common machine reset handling
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date: Fri, 1 Nov 2013 16:12:47 +0000
Cc: Domenico Andreoli <domenico.andreoli@linux.com>, linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org, Olof Johansson <olof@lixom.net>, linux-arm-kernel@lists.infradead.org
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=caramon; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Bl81PLwMk4wuSND12wBj2JPjTOJohLjKnBl+AL+gsMU=; b=ceefJS42i9u9U/cJps4vVpF2aO6+o2EHTK9h58+wTUfr4/5slP2wpAIqqHLA/5YbD/KV/yyJ5TZbFpim8BSVc90hxKCOl+OFnD8aqqpuQNDXIR3JWMUA63hHF8c/ecd4EY3WPuxD4hKJoqmsy9Rsie30+zk8BtvsLALMPETQjFg=;
In-reply-to: <5273CFB9.1080603@wwwdotorg.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20131031062708.520968323@linux.com> <5272D05E.1070207@wwwdotorg.org> <20131101051610.GA28233@glitch> <5273CFB9.1080603@wwwdotorg.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.19 (2009-01-05)
On Fri, Nov 01, 2013 at 09:58:49AM -0600, Stephen Warren wrote:
> For PMICs that provide power off, we've been adding a property to DT to
> indicate whether the PMIC is *the* system power off controller or not.
> If the property is present, the PMIC registers itself in the poweroff
> hook. If not, it doesn't. So, there really isn't an algorithm for
> selecting the power off mechanism, but rather we designate one mechanism
> ahead of time, and that's the only one that's relevant. We could
> probably do the same for reset mechanisms.
> 
> I guess the vexpress situation is actually the same; there's a single
> concept of a custom vexpress reset, it's just that sysfs is used to
> select exactly what that does?

I'm not aware of that.  Vexpress has the following mechanisms:

- reset - this causes the system to be restarted without powering off.
- restart - this causes the system to be powered off and back on.
- poweroff - this causes the system to power off.

Obviously, poweroff is what needs to happen when someone issues the
poweroff command (or, when we get hibernate support, the power off
hook will also be called to power the system off after saving all
system state.)  So, a power off callback really better power the
system off and not reboot it.

reset vs restart is a choice, and one of those should happen as a result
of the reboot command, or other similar event which ends up requesting
a system restart.  That may be configurable.

Ultimately though, this should have no bearing on the hooking of poweroff
and restart callbacks; the only difference there is on Vexpress is the
function code passed to the system controller.

<Prev in Thread] Current Thread [Next in Thread>