From patchwork Tue Jul 23 02:47:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "lan,Tianyu" X-Patchwork-Id: 2831706 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D60939F4D4 for ; Tue, 23 Jul 2013 02:55:53 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E0EFB2021E for ; Tue, 23 Jul 2013 02:55:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE3522020E for ; Tue, 23 Jul 2013 02:55:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753918Ab3GWCzt (ORCPT ); Mon, 22 Jul 2013 22:55:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:49501 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753890Ab3GWCzt (ORCPT ); Mon, 22 Jul 2013 22:55:49 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 22 Jul 2013 19:55:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,723,1367996400"; d="scan'208";a="369450968" Received: from lantianyu-ws.sh.intel.com (HELO localhost) ([10.239.36.12]) by fmsmga001.fm.intel.com with ESMTP; 22 Jul 2013 19:55:47 -0700 From: tianyu.lan@intel.com To: lenb@kernel.org Cc: Lan Tianyu , linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, Dagobertstaler@gmail.com, git@karolherbst.de Subject: [PATCH] ACPI/glue: evaluate "_STA" method directly to get device actual status instead of using acpi_bus_get_status_handle() Date: Tue, 23 Jul 2013 10:47:13 +0800 Message-Id: <1374547633-4477-1-git-send-email-tianyu.lan@intel.com> X-Mailer: git-send-email 1.7.9.5 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, 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 From: Lan Tianyu commit 33f767d7(ACPI: Rework acpi_get_child() to be more efficient) changes the logic of choosing child in the do_acpi_find_child() when there are multi child devices with same _ADR. Original, it returned the last one but it return the first one after commit 33f767d7. This causes regression on the Notebook P15SM that there is no ACPI handle for video card. This because there are two ACPI nodes with same _ADR for associated PCIE port. One contains video card's ACPI node and the other one doesn't(So called wrong ACPI node.). The wrong one is the first child device on this machine. So after commit 33f767d7, bbswitch can't find ACPI handle for video card. Further more, both these device nodes don't have _STA. commit c7d9ca9(ACPI: add _STA evaluation at do_acpi_find_child()) also changes the logic of choosing child. On some platforms, there are multiple devices with the same "_ADR" and they are perceptively for WIN7, WIN8 and Linux. If one of them is enabled, others will be disabled. The commit calls acpi_bus_get_status_handle() to get device's status If a matching device object exists, but is disabled, acpi_get_child() will continue to walk the namespace in the hope of finding an enabled one. If one is found, its handle will be returned, but otherwise the function will return the handle of the disabled object found. For this case, Bios must provide _STA for these device nodes since this is designed for OS to select which device node should be chosen. After commit c7d9ca9, the first enabled device will be chosen or if all device nodes were disabled or acpi_bus_get_status_handle() always returned error, the last one would be returned. But for device nodes without _STA, according acpi spec "If a device object (including the processor object) does not have an _STA object, then OSPM assumes that the device is present, enabled, shown in the UI, and functioning." and so acpi_bus_get_status_handle() return 0x0F as status for these devices without _STA. On the Notebook P15SM, both PCIE port device node with same _ADR don't have _STA and are treated as ENABLED devices by do_acpi_find_child(). The first wrong device node is returned. To workaround the issue, evaluate the _STA directly in the do_acpi_find_child() and if all device nodes doesn't have _STA, the last one will be chosen. This also will not affect the case for commit c7d9ca9. This have been tested on Lenovo Y480 where commit 33f767d7 fixed one similar issue. Reference:https://bugzilla.kernel.org/show_bug.cgi?id=60561 Reference:https://github.com/Bumblebee-Project/bbswitch/issues/65 reference:https://github.com/Bumblebee-Project/bbswitch/issues/2#issuecomment-21101083 Tested-by: Sergio Perez Tested-by: Karol Herbst Cc: #3.9+ Signed-off-by: Lan Tianyu --- Hi Rafael: This patch is based on the commit c7d9ca9 merged in v3.11 and purposes to fix the regression introduced by 33f767d7 merged in v3.9. So it's necessary to backport both commit c7d9ca9 and this patch to 3.9+ stable tree? drivers/acpi/glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index f680957..732c707 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -87,7 +87,7 @@ static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { *ret_p = handle; - status = acpi_bus_get_status_handle(handle, &sta); + status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_ENABLED)) return AE_CTRL_TERMINATE; }