linux-kernel - Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

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, 15 Jan 2015 17:52:31 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linaro-acpi@...ts.linaro.org
Cc:	Jon Masters <jcm@...hat.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Robert Moore <robert.moore@...el.com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>, Lv Zheng <lv.zheng@...el.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Olof Johansson <olof@...om.net>
Subject: Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

On Thursday 15 January 2015 10:51:58 Jon Masters wrote:
> On 01/15/2015 09:10 AM, Grant Likely wrote:
> > On Tue, Jan 6, 2015 at 1:59 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> For drivers merged upstream, I would insist that every driver merged
> >> for an ARM64 platform has a documented DT binding that is used in the
> >> driver.
> > 
> > That's a dumb rule. It will result in untested DT code paths being
> > thrown into drivers just too meet the rules rather than on whether or
> > not they will actually be used. It's fine to allow driver authors to
> > only implement the ACPI code path if that is what they are working
> > with. We can *always* add a DT path to the driver when it is needed.
> 
> It gets worse. There *will* be large numbers of ACPI only ARM servers
> landing over the coming year. Not only would DT code be untested, but
> insisting on keeping e.g. a DSDT and DT in sync is never going to work
> anyway. Already we have early stage servers that contain a DT used for
> bringup that is subsequently not being updated as often as the ACPI
> tables (those systems are now booting exclusively in labs with ACPI).
> Eventually, I am going to push for the DT data to be removed from these
> systems rather than have out of date unmaintained DT data in firmware.

We will of course be able to relax the rule once ACPI has stabilized on
ARM64. At the moment, we haven't even agreed on how to represent basic
devices, so things are in flux and there is no way for a BIOS writer
to ship an image that we will guarantee to support in the long run.

At some point after we are reasonably sure we are able to keep supporting
all existing systems that are working with that kernel, we can take
support for new systems without having DT by default, and also support
booting those without acpi=force, which is related to this question.

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