From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9423CC4321E for ; Sun, 9 Sep 2018 15:55:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0309420833 for ; Sun, 9 Sep 2018 15:55:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="ODpDdDFm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0309420833 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726789AbeIIUqC (ORCPT ); Sun, 9 Sep 2018 16:46:02 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:32833 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726598AbeIIUqC (ORCPT ); Sun, 9 Sep 2018 16:46:02 -0400 Received: by mail-io1-f66.google.com with SMTP id r196-v6so5082329iod.0 for ; Sun, 09 Sep 2018 08:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fZKF5r8urd2yVRiHJG51pNBja/4zKr/DhfLHNDlE0Us=; b=ODpDdDFmvRYLDnnkS0F8MmTQ+Riq/h24Fhky2ybrKZfVFZNsV6vdLQ1B3VsRGk9c9N N1eR7jO2JEw0+ahKMmh4PW6/YEqLlk75vlCP1Cy1uh+Q5V8xdtkRol3z7hedybsmDSUD CHW3C5SK7A2Q4h1I6Zcp1XrY7j7i6n/j046S4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fZKF5r8urd2yVRiHJG51pNBja/4zKr/DhfLHNDlE0Us=; b=XWBRS7pmCpcJwVXP8zfFNNmtpybMaTsv7QjCyCr3E+yW7i3DKqxFKIjXHXfolm3O6A LvFGYRxgBvJtY/G4QIj7fcILcqZ4MYO+hSWNwVcYmu4leCmqRC/g6EUJ91tkTInUmkE/ kmgYbDendjxcClJvEI7DmtmHVlBh4YviLVgRRpAZVCGHK/x3S4dBbcdl6wk0PfCORPxP fJBE0Rj+rlFMICpns1M/Ahjmbu/4Ac9P4DTn3QFTNcDXt4ZMGMkWB9zbaCmlVAxS0MII vG9H8IGeWhIN0aWbaMfG2Md4Ws1CbRUCL6FI5tFnef4gnBMoiywZ/qdO+cBZFKkOUnJc xK7Q== X-Gm-Message-State: APzg51AoJwBVQLpDaS8pbIshxCJwIP9eKUQC2dNRJziVc8GLQsMz0XMy zt1w5zNhn2ctw5nikJfkl8spboaGvWDbDn8btkWfOw== X-Google-Smtp-Source: ANB0VdZyN97goDDaJS7PZB60rpV7melQW1+ASjDA929brsNBLbGsbHWT0hajClOQmib8sd2Waq5xR0AlDvXIRO3W9OU= X-Received: by 2002:a6b:4516:: with SMTP id s22-v6mr14360138ioa.60.1536508556327; Sun, 09 Sep 2018 08:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Sun, 9 Sep 2018 08:55:55 -0700 (PDT) In-Reply-To: <20180909110732.GA63296@iMac.local> References: <1f8095f1-1f0c-0791-31c4-c7b986c4ce1f@broadcom.com> <20180909110732.GA63296@iMac.local> From: Ard Biesheuvel Date: Sun, 9 Sep 2018 17:55:55 +0200 Message-ID: Subject: Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER To: Catalin Marinas Cc: Scott Branden , Grant Likely , Arnd Bergmann , Will Deacon , Linux Kernel Mailing List , Leif Lindholm , Alexander Graf , BCM Kernel Feedback , Olof Johansson , Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9 September 2018 at 13:07, Catalin Marinas wrote: > On Wed, Sep 05, 2018 at 11:04:36AM -0700, Scott Branden wrote: >> On 18-09-05 11:00 AM, Grant Likely wrote: >> > On Wed, Sep 5, 2018 at 6:27 PM Scott Branden wrote: >> > > On 18-09-05 02:40 AM, Ard Biesheuvel wrote: >> > > > On 4 September 2018 at 19:19, Scott Branden wrote: >> > > > > Rather than introduce EFI_ARMSTUB_DTB_LOADER, why not have >> > > > > the efistub use CONFIG_OF to determine whether it supports dtb= or not? >> > > > > >> > > > > That way ACPI-only distros disable devicetree support entirely. >> > > > > >> > > > Unfortunately, CONFIG_OF cannot be disabled on arm64 even on ACPI-only builds. >> > > OF shouldn't be automatically selected in the arm64/Kconfig. It should >> > > have a config parmaeter like other archs as mips and arm. I can >> > > submit a patch so it functions the same way as other archs so it >> > > is not always selected. It will be good to add a USE_OF config >> > > options like the other archs (or simply remove the select from the >> > > Kconfig and choose OF directly in the defconfig. This will have >> > > the added benefit of doing away with OF support when its not >> > > needed on an ARM64 platform. ACPI is already not automatically >> > > selected for all ARM64 platforms, nor should devicetree. >> > We don't do that on Arm because a devicetree is always required at >> > boot time. Even on ACPI systems a tiny DTB is used containing just a >> > /chosen node for passing the kernel command line and the initrd >> > location. >> >> Seems bizarre DTB is not needed for x86 to boot from UEFI with ACPI >> support? I'll look into it further at some point in order to remove such >> anomaly. There should be no need for such devicetree reliance. > > I'd say don't waste time on this, the patch would not get merged ;). As > Grant said, we use a tiny dtb to pass the command line, initrd to the > kernel. You'd have to invent an alternative (setup_header, ATAGs) and I > really don't see the point of increased complexity just because of some > philosophical arguments against OF. > Not just that: we also need of_match_table support for ACPI's PRP0001 device (which is a horrible hack in itself, but currently supported in Linux/arm64 *and* Linux/x86 nonetheless) From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Sun, 9 Sep 2018 17:55:55 +0200 Subject: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER In-Reply-To: <20180909110732.GA63296@iMac.local> References: <1f8095f1-1f0c-0791-31c4-c7b986c4ce1f@broadcom.com> <20180909110732.GA63296@iMac.local> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 9 September 2018 at 13:07, Catalin Marinas wrote: > On Wed, Sep 05, 2018 at 11:04:36AM -0700, Scott Branden wrote: >> On 18-09-05 11:00 AM, Grant Likely wrote: >> > On Wed, Sep 5, 2018 at 6:27 PM Scott Branden wrote: >> > > On 18-09-05 02:40 AM, Ard Biesheuvel wrote: >> > > > On 4 September 2018 at 19:19, Scott Branden wrote: >> > > > > Rather than introduce EFI_ARMSTUB_DTB_LOADER, why not have >> > > > > the efistub use CONFIG_OF to determine whether it supports dtb= or not? >> > > > > >> > > > > That way ACPI-only distros disable devicetree support entirely. >> > > > > >> > > > Unfortunately, CONFIG_OF cannot be disabled on arm64 even on ACPI-only builds. >> > > OF shouldn't be automatically selected in the arm64/Kconfig. It should >> > > have a config parmaeter like other archs as mips and arm. I can >> > > submit a patch so it functions the same way as other archs so it >> > > is not always selected. It will be good to add a USE_OF config >> > > options like the other archs (or simply remove the select from the >> > > Kconfig and choose OF directly in the defconfig. This will have >> > > the added benefit of doing away with OF support when its not >> > > needed on an ARM64 platform. ACPI is already not automatically >> > > selected for all ARM64 platforms, nor should devicetree. >> > We don't do that on Arm because a devicetree is always required at >> > boot time. Even on ACPI systems a tiny DTB is used containing just a >> > /chosen node for passing the kernel command line and the initrd >> > location. >> >> Seems bizarre DTB is not needed for x86 to boot from UEFI with ACPI >> support? I'll look into it further at some point in order to remove such >> anomaly. There should be no need for such devicetree reliance. > > I'd say don't waste time on this, the patch would not get merged ;). As > Grant said, we use a tiny dtb to pass the command line, initrd to the > kernel. You'd have to invent an alternative (setup_header, ATAGs) and I > really don't see the point of increased complexity just because of some > philosophical arguments against OF. > Not just that: we also need of_match_table support for ACPI's PRP0001 device (which is a horrible hack in itself, but currently supported in Linux/arm64 *and* Linux/x86 nonetheless)