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:	Tue, 06 Jan 2015 23:55:58 -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

On 01/06/2015 05:06 PM, Jon Masters wrote:
> 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.

Clarification: I'm suggesting that in the medium term the dependency
upon CONFIG_EXPERT either goes away or is replaced with requiring ACPI
and DTB in the non "expert" case and requiring "expert" selected to
allow a kernel that will boot with ACPI only. But only a suggestion.

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/