[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu_=si=L5+vvg+8hRgwmTahqdePw5bZxUMFSZ8obk-VXFQ@mail.gmail.com>
Date: Thu, 29 Jan 2015 18:20:06 +0000
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Timur Tabi <timur@...eaurora.org>,
Mark Rutland <Mark.Rutland@....com>,
Rob Herring <robh@...nel.org>,
"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
Robert Richter <rric@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
Marc Zyngier <Marc.Zyngier@....com>,
Will Deacon <Will.Deacon@....com>,
Randy Dunlap <rdunlap@...radead.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
lkml <linux-kernel@...r.kernel.org>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
"wangyijing@...wei.com" <wangyijing@...wei.com>,
Mark Brown <broonie@...nel.org>,
"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
"jcm@...hat.com" <jcm@...hat.com>, Olof Johansson <olof@...om.net>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Jason Cooper <jason@...edaemon.net>
Subject: Re: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce
early_param for "acpi" and pass acpi=force to enable ACPI
On 29 January 2015 at 15:19, Catalin Marinas <catalin.marinas@....com> wrote:
> On Wed, Jan 28, 2015 at 06:18:44PM +0000, Timur Tabi wrote:
>> On 01/28/2015 12:14 PM, Catalin Marinas wrote:
>> >> >So it looks like there's a whole conversation about this already in
>> >> >this thread that I didn't notice. However, reading through all of it,
>> >> >I still don't understand sure why the presence of ACPI tables is
>> >> >insufficient to enable ACPI.
>>
>> > Because ACPI on arm64 is still experimental, no matter how many people
>> > claim that it is production ready in their private setups.
>>
>> Fair enough. Does this mean that passing "acpi=force" on the kernel
>> command line is a requirement for ARM64 servers?
>
> Please read my other email and ideally the whole sub-thread. The
> acpi=force should only be required if the SoC is described (from
> firmware) by both DT and ACPI.
>
>> >> >In what situation would we want to ignore ACPI tables that are
>> >> >present?
>>
>> > When DT tables are also present (and for the first platforms, that's
>> > highly recommended, though not easily enforceable at the kernel level).
>>
>> My understanding is that the EFI stub creates a device tree (and it
>> contains some important information), so I don't understand how we can
>> ever have an ACPI-only platform on ARM64 servers.
>
> If EFI stub creates the DT itself (not passed by firmware), it will
> write some information in the chosen node that the rest of the kernel
> can make use of and take the appropriate decision on whether to use ACPI
> or not. That's something that will be used by kexec and Xen as well
> which may want to boot with ACPI tables outside an EFI environment.
>
If we are going with this solution, we should also mandate that an
ACPI enabled firmware should not supply a non-DT DTB, or we wouldn't
spot the difference. Not sure how likely this is, but I could imagine
a firmware setting up an initrd and hence populating the /chosen node
in an otherwise empty DTB. In this case, the stub would not add its
'I-created-an-empty-dtb' property.
--
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists