Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752601AbbBFKe2 (ORCPT ); Fri, 6 Feb 2015 05:34:28 -0500 Received: from mail-la0-f45.google.com ([209.85.215.45]:42318 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751193AbbBFKeX (ORCPT ); Fri, 6 Feb 2015 05:34:23 -0500 MIME-Version: 1.0 In-Reply-To: <20150202163253.GG21175@leverpostej> References: <1422881149-8177-1-git-send-email-hanjun.guo@linaro.org> <1422881149-8177-9-git-send-email-hanjun.guo@linaro.org> <20150202134033.GR4278@bivouac.eciton.net> <20150202135051.GA3825@xora-haswell.xora.org.uk> <20150202163253.GG21175@leverpostej> Date: Fri, 6 Feb 2015 10:34:21 +0000 Message-ID: Subject: Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property From: G Gregory To: Mark Rutland Cc: Leif Lindholm , "hanjun.guo@linaro.org" , Catalin Marinas , "Rafael J. Wysocki" , Olof Johansson , Arnd Bergmann , "grant.likely@linaro.org" , Will Deacon , Lorenzo Pieralisi , Sudeep Holla , "jcm@redhat.com" , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Randy Dunlap , Charles Garcia-Tobin , "phoenix.liyi@huawei.com" , Timur Tabi , Ashwin Chaugule , "suravee.suthikulpanit@amd.com" , Mark Langsdorf , "wangyijing@huawei.com" , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linaro-acpi@lists.linaro.org" , Jonathan Corbet , Matt Fleming 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: 3944 Lines: 83 On 2 February 2015 at 16:32, Mark Rutland wrote: > On Mon, Feb 02, 2015 at 01:50:52PM +0000, Graeme Gregory wrote: >> On Mon, Feb 02, 2015 at 01:40:33PM +0000, Leif Lindholm wrote: >> > On Mon, Feb 02, 2015 at 08:45:36PM +0800, Hanjun Guo wrote: >> > > When system supporting both DT and ACPI but firmware providing >> > > no dtb, we can use this linux,uefi-stub-generated-dtb property >> > > to let kernel know that we can try ACPI configuration data even >> > > if no "acpi=force" is passed in early parameters. >> > > >> > > CC: Mark Rutland >> > > CC: Jonathan Corbet >> > > CC: Catalin Marinas >> > > CC: Will Deacon >> > > CC: Leif Lindholm >> > > CC: Grant Likely >> > > CC: Matt Fleming >> > > Signed-off-by: Hanjun Guo >> > > --- >> > > Documentation/arm/uefi.txt | 3 +++ >> > > arch/arm64/include/asm/acpi.h | 1 + >> > > arch/arm64/kernel/setup.c | 30 ++++++++++++++++++++++++++++++ >> > > drivers/firmware/efi/libstub/fdt.c | 8 ++++++++ >> > > 4 files changed, 42 insertions(+) >> > > >> > > diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt >> > > index d60030a..5f86eae 100644 >> > > --- a/Documentation/arm/uefi.txt >> > > +++ b/Documentation/arm/uefi.txt >> > > @@ -60,5 +60,8 @@ linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. >> > > -------------------------------------------------------------------------------- >> > > linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. >> > > -------------------------------------------------------------------------------- >> > > +linux,uefi-stub-generated-dtb | bool | Indication for no DTB provided by >> > > + | | firmware. >> > > +-------------------------------------------------------------------------------- >> > >> > Apologies for the late bikeshedding, but the discussion on this topic >> > previsously was lively enough that I thought I'd let it die down a bit >> > before seeing if I had anything to add. >> > >> > That, and I just realised something: >> > One alternative to this added DT entry is that we could treat the >> > absence of a registered UEFI configuration table as the indication >> > that no HW description was provided from firmware, since the stub does >> > not call InstallConfigurationTable() on the DT it generates. This does >> > move the ability to detect to after efi_init(), but this should be >> > fine for ACPI-purposes. >> > >> That would not work as expected in the kexec/Xen use case though as they >> may genuinely boot with DT from an ACPI host without UEFI. > > I'm a little concerned by this case. How do we intend to pass stuff from > Xen to the kernel in this case? When we initially discussed the stub > prior to merging, we weren't quite sure if ACPI without UEFI was > entirely safe. > > The linux,uefi-stub-kern-ver property was originally intended as a > sanity-check feature to ensure nothing (including Xen) masqueraded as > the stub, but for some reason the actual sanity check was never > implemented. > >> > If that is deemed undesirable, I would still prefer Catalin's >> > suggested name ("linux,bare-dtb"), which describes the state rather >> > than the route we took to get there. >> > >> I agree. > > I guess this would be ok, though it would be nice to know which agent > generated the DTB. > The most obvious scheme then is linux,bare-dtb = "uefi-stub"; otherwise we generate a new binding for every component in the boot path. Graeme -- 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/