From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752159AbbASRkh (ORCPT ); Mon, 19 Jan 2015 12:40:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43859 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752024AbbASRkf (ORCPT ); Mon, 19 Jan 2015 12:40:35 -0500 Message-ID: <54BD3803.6020307@redhat.com> Date: Mon, 19 Jan 2015 11:59:47 -0500 From: Jon Masters Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Grant Likely , Catalin Marinas , Ard Biesheuvel CC: "hanjun.guo@linaro.org" , Mark Rutland , "linaro-acpi@lists.linaro.org" , Will Deacon , "wangyijing@huawei.com" , Rob Herring , Lorenzo Pieralisi , Al Stone , Timur Tabi , "linux-acpi@vger.kernel.org" , Charles Garcia-Tobin , "phoenix.liyi@huawei.com" , Robert Richter , Jason Cooper , Arnd Bergmann , Marc Zyngier , Mark Brown , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , "graeme.gregory@linaro.org" , Randy Dunlap , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , "suravee.suthikulpanit@amd.com" , Sudeep Holla , Olof Johansson Subject: Re: [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI References: <1421247905-3749-1-git-send-email-hanjun.guo@linaro.org> <1421247905-3749-5-git-send-email-hanjun.guo@linaro.org> <20150119114255.GF11835@e104818-lin.cambridge.arm.com> <20150119135144.GI11835@e104818-lin.cambridge.arm.com> <20150119151350.21B65C40948@trevor.secretlab.ca> In-Reply-To: <20150119151350.21B65C40948@trevor.secretlab.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/2015 10:13 AM, Grant Likely wrote: > On Mon, 19 Jan 2015 13:51:45 +0000 > , Catalin Marinas > wrote: >> On Mon, Jan 19, 2015 at 11:55:32AM +0000, Ard Biesheuvel wrote: >>> On 19 January 2015 at 11:42, Catalin Marinas wrote: >>>> On Wed, Jan 14, 2015 at 03:04:52PM +0000, Hanjun Guo wrote: >>>>> From: Al Stone >>>>> >>>>> Introduce one early parameters "off" and "force" for "acpi", acpi=off >>>>> will be the default behavior for ARM64, so introduce acpi=force to >>>>> enable ACPI on ARM64. >>>>> >>>>> Disable ACPI before early parameters parsed, and enable it to pass >>>>> "acpi=force" if people want use ACPI on ARM64. This ensures DT be >>>>> the prefer one if ACPI table and DT both are provided at this moment. >>>> [...] >>>>> --- a/arch/arm64/kernel/setup.c >>>>> +++ b/arch/arm64/kernel/setup.c >>>>> @@ -62,6 +62,7 @@ >>>>> #include >>>>> #include >>>>> #include >>>>> +#include >>>>> >>>>> unsigned int processor_id; >>>>> EXPORT_SYMBOL(processor_id); >>>>> @@ -388,6 +389,8 @@ void __init setup_arch(char **cmdline_p) >>>>> early_fixmap_init(); >>>>> early_ioremap_init(); >>>>> >>>>> + disable_acpi(); >>>>> + >>>>> parse_early_param(); >>>>> >>>>> /* >>>> >>>> Did we get to any conclusion here? DT being the preferred one is fine >>>> when both DT and ACPI are present but do we still want the kernel to >>>> ignore ACPI altogether if DT is not present? It's a bit harder to detect >>>> the presence of DT at this point since the EFI_STUB added one already. I >>>> guess we could move the "acpi=force" argument passing to EFI_STUB if no >>>> DT is present at boot. >>> >>> Since the EFI stub populates the /chosen node in DT, I would prefer >>> for it to add a property there to indicate whether it created the DT >>> from scratch rather than adding ACPI specific stuff in there (even if >>> it is just a string to concatenate) >> >> This works for me. So we could pass "acpi=force" in EFI stub if it >> created the DT from scratch *and* ACPI tables are present (can it detect >> the latter? And maybe it could print something if none are available). >> If that works, the actual kernel can assume that ACPI needs to be >> explicitly enabled via acpi=force, irrespective of how much information >> it has in DT. > > Ditto for me. I think this is a fine solution. And, yes, the stub can > easily detect the presence of ACPI by looking in the UEFI config table. I get the point behind doing this, but could we not have it pass in a different parameter than =force? Perhaps something new? I'd like to separate out the case that it was enabled automatically vs explicitly forced on by a user wanting to use ACPI on a system with both tables. Jon.