From patchwork Tue Jun 4 05:23:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aaron Lu X-Patchwork-Id: 2656921 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id E01CCDF2A1 for ; Tue, 4 Jun 2013 05:23:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756461Ab3FDFWo (ORCPT ); Tue, 4 Jun 2013 01:22:44 -0400 Received: from mga09.intel.com ([134.134.136.24]:2453 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753954Ab3FDFWl (ORCPT ); Tue, 4 Jun 2013 01:22:41 -0400 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 03 Jun 2013 22:20:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,797,1363158000"; d="scan'208";a="347755435" Received: from aaronlu.sh.intel.com ([10.239.36.102]) by orsmga002.jf.intel.com with ESMTP; 03 Jun 2013 22:22:35 -0700 Message-ID: <51AD79B6.6060902@intel.com> Date: Tue, 04 Jun 2013 13:23:02 +0800 From: Aaron Lu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rafael J. Wysocki" CC: ACPI Devel Mailing List , Len Brown , Aaron Lu , Zhang Rui Subject: [PATCH] ACPI: do not match devices that have scan handler References: <51AC9389.3050603@intel.com> In-Reply-To: <51AC9389.3050603@intel.com> X-Forwarded-Message-Id: <51AC9389.3050603@intel.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org With the introduction of acpi scan handler, an acpi device that has acpi scan handler does not need an acpi driver any more. For those devices, there is no meaning to match them against a newly registered acpi driver in acpi_bus_match. This can also solve a regression caused by a broken BIOS table, where it has defined a _ROM method under PCI root. The video module would think devices that have _ROM defined under it is a display controller device since only display devices would have _ROM method defined according to the ACPI SPEC. As a resule, this method under PCI root would make video module tries to drive PCI root acpi device and the pre-assigned driver_data by PCI root's scan handler will be emptied, making subsequent call to acpi_get_pci_dev fail. Buglink:https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell Reported-and-bisected-by: Dmitry S. Demin Cc: stable@kernel.org Signed-off-by: Aaron Lu --- drivers/acpi/scan.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 5e7e991..67ce501 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -553,6 +553,12 @@ static int acpi_bus_match(struct device *dev, struct device_driver *drv) struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = to_acpi_driver(drv); + /* No need to bind driver for devices that have scan handler */ + if (acpi_dev->handler) + return 0; + + WARN_ON(acpi_dev->driver_data); + return acpi_dev->flags.match_driver && !acpi_match_device_ids(acpi_dev, acpi_drv->ids); }