From patchwork Tue Jan 19 16:31:04 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukas Wunner X-Patchwork-Id: 8064071 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id BC8269F859 for ; Tue, 19 Jan 2016 16:31:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0B65C204A2 for ; Tue, 19 Jan 2016 16:31:14 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 12DCF20461 for ; Tue, 19 Jan 2016 16:31:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6A0426E7BA; Tue, 19 Jan 2016 08:31:12 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mailout3.hostsharing.net (mailout3.hostsharing.net [176.9.242.54]) by gabe.freedesktop.org (Postfix) with ESMTPS id DA6066E7BA for ; Tue, 19 Jan 2016 08:31:10 -0800 (PST) Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout3.hostsharing.net (Postfix) with ESMTPS id 2507C101D0DC3; Tue, 19 Jan 2016 17:31:08 +0100 (CET) Received: from localhost (6-38-90-81.adsl.cmo.de [81.90.38.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by h08.hostsharing.net (Postfix) with ESMTPSA id 17521603E112; Tue, 19 Jan 2016 17:31:06 +0100 (CET) Date: Tue, 19 Jan 2016 17:31:04 +0100 From: Lukas Wunner To: "Rafael J. Wysocki" Message-ID: <20160119163104.GA9469@wunner.de> References: <1452752207-30382-1-git-send-email-ankitprasad.r.sharma@intel.com> <1530202.t7e2q1JhJ2@vostro.rjw.lan> <20160118230047.GA9173@wunner.de> <5484189.RBRMZdsTjH@vostro.rjw.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5484189.RBRMZdsTjH@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ankitprasad Sharma , intel-gfx@lists.freedesktop.org, shashidhar.hiremath@intel.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, akash.goel@intel.com, Len Brown Subject: Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Rafael, On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote: > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote: > > Hi, > > > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote: > > > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote: > > [cut] > > > > > > > If you want to check if the device ir present at all, you cen use > > > > > > acpi_device_is_present() introduced recently (although that would need > > > > > > to be exported if you want to use it from a driver). > > > > > > > > > > I meant acpi_dev_present(), sorry about the mistake. > > > > > > > > > > I guess we should rename it to acpi_device_found() or something similar > > > > > to avoid such confusion in the future. > > > > > > > > The name was chosen because the PCI equivalent is called pci_dev_present() > > > > and I assumed that name already stuck in developers' heads, so if they're > > > > looking for an ACPI presence detection function, that's what they'd look > > > > for first. > > > > > > But "present" in ACPI really means something different. There may be ACPI > > > device objects in the namespace for devices that are not *actually* present. > > > > You mean synthesized devices like LNXSYBUS? > > Don't think anyone is going to test for the presence of that. > > No, I mean real devices, where the corresponding ACPI object has _STA that > returns 0. > > There may be a couple of reasons for that. The device the ACPI object > corresponds to may not be physically present (eg. it may possible to > hot-add it) or the device may depend on something else for functionality > and that thing hasn't been set up yet etc. > > The presence of an ACPI device object in the namespace means that the > platform firmware knows about the device, but it need not mean that > the device is really there. _STA returns that piece of information. Thank you for the clarification, these are very good points. The drivers in question use acpi_get_devices() merely to probe for presence of a device in the namespace. They do not invoke _STA, nor do they even hold a pointer to the acpi_device or acpi_handle when detecting presence. Mostly this is about activating quirks if a certain ACPI device is detected. Currently about 50% of the calls to acpi_get_devices() in the drivers fit this pattern and the point of acpi_dev_present() is to give developers a simple, lightweight tool as an alternative. However the kernel-doc should be amended to clarify that _STA is not invoked. The patch below is a suggestion, feel free to rephrase. Thanks & best regards, Lukas -- >8 -- Subject: [PATCH] ACPI / utils: Clarify appropriate usage of acpi_dev_present() Rafael J. Wysocki pointed out that even though a device is present in the namespace, its _STA control method might still return 0 in the "device is present" bit. Amend the documentation accordingly. Cc: "Rafael J. Wysocki" Signed-off-by: Lukas Wunner --- drivers/acpi/utils.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index f2f9873..99af3bc 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -716,6 +716,8 @@ EXPORT_SYMBOL(acpi_check_dsm); * * Return %true if the device was present at the moment of invocation. * Note that if the device is pluggable, it may since have disappeared. + * Also, this merely checks presence in the namespace but does not + * invoke the _STA control method. * * For this function to work, acpi_bus_scan() must have been executed * which happens in the subsys_initcall() subsection. Hence, do not