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]

Message-ID: <20150129151956.GF8951@e104818-lin.cambridge.arm.com>
Date:	Thu, 29 Jan 2015 15:19:56 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Timur Tabi <timur@...eaurora.org>
Cc:	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
	Mark Rutland <Mark.Rutland@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	Rob Herring <robh@...nel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"jcm@...hat.com" <jcm@...hat.com>, Mark Brown <broonie@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce
 early_param for "acpi" and pass acpi=force to enable ACPI

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.

-- 
Catalin
--
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/