From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754437AbbAEURq (ORCPT ); Mon, 5 Jan 2015 15:17:46 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:63096 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753789AbbAEURo (ORCPT ); Mon, 5 Jan 2015 15:17:44 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Catalin Marinas , Hanjun Guo , Mark Rutland , "linaro-acpi@lists.linaro.org" , Will Deacon , Lv Zheng , Rob Herring , Lorenzo Pieralisi , Al Stone , Daniel Lezcano , Robert Moore , "linux-acpi@vger.kernel.org" , "jcm@redhat.com" , "grant.likely@linaro.org" , Charles Garcia-Tobin , Robert Richter , Jason Cooper , Marc Zyngier , Liviu Dudau , Mark Brown , Bjorn Helgaas , "graeme.gregory@linaro.org" , "Kangkang.Shen@huawei.com" , Randy Dunlap , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Sudeep Holla , Olof Johansson Subject: Re: [PATCH v5 18/18] Documentation: ACPI for ARM64 Date: Mon, 05 Jan 2015 21:16:30 +0100 Message-ID: <1797489.PjmKzBFdQA@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150105131302.GB14967@e104818-lin.cambridge.arm.com> References: <1413553034-20956-1-git-send-email-hanjun.guo@linaro.org> <54A28B22.7090305@linaro.org> <20150105131302.GB14967@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:aQoUOPMm1DjmCh5bsRU4XxuhomAmKcodvtLrwHvVo9jOsem1Whj kItl25xQzaPkVuJYREBsgXNCBj9s5XpOkRpwjH5dUCkhTs4W1jMqmExpUrJAO4cHR31xe7b SltBj6RY8CcKpPH/mvFE3PjsWlFQVJeLr7P+948S/wd3dluIiHZfeFzuHtCE0wipqZBINBi DkpY7huzDKQgFLzEPvoYg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 05 January 2015 13:13:02 Catalin Marinas wrote: > > > since passing no DT tables to OS but > > acpi=force is missing is a corner case, we can do a follow up patch to > > fix that, does it make sense? > > Not entirely. Why would no dtb and no acpi=force be a corner case? I > thought this should be the default when only ACPI tables are passed, no > need for an additional acpi=force argument. We don't really support the case of only ACPI tables for now. The expectation is that you always have working DT support, at least for the next few years as ACPI features are ramping up, and without acpi=force it should not try to use ACPI at all. Arnd