On Wed, Oct 29, 2014 at 04:51:09PM +0100, Johan Hovold wrote:

On Wed, Oct 29, 2014 at 08:25:02AM -0700, Guenter Roeck wrote:

quoted

On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote:

quoted

On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:

quoted

On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:

quoted

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

quoted

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).

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?

If the handler has determined that it has failed, then why delay before
trying the next handler?  At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?

The current handlers we have are not expecting any other handler to be
run after they return. My question was whether all these handlers should
get a short mdelay added to them (e.g. to compensate for bus latencies)

Some of them do add a delay.

Yes, but not all.

quoted

quoted

or if this could be done in the power-off handler (e.g. before printing
the error message).

That might make sense, but it would have to be configurable, since the delay
is platform specific and power-off handler does not know how long to wait
(the longest delay I have seen is 10 seconds).

We've already concluded in this thread that such delays must be encoded
in the actual handler (even if it's an argument to the power-off call
chain code). The only exception should be generic handlers such as
gpio-poweroff, which may need to define different delays depending on
board. This could of course just be an argument of the corresponding DT
node.

There probably should be a generic device-tree property for this, even
if some delays would be device specific (e.g. the two second delay for
omap rtc).

But on top of that, external latencies would be quite board specific.
The PMIC on the Beaglebone black adds a 50ms deglitch time, for
instance.

My question above was if it was reasonable to add some generic short
delay after calling each power-off handler to handle short power-off
latencies (e.g. bus latencies) so that not every handler needs an
explicit delay.

I just added a 500ms margin to the OMAP rtc power-off handler. That
should be more than enough, and perhaps something like that could be a
default in the power-off call chain. Consider that arch-arm has a 1s
grace period before reporting failed reboot already today.

Johan