Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755614AbcCXQQP (ORCPT <rfc822;w@1wt.eu>);
	Thu, 24 Mar 2016 12:16:15 -0400
Received: from mga11.intel.com ([192.55.52.93]:62538 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751834AbcCXQQC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 24 Mar 2016 12:16:02 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,385,1455004800"; 
   d="scan'208";a="72588578"
From: "Stanacar, Stefan" <stefan.stanacar@intel.com>
To: "matt@codeblueprint.co.uk" <matt@codeblueprint.co.uk>
CC: "Baluta, Daniel" <daniel.baluta@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "dvhart@infradead.org" <dvhart@infradead.org>,
        "Gumbel, Matthew K" <matthew.k.gumbel@intel.com>,
        "Purdila, Octavian" <octavian.purdila@intel.com>,
        "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
        "Abbas, Mohamed" <mohamed.abbas@intel.com>,
        "Musca, Constantin" <constantin.musca@intel.com>
Subject: Re: [PATCH v2] efi: Introduce EFI bootloader control driver
Thread-Topic: [PATCH v2] efi: Introduce EFI bootloader control driver
Thread-Index: AQHRgP4gz9DmkaiYq0aye7ci0K473J9fYK2AgAAzMICACSJigIAAGKgA
Date: Thu, 24 Mar 2016 16:15:56 +0000
Message-ID: <1458836156.14677.9.camel@intel.com>
References: <1458295910-26557-1-git-send-email-daniel.baluta@intel.com>
	 <20160318161505.GU2619@codeblueprint.co.uk>
	 <1458328697.16385.21.camel@intel.com>
	 <20160324144741.GA4328@codeblueprint.co.uk>
In-Reply-To: <20160324144741.GA4328@codeblueprint.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.237.105.93]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C2571A392F1B1B42AB243AAD2A30123D@intel.com>
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u2OGGIiZ028391
Content-Length: 2181
Lines: 61

On Thu, 2016-03-24 at 14:47 +0000, Matt Fleming wrote:
> (Sorry for the delay)
> 
> On Fri, 18 Mar, at 07:18:17PM, Stanacar, Stefan wrote:
> > 
> > 
> > Hi Matt,
> > 
> > It is possible, but that means modifying those userspace apps :)
> > There are reboot implementations that do "reboot <reason>", such as
> > Android's reboot command [1] and Upstart's reboot replacement [2],
> > which
> > pass the reason as an argument to the reboot syscall. 
> > Probably your first question will be - "Why don't you modify those
> > apps?"
> Your guess is correct ;)
> 
> > 
> > Well, I don't see platform-agnostic way how those could be
> > modified to pass the reason to the bootloader, regardless of
> > platform or
> > bootloader.
> This is true. But then again, what you're proposing isn't boot loader
> or platform agnostic anyway. Yes it's transparent to both the app and
> boot loader, but it's only going to work on EFI platforms running
> gummiboot.

Yup, that's true. It's going to work only on EFI platforms. The
bootloader actually doesn't matter (any efi bootloader should work) as
long as it reads the reason and does what's supposed to do with it (boot
in recovery, etc)

> 
> And because of that, if this is going to be merged upstream I think
> something like drivers/power/reset/ would be a more appropriate place,
> or drivers/platform/x86.
> 

Agreed. It seems that drivers/power/reset is preferred by ARM boards:
https://git.linaro.org/people/john.stultz/flo.git/commit/f1e712be2be9f42
97215fc4af6194e0f75f05dfb


> If this does get merged, please rework the patch to use the efivar API
> instead of accessing efi.set_variable() directly. We've also got a
> bunch of ucs2 string functions in lib/ucs2_string.c that you could

Ok.

> use. In fact, this version of the driver I found on the net is much
> more like what I had in mind,
> 
>   https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/dr
> ivers/external_drivers/drivers/platform/x86/reboot_target_uefi.c

Ok, that's funny somehow... I wouldn't be surprised if I'd find 3 more
variations of the same driver in different vendor trees :(.
I'll ping the author of the patch, thanks!

Cheers,
Stefan