On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote:

On 10/29/2014 05:34 AM, Johan Hovold wrote:

quoted

On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:

quoted

On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:

quoted

That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.

So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?

And how is that different from having a set of power-off handlers, and
reporting when each individual one fails?  Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?

Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).

Good that I just replaced notifier chain with an open coded implementation.

Good to hear.

Sure, that is possible, but I would prefer to do that as a follow-up commit,
and it should be discussed in the context of the power-off handler patch set.

Fine with me.

quoted

And what about any power-off latencies? Should this always be dealt with
in the power-off handler?

Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?

Should there always be a short delay before calling the next handler?

That delay would depend on the individual power-off handler, so I think
the current implementation works just fine (where power-off handlers
implement the delay).

Some don't, and could possibly unknowingly have been relying on the fact
that they could return to user space and be powered off at some later
time. With systemd that would have caused a panic.

Also consider generic power-off handlers such as gpio-poweroff. It
currently hard-codes a three-second delay but the actual delay would
really be board specific.

We could move the delay into the infrastructure, but it would have
to be configurable. I would prefer to consider that as a follow-up patch
to not overload the power-off handler patch set with too many changes
at the same time.

Sure.

Johan