From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753143AbaIJSaJ (ORCPT ); Wed, 10 Sep 2014 14:30:09 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:36533 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751044AbaIJSaF (ORCPT ); Wed, 10 Sep 2014 14:30:05 -0400 Date: Wed, 10 Sep 2014 19:30:03 +0100 From: Will Deacon To: Bjorn Helgaas Cc: "jcm@redhat.com" , "hanjun.guo@linaro.org" , Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland , Olof Johansson , "grant.likely@linaro.org" , "graeme.gregory@linaro.org" , Arnd Bergmann , Sudeep Holla , Jason Cooper , Marc Zyngier , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles Garcia-Tobin , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 04/17] ARM64 / ACPI: Introduce early_param for "acpi" Message-ID: <20140910183003.GN1710@arm.com> References: <1409583475-6978-1-git-send-email-hanjun.guo@linaro.org> <1409583475-6978-5-git-send-email-hanjun.guo@linaro.org> <540F7BE2.8060403@redhat.com> <20140910130419.GJ28488@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 10, 2014 at 02:21:59PM +0100, Bjorn Helgaas wrote: > On Wed, Sep 10, 2014 at 7:04 AM, Will Deacon wrote: > > > It's blindingly obvious that acpi=off is there to disable ACPI at boot. > > We either support that option or we don't -- none of this `oh, well you > > can use it in this specific case I suppose' rubbish. I'm not questioning > > your use-case, but there's really no need to talk about an `orderly > > adoption' when all you need to say is that your ACPI is busted and passing > > acpi=off lets you boot with a devicetree. > > Maybe we should set a taint bit or give some other indication that > we're using a flag to work around breakage. That sounds like a good idea. Working around breakage is a fact of life, but the taint indicates that it's not the ideal behaviour. Will