On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote: > On 10/29/2014 05:34 AM, Johan Hovold wrote: > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote: > >> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote: > >>> 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
