linux-kernel - Re: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/