From patchwork Mon Jan 27 00:32:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 3540301 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 01F2FC02DC for ; Mon, 27 Jan 2014 00:32:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 36B762011E for ; Mon, 27 Jan 2014 00:32:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34B032011D for ; Mon, 27 Jan 2014 00:32:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753514AbaA0Acg (ORCPT ); Sun, 26 Jan 2014 19:32:36 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:59845 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753508AbaA0Acb (ORCPT ); Sun, 26 Jan 2014 19:32:31 -0500 Received: from cpc11-sgyl31-2-0-cust68.sgyl.cable.virginm.net ([94.175.92.69] helo=debutante.sirena.org.uk) by mezzanine.sirena.org.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1W7a7i-0004JI-2V; Mon, 27 Jan 2014 00:32:23 +0000 Received: from broonie by debutante.sirena.org.uk with local (Exim 4.82) (envelope-from ) id 1W7a7c-0002e0-R3; Mon, 27 Jan 2014 00:32:16 +0000 From: Mark Brown To: Len Brown , "Rafael J. Wysocki" Cc: linux-acpi@vger.kernel.org, linaro-kernel@lists.linaro.org, Jean Delvare , Guenter Roeck , Mark Brown Date: Mon, 27 Jan 2014 00:32:14 +0000 Message-Id: <1390782734-10131-1-git-send-email-broonie@kernel.org> X-Mailer: git-send-email 1.8.5.3 X-SA-Exim-Connect-IP: 94.175.92.69 X-SA-Exim-Mail-From: broonie@sirena.org.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Subject: [PATCH] ACPI: Flag use of ACPI and ACPI idioms for power supplies to regulator API X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Mark Brown There is currently no facility in ACPI to express the hookup of voltage regulators, the expectation is that the regulators that exist in the system will be handled transparently by firmware if they need software control at all. This means that if for some reason the regulator API is enabled on such a system it should assume that any supplies that devices need are provided by the system at all relevant times without any software intervention. Tell the regulator core to make this assumption by calling regulator_has_full_constraints(). Do this as soon as we know we are using ACPI so that the information is available to the regulator core as early as possible. This will cause the regulator core to pretend that there is an always on regulator supplying any supply that is requested but that has not otherwise been mapped which is the behaviour expected on a system with ACPI. Should the ability to specify regulators be added in future revisions of ACPI then once we have support for ACPI mappings in the kernel the same assumptions will apply. It is also likely that systems will default to a mode of operation which does not require any interpretation of these mappings in order to be compatible with existing operating system releases so it should remain safe to make these assumptions even if the mappings exist but are not supported by the kernel. Signed-off-by: Mark Brown --- drivers/acpi/bus.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 384da5ab5955..fcb59c21c68d 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -33,6 +33,7 @@ #include #include #include +#include #ifdef CONFIG_X86 #include #endif @@ -509,6 +510,14 @@ void __init acpi_early_init(void) goto error0; } + /* + * If the system is using ACPI then we can be reasonably + * confident that any regulators are managed by the firmware + * so tell the regulator core it has everything it needs to + * know. + */ + regulator_has_full_constraints(); + return; error0: