Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753675AbbLJUYg (ORCPT ); Thu, 10 Dec 2015 15:24:36 -0500 Received: from mail.kernel.org ([198.145.29.136]:49382 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752867AbbLJUYe (ORCPT ); Thu, 10 Dec 2015 15:24:34 -0500 MIME-Version: 1.0 In-Reply-To: References: <1449610162-30543-1-git-send-email-john.stultz@linaro.org> <10759786.VG6jMebqAj@wuerfel> <1721197.gFcIQMjGvs@wuerfel> From: Rob Herring Date: Thu, 10 Dec 2015 14:24:11 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] misc: Introduce reboot_reason driver To: John Stultz Cc: Arnd Bergmann , 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: 2414 Lines: 44 On Thu, Dec 10, 2015 at 12:56 PM, John Stultz wrote: > On Thu, Dec 10, 2015 at 6:52 AM, Arnd Bergmann wrote: >> On Wednesday 09 December 2015 17:19:52 John Stultz wrote: >>> >>> If the concern is that since DT is basically ABI, one might not want >>> to have such a wide interface that specifies all the different >>> reasons, I can understand that. Though I'm really not sure how else we >>> would be able to specify the device supported the reboot reason logic >>> w/o having something in the DT (since some device may use the same soc >>> w/ the same reboot logic may use a different bootloader which doesn't >>> support the reason methods). At that point if we don't describe the >>> method clearly, it ends up being something closer to just a quirks >>> list which we'd have to map internally to behavior, which doesn't seem >>> great. >>> >>> Should we run into hardware that the proposed driver doesn't handle, >>> we can introduce a new driver for those specific semantics, but this >>> way we can share at least most of the logic, no? >> >> I think we need a layered approach, with some high-level code to >> store the boot reason, but then support firmware specific backends >> to that. If we just need a phandle for an SRAM partition and an offset >> within it, that can be done by the high-level driver, but not >> any of the more sophisticated communication methods. > > Hrm. This feels to me like over-design, though. We already have the > restart notifiers to hook into, which provide the command string. So > its just a matter of parsing the string and writing the appropriate > magic in the appropriate way (to memory, registers, efi, whatever). > The amount of code we'd be dealing with to have a front end and 3-4 > back-ends, vs having 3-4 separate drivers seems like it would almost > be the same. So why try to make a more complicated infrastructure? 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. ;) 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/