From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ard Biesheuvel Subject: Re: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI Date: Thu, 29 Jan 2015 18:20:06 +0000 Message-ID: References: <1421247905-3749-1-git-send-email-hanjun.guo@linaro.org> <1421247905-3749-5-git-send-email-hanjun.guo@linaro.org> <20150128181453.GG31752@e104818-lin.cambridge.arm.com> <54C92804.5090806@codeaurora.org> <20150129151956.GF8951@e104818-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-ie0-f178.google.com ([209.85.223.178]:56186 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbbA2SUH (ORCPT ); Thu, 29 Jan 2015 13:20:07 -0500 Received: by mail-ie0-f178.google.com with SMTP id rp18so36854144iec.9 for ; Thu, 29 Jan 2015 10:20:06 -0800 (PST) In-Reply-To: <20150129151956.GF8951@e104818-lin.cambridge.arm.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Catalin Marinas Cc: Timur Tabi , Mark Rutland , Rob Herring , "phoenix.liyi@huawei.com" , Robert Richter , "linux-acpi@vger.kernel.org" , Arnd Bergmann , "linaro-acpi@lists.linaro.org" , Marc Zyngier , Will Deacon , Randy Dunlap , "Rafael J. Wysocki" , lkml , "grant.likely@linaro.org" , "wangyijing@huawei.com" , Mark Brown , "hanjun.guo@linaro.org" , "jcm@redhat.com" , Olof Johansson , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" On 29 January 2015 at 15:19, Catalin Marinas wrote: > On Wed, Jan 28, 2015 at 06:18:44PM +0000, Timur Tabi wrote: >> On 01/28/2015 12:14 PM, Catalin Marinas wrote: >> >> >So it looks like there's a whole conversation about this already in >> >> >this thread that I didn't notice. However, reading through all of it, >> >> >I still don't understand sure why the presence of ACPI tables is >> >> >insufficient to enable ACPI. >> >> > Because ACPI on arm64 is still experimental, no matter how many people >> > claim that it is production ready in their private setups. >> >> Fair enough. Does this mean that passing "acpi=force" on the kernel >> command line is a requirement for ARM64 servers? > > Please read my other email and ideally the whole sub-thread. The > acpi=force should only be required if the SoC is described (from > firmware) by both DT and ACPI. > >> >> >In what situation would we want to ignore ACPI tables that are >> >> >present? >> >> > When DT tables are also present (and for the first platforms, that's >> > highly recommended, though not easily enforceable at the kernel level). >> >> My understanding is that the EFI stub creates a device tree (and it >> contains some important information), so I don't understand how we can >> ever have an ACPI-only platform on ARM64 servers. > > If EFI stub creates the DT itself (not passed by firmware), it will > write some information in the chosen node that the rest of the kernel > can make use of and take the appropriate decision on whether to use ACPI > or not. That's something that will be used by kexec and Xen as well > which may want to boot with ACPI tables outside an EFI environment. > If we are going with this solution, we should also mandate that an ACPI enabled firmware should not supply a non-DT DTB, or we wouldn't spot the difference. Not sure how likely this is, but I could imagine a firmware setting up an initrd and hence populating the /chosen node in an otherwise empty DTB. In this case, the stub would not add its 'I-created-an-empty-dtb' property. -- Ard. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754403AbbA2SUK (ORCPT ); Thu, 29 Jan 2015 13:20:10 -0500 Received: from mail-ie0-f173.google.com ([209.85.223.173]:41951 "EHLO mail-ie0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752721AbbA2SUH (ORCPT ); Thu, 29 Jan 2015 13:20:07 -0500 MIME-Version: 1.0 In-Reply-To: <20150129151956.GF8951@e104818-lin.cambridge.arm.com> References: <1421247905-3749-1-git-send-email-hanjun.guo@linaro.org> <1421247905-3749-5-git-send-email-hanjun.guo@linaro.org> <20150128181453.GG31752@e104818-lin.cambridge.arm.com> <54C92804.5090806@codeaurora.org> <20150129151956.GF8951@e104818-lin.cambridge.arm.com> Date: Thu, 29 Jan 2015 18:20:06 +0000 Message-ID: Subject: Re: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI From: Ard Biesheuvel To: Catalin Marinas Cc: Timur Tabi , Mark Rutland , Rob Herring , "phoenix.liyi@huawei.com" , Robert Richter , "linux-acpi@vger.kernel.org" , Arnd Bergmann , "linaro-acpi@lists.linaro.org" , Marc Zyngier , Will Deacon , Randy Dunlap , "Rafael J. Wysocki" , lkml , "grant.likely@linaro.org" , "wangyijing@huawei.com" , Mark Brown , "hanjun.guo@linaro.org" , "jcm@redhat.com" , Olof Johansson , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , Jason Cooper Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29 January 2015 at 15:19, Catalin Marinas wrote: > On Wed, Jan 28, 2015 at 06:18:44PM +0000, Timur Tabi wrote: >> On 01/28/2015 12:14 PM, Catalin Marinas wrote: >> >> >So it looks like there's a whole conversation about this already in >> >> >this thread that I didn't notice. However, reading through all of it, >> >> >I still don't understand sure why the presence of ACPI tables is >> >> >insufficient to enable ACPI. >> >> > Because ACPI on arm64 is still experimental, no matter how many people >> > claim that it is production ready in their private setups. >> >> Fair enough. Does this mean that passing "acpi=force" on the kernel >> command line is a requirement for ARM64 servers? > > Please read my other email and ideally the whole sub-thread. The > acpi=force should only be required if the SoC is described (from > firmware) by both DT and ACPI. > >> >> >In what situation would we want to ignore ACPI tables that are >> >> >present? >> >> > When DT tables are also present (and for the first platforms, that's >> > highly recommended, though not easily enforceable at the kernel level). >> >> My understanding is that the EFI stub creates a device tree (and it >> contains some important information), so I don't understand how we can >> ever have an ACPI-only platform on ARM64 servers. > > If EFI stub creates the DT itself (not passed by firmware), it will > write some information in the chosen node that the rest of the kernel > can make use of and take the appropriate decision on whether to use ACPI > or not. That's something that will be used by kexec and Xen as well > which may want to boot with ACPI tables outside an EFI environment. > If we are going with this solution, we should also mandate that an ACPI enabled firmware should not supply a non-DT DTB, or we wouldn't spot the difference. Not sure how likely this is, but I could imagine a firmware setting up an initrd and hence populating the /chosen node in an otherwise empty DTB. In this case, the stub would not add its 'I-created-an-empty-dtb' property. -- Ard. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Thu, 29 Jan 2015 18:20:06 +0000 Subject: [Linaro-acpi] [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI In-Reply-To: <20150129151956.GF8951@e104818-lin.cambridge.arm.com> References: <1421247905-3749-1-git-send-email-hanjun.guo@linaro.org> <1421247905-3749-5-git-send-email-hanjun.guo@linaro.org> <20150128181453.GG31752@e104818-lin.cambridge.arm.com> <54C92804.5090806@codeaurora.org> <20150129151956.GF8951@e104818-lin.cambridge.arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 29 January 2015 at 15:19, Catalin Marinas wrote: > On Wed, Jan 28, 2015 at 06:18:44PM +0000, Timur Tabi wrote: >> On 01/28/2015 12:14 PM, Catalin Marinas wrote: >> >> >So it looks like there's a whole conversation about this already in >> >> >this thread that I didn't notice. However, reading through all of it, >> >> >I still don't understand sure why the presence of ACPI tables is >> >> >insufficient to enable ACPI. >> >> > Because ACPI on arm64 is still experimental, no matter how many people >> > claim that it is production ready in their private setups. >> >> Fair enough. Does this mean that passing "acpi=force" on the kernel >> command line is a requirement for ARM64 servers? > > Please read my other email and ideally the whole sub-thread. The > acpi=force should only be required if the SoC is described (from > firmware) by both DT and ACPI. > >> >> >In what situation would we want to ignore ACPI tables that are >> >> >present? >> >> > When DT tables are also present (and for the first platforms, that's >> > highly recommended, though not easily enforceable at the kernel level). >> >> My understanding is that the EFI stub creates a device tree (and it >> contains some important information), so I don't understand how we can >> ever have an ACPI-only platform on ARM64 servers. > > If EFI stub creates the DT itself (not passed by firmware), it will > write some information in the chosen node that the rest of the kernel > can make use of and take the appropriate decision on whether to use ACPI > or not. That's something that will be used by kexec and Xen as well > which may want to boot with ACPI tables outside an EFI environment. > If we are going with this solution, we should also mandate that an ACPI enabled firmware should not supply a non-DT DTB, or we wouldn't spot the difference. Not sure how likely this is, but I could imagine a firmware setting up an initrd and hence populating the /chosen node in an otherwise empty DTB. In this case, the stub would not add its 'I-created-an-empty-dtb' property. -- Ard.