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: <20150129231120.GA23786@e104818-lin.cambridge.arm.com>
Date:	Thu, 29 Jan 2015 23:11:20 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Jon Masters <jcm@...hat.com>
Cc:	Timur Tabi <timur@...eaurora.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.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>,
	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 Thu, Jan 29, 2015 at 06:44:36PM +0000, Jon Masters wrote:
> On 01/29/2015 01:34 PM, Timur Tabi wrote:
> > On 01/29/2015 12:28 PM, Ard Biesheuvel wrote:
> >> The UEFI stub in the kernel uses the DTB file format (FDT) to pass
> >> information about the UEFI memory map and system table to the kernel.
> >> It does so even if there is no device tree that describes the
> >> platform. In this case, the file only contains a /chosen DT node, and
> >> nothing else, and it is up to the kernel to figure out that it can ask
> >> UEFI for a set of ACPI tables that it can use instead to configure the
> >> system. Otherwise, the /chosen node properties are added to a device
> >> tree that contains the full platform description.
> >>
> >> The problem is that we have to decide how to distinguish a
> >> conventional device tree DTB from a DTB that only exists to
> >> communicate the UEFI entry points.
> > 
> > Ah, that's exactly what I'm seeing.  The UEFI stub in our kernel 
> > generates a DTB, and therefore I always need to put acpi=force on our 
> > kernel command line.

To Timur: that's because you use a set of patches that are still under
development and not yet agreed as being upstream ready. There is a
sub-thread on this topic and even a patch from Ard on how EFI stub can
tell the kernel whether DT as any SoC description or not. This needs
further discussion since similar feature is needed by kexec and Xen.

> I expect some of the distros to patch ACPI always enabled. So from my
> point of view this affects only those wanting to follow upstream.

Sorry Jon but statements like this make me wonder whether we should
simply let the whole ARM ACPI be an out of tree distro business. We
spend a long time discussing OS-agnostic firmware implementation,
planning mini-summits, just to get certain Linux distro representative
stating that the kernel-firmware interface we discuss here only matters
for those planning to follow upstream. Certain Linux distros will play
by other rules.

I'm trying to get some consensus here, coming with arguments why DT
has priority over ACPI while still allowing ACPI-only firmware and you
pretty much state that vendors picking a distro kernel rather than
mainline don't need to bother. How does this work with Red Hat's stand
on upstream first? Not having ACPI in mainline yet is not an excuse;
there have been reasonable technical arguments and it's now a matter of
time until they (well, part of them) are sorted, nothing political
(what's political is distros patching the kernel to disable DT booting
on purpose).

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