From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER
Date: Sun, 9 Sep 2018 12:07:33 +0100 [thread overview]
Message-ID: <20180909110732.GA63296@iMac.local> (raw)
In-Reply-To: <dc26dc1b-c022-341b-18ba-c009275e5ee9@broadcom.com>
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 <scott.branden@broadcom.com> wrote:
> > > On 18-09-05 02:40 AM, Ard Biesheuvel wrote:
> > > > On 4 September 2018 at 19:19, Scott Branden <scott.branden@broadcom.com> 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.
--
Catalin
next prev parent reply other threads:[~2018-09-09 11:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 17:21 [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER Scott Branden
2018-08-29 18:44 ` Olof Johansson
2018-08-29 18:59 ` Scott Branden
2018-08-30 5:54 ` Ard Biesheuvel
2018-08-30 15:06 ` Olof Johansson
2018-08-30 16:23 ` Ard Biesheuvel
2018-08-31 21:28 ` Scott Branden
2018-09-02 2:54 ` Olof Johansson
2018-09-04 6:23 ` Ard Biesheuvel
2018-09-04 10:13 ` Grant Likely
2018-09-04 17:19 ` Scott Branden
2018-09-05 9:40 ` Ard Biesheuvel
2018-09-05 17:27 ` Scott Branden
2018-09-05 18:00 ` Grant Likely
2018-09-05 18:04 ` Scott Branden
2018-09-09 11:07 ` Catalin Marinas [this message]
2018-09-09 15:55 ` Ard Biesheuvel
2018-09-04 17:28 ` Olof Johansson
2018-09-05 9:37 ` Ard Biesheuvel
2018-09-05 19:09 ` Grant Likely
2018-09-10 17:53 ` Scott Branden
2018-09-10 18:01 ` Olof Johansson
2018-09-10 18:08 ` Ard Biesheuvel
2018-09-13 20:22 ` Scott Branden
2018-09-14 6:06 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180909110732.GA63296@iMac.local \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox