Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752427AbbLNPXJ (ORCPT ); Mon, 14 Dec 2015 10:23:09 -0500 Received: from mail.kernel.org ([198.145.29.136]:38937 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368AbbLNPXG (ORCPT ); Mon, 14 Dec 2015 10:23:06 -0500 MIME-Version: 1.0 In-Reply-To: <1552521.IZhVsTdxHT@wuerfel> References: <1449610162-30543-1-git-send-email-john.stultz@linaro.org> <1552521.IZhVsTdxHT@wuerfel> From: Rob Herring Date: Mon, 14 Dec 2015 09:22:41 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] misc: Introduce reboot_reason driver To: Arnd Bergmann Cc: John Stultz , Bjorn Andersson , lkml , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vinay Simha BN , Haojian Zhuang , "devicetree@vger.kernel.org" , Android Kernel Team , Andy Gross , "linux-arm-msm@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2242 Lines: 53 On Thu, Dec 10, 2015 at 4:11 PM, Arnd Bergmann wrote: > On Thursday 10 December 2015 13:43:16 John Stultz wrote: >> On Thu, Dec 10, 2015 at 12:24 PM, Rob Herring wrote: >> > The fact that we are using notifiers for reset reason and triggering >> > is probably some indication that some infrastructure is needed. But I >> > don't think you need to do that here as long as it is all kernel >> > internals. We'll make the 2nd guy do it. >> >> >> >> Though, just so I understand better, what is problematic w/ the reset >> notifiers? They provide the reboot command argument, which is the core >> of what is needed. It actually seemed like it was almost designed with >> this problem in mind. > > Notifiers in general are a bit of a kludge. We often use them in places > that have not been abstracted well enough yet, and they make it > less obvious what is actually going on when something happens, or > in what order things are called. Exactly. > I'm actually less worried about the notifier side here than about > the general problem of the communication channel. The reboot reason > is only one of a number of things that the kernel needs to communicate > to the boot loader. Other things may include: If only there was a standard interface for firmware variable storage... > - boot device > - location of the kernel > - command line > - properties of the /chosen DT node in general > - boot scripts > - ethernet MAC addresses > - bootloader console configuration A major distinction here is many of these would be persistent (i.e. in flash). As much of this goes into to the DT anyway, a standard way for userspace to update the DT could solve this. That would not really work for handling a one time case unless you supported boot with an alternate DT. I've also seen storing of SD tuning parameters to avoid tuning at boot up. Although, the tuning doesn't add that much to the boot time relative to Android boot, so I don't really see the point. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/