Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751072AbbLHW1E (ORCPT ); Tue, 8 Dec 2015 17:27:04 -0500 Received: from mail.kernel.org ([198.145.29.136]:53371 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbbLHW1C (ORCPT ); Tue, 8 Dec 2015 17:27:02 -0500 MIME-Version: 1.0 In-Reply-To: <1449610162-30543-1-git-send-email-john.stultz@linaro.org> References: <1449610162-30543-1-git-send-email-john.stultz@linaro.org> From: Rob Herring Date: Tue, 8 Dec 2015 16:26:39 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] misc: Introduce reboot_reason driver To: John Stultz Cc: lkml , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vinay Simha BN , Bjorn Andersson , Haojian Zhuang , "devicetree@vger.kernel.org" , Android Kernel Team 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: 1642 Lines: 36 On Tue, Dec 8, 2015 at 3:29 PM, John Stultz wrote: > This patch adds a basic driver to allow for commands like > "reboot bootloader" and "reboot recovery" to communicate this > reboot-reason to the bootloader. > > This is commonly done on Android devices, in order to reboot > the device into fastboot or recovery mode. It also supports > custom OEM specific commands, via "reboot oem-". What are some examples of OEM specific commands? > This driver pulls the phys memory address from DT as well as > the magic reason values that are written to the address for > each mode. Starting with what does the h/w look like, this is typically implemented with some sort of persistent register(s) either in the SOC or PMIC. So I think persistent memory/registers is what we need to describe in DT. Perhaps this could be tied into pstore (an overkill for a single register, but useful if you already have pstore support for persistent memory)? The 2nd part is which register to use and the mapping of values to reboot reason. Do these vary within SOC families? If not, then we should just hardcode them in the reboot drivers which are already vendor specific. Also, while trying to standardize the values for reboot reason probably won't work short term, we should define something so people will start using it. We also should consider any implications with PSCI. 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/