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]

Message-ID: <54AC5C57.7050504@redhat.com>
Date:	Tue, 06 Jan 2015 17:06:15 -0500
From:	Jon Masters <jcm@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>, linaro-acpi@...ts.linaro.org
CC:	Catalin Marinas <catalin.marinas@....com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Lv Zheng <lv.zheng@...el.com>, Rob Herring <robh@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Robert Moore <robert.moore@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <Will.Deacon@....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>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Olof Johansson <olof@...om.net>
Subject: Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

Hi Arnd,

Happy New Year!

On 01/06/2015 02:21 PM, Arnd Bergmann wrote:
> On Tuesday 06 January 2015 11:24:43 Jon Masters wrote:
>> On 01/06/2015 06:20 AM, Catalin Marinas wrote:
>>
>>> Now, what's preventing a vendor firmware from providing only ACPI
>>> tables? Do we enforce it in some way (arm-acpi.txt, kernel warning etc.)
>>> that both DT and ACPI are supported, or at least that dts files are
>>> merged in the kernel first?
>>
>> I know of some (server) firmware that will only provide ACPI in the
>> medium term, so this is coming.
> 
> Medium term is fine, as long as they are not expecting their hardware
> to be supported by Linux before ACPI support is stable enough for
> general consumption.

To be clear, I think that's reasonable for upstream. I may love ACPI,
but vendors can always ship kernels with a config supporting ACPI only
platforms in the interim period if they have a commercial justification
and that doesn't have to be supported in terms of the upstream default.

But, perhaps there's a way to have it both ways, you could consider also
a CONFIG_EXPERT option that would allow you to build a kernel with ACPI
only support in the medium term. That way, if someone is running a
vendor kernel, but wants to track upstream development more closely,
they can do so on such hardware by enabling the expert config bit.

> I have no idea how long that will take, but my
> guess is that we shouldn't plan on supporting ACPI-only platforms in
> Linux for the next couple of years and just demand that all drivers
> have DT support to let users add a valid DTB that can describe the
> hardware.

I'm not opposed. It was particularly useful in the early days of ACPI to
be able to boot our internal systems (which now all default to ACPI on
by default) with acpi=off when there were glitches that needed to be
isolated to whether they were ACPI related. One reason I was very keen
for a DT UUID in UEFI early on was so that there was a clean way to
specify both sets of tables on a UEFI platform. Keeping them in sync is
not something we can rely on in the longer term, but during bringup
timeframe I suspect you'll continue to see many platforms with both sets
of tables. This is especially true for early silicon that might be
supporting both embedded and server environments - hence a platform that
appears to be a server might have a DT posted upstream anyway if such a
platform is also being used for unrelated embedded work.

> That should always be possible using something like grub2 as an
> intermediate that boots using the UEFI interfaces and loads the
> kernel and DT from disk.

This is another reason (but it's up to you, I understand your position)
why it may not be a huge problem if there are ACPI only systems, since
the "devicetree" directive in GRUB2 configs is always possible.

Jon.

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