From patchwork Thu Jun 15 01:41:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lv Zheng X-Patchwork-Id: 9787811 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 79AA9602CB for ; Thu, 15 Jun 2017 01:42:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6CDCB20007 for ; Thu, 15 Jun 2017 01:42:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6166F28562; Thu, 15 Jun 2017 01:42:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D50E620007 for ; Thu, 15 Jun 2017 01:42:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752409AbdFOBme (ORCPT ); Wed, 14 Jun 2017 21:42:34 -0400 Received: from mga09.intel.com ([134.134.136.24]:43261 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbdFOBlq (ORCPT ); Wed, 14 Jun 2017 21:41:46 -0400 Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 18:41:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,342,1493708400"; d="scan'208";a="114592408" Received: from unknown (HELO lvzheng-MOBLsp3.sh.intel.com) ([10.239.159.55]) by fmsmga005.fm.intel.com with ESMTP; 14 Jun 2017 18:41:43 -0700 From: Lv Zheng To: "Rafael J . Wysocki" , "Rafael J . Wysocki" , Len Brown Cc: Lv Zheng , Lv Zheng , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: [PATCH v3 2/4] ACPI / EC: Add support to skip boot stage DSDT probe Date: Thu, 15 Jun 2017 09:41:41 +0800 Message-Id: <40ce1fcc531f3bdf82a765e1ae69ff426ffcd61e.1497490457.git.lv.zheng@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: References: 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 We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is no extra DSDT EC device enumeration process occurring before the main ACPI device enumeration process. That means acpi_ec_dsdt_probe() is not a Windows compliant approach, it's just a linux workaround. Tracking back, we can see a long time ago, Linux EC driver won't probe DSDT EC during boot. It was added by the following commit (see link #1 for bug report): Commit: c5279dee26c0e8d7c4200993bfc4b540d2469598 Subject: ACPI: EC: Add some basic check for ECDT data This commit simply drivers Linux EC driver to a wrong direction. Why we shouldn't enumerate DSDT EC before the main ACPI device enumeration? The only way to know if the DSDT EC is valid is to evaluate its _STA control method, but it's not proper to evaluate this control method that early and out of the ACPI enumeration process because _STA may contain other devices' initialization code and such devices may not have been initialized before OSPM starts to enumerate them via the main ACPI device enumeration. But after we reverted back to the expected behavior, someone reported a regression (see link #2 for reference). On that platform, there is no ECDT, but the platform control methods access EC operation region earlier than Linux expects, causing some ACPI method execution errors. According to the regression rule, we just revert back to old behavior to still probe DSDT EC as boot EC. Now we've been reported 3rd functional breakage (link #3). In order to handle both issues (link #2 and link #3), we could just skip boot stage DSDT probe when ECDT exists so that a later quirk can always use correct ECDT GPE setting. Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880 [#1] Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261 [#2] Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651 [#3] Tested-by: Daniel Drake Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index c1f480b..44b973e 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1667,12 +1667,34 @@ static const struct acpi_device_id ec_device_ids[] = { {"", 0}, }; +/* + * This function is not Windows compliant as Windows never enumerates the + * namespace EC before the main ACPI device enumeration process. This + * function is kept for historical reason and will be deprecated in the + * future. + * + * It's added due to a non-root-caused bug fix: + * http://bugzilla.kernel.org/show_bug.cgi?id=11880 + * But removing it now unfortunately triggers user noticable regression: + * http://bugzilla.kernel.org/show_bug.cgi?id=119261 + */ int __init acpi_ec_dsdt_probe(void) { acpi_status status; struct acpi_ec *ec; int ret; + /* + * If a platform has ECDT, there is no need to proceed as the + * following probe is not a part of the ACPI device enumeration, + * executing _STA is not safe, and thus this probe may risk of + * picking up an invalid EC device. + * So we should catch any possible chance to avoid applying this + * quirk. + */ + if (boot_ec) + return -ENODEV; + ec = acpi_ec_alloc(); if (!ec) return -ENOMEM;