From patchwork Sat Nov 21 20:30:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 330025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BD85C388F9 for ; Sat, 21 Nov 2020 20:31:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5BF1821D7E for ; Sat, 21 Nov 2020 20:31:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HkrT/Ciu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728503AbgKUUar (ORCPT ); Sat, 21 Nov 2020 15:30:47 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:39138 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728402AbgKUUar (ORCPT ); Sat, 21 Nov 2020 15:30:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605990646; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/nTqVVP0uahNJ0Vi39exTUckgy0BekWuMmxre6Vsres=; b=HkrT/Ciu5xzotOIaB61Mht6EEOJTM35499NDo0n1g/evJ1FEsy6/ifwKBB0hSrhkT6E3aJ kPzqblMPDsdnTzGAfPuKFfgcp/JU06prSlADSJ+Bwx8v0AdH5FFUomthGT9c8HtrSJwqv1 EGA3McCG05L4xnAOFytViKJPrk8FmfU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-kLbre_OuMU655pTZoK3Yww-1; Sat, 21 Nov 2020 15:30:44 -0500 X-MC-Unique: kLbre_OuMU655pTZoK3Yww-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AEDFE51DE; Sat, 21 Nov 2020 20:30:43 +0000 (UTC) Received: from x1.localdomain (ovpn-112-24.ams2.redhat.com [10.36.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id B733718E4F; Sat, 21 Nov 2020 20:30:42 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown Cc: Hans de Goede , linux-acpi@vger.kernel.org Subject: [PATCH 1/7] ACPI: scan: Add an acpi_info_matches_hids() helper Date: Sat, 21 Nov 2020 21:30:34 +0100 Message-Id: <20201121203040.146252-2-hdegoede@redhat.com> In-Reply-To: <20201121203040.146252-1-hdegoede@redhat.com> References: <20201121203040.146252-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org acpi_device_dep_initialize() skips _DEPS with a HID of "INT3396" and checks this using an acpi_device_info struct. The upcoming changes splitting the scanning of the root into 2 steps, deferring the addition of some devices which need access to OpRegions of other devices during scanning to the second step, need to extend the HIDs to skip during _DEP checking to a list of HIDs; and need to check an acpi_device_info struct against a list of HIDs in more places. Add an acpi_info_matches_hids() helper which checks a list of HIDs for this and switch acpi_device_dep_initialize() over to this helper. Signed-off-by: Hans de Goede --- drivers/acpi/scan.c | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index bc6a79e33220..e949265d5667 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -719,6 +719,28 @@ int acpi_device_add(struct acpi_device *device, /* -------------------------------------------------------------------------- Device Enumeration -------------------------------------------------------------------------- */ +static bool acpi_info_matches_hids(struct acpi_device_info *info, + const char * const hids[]) +{ + int i; + + if (!(info->valid & ACPI_VALID_HID)) + return false; + + for (i = 0; hids[i]; i++) { + if (!strcmp(info->hardware_id.string, hids[i])) + return true; + } + + return false; +} + +/* List of HIDs for which we ignore matching ACPI devices, when checking _DEP lists. */ +static const char * const acpi_ignore_dep_hids[] = { + "INT3396", /* Windows System Power Management Controller */ + NULL +}; + static struct acpi_device *acpi_bus_get_parent(acpi_handle handle) { struct acpi_device *device = NULL; @@ -1833,13 +1855,7 @@ static void acpi_device_dep_initialize(struct acpi_device *adev) continue; } - /* - * Skip the dependency of Windows System Power - * Management Controller - */ - skip = info->valid & ACPI_VALID_HID && - !strcmp(info->hardware_id.string, "INT3396"); - + skip = acpi_info_matches_hids(info, acpi_ignore_dep_hids); kfree(info); if (skip) From patchwork Sat Nov 21 20:30:37 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 330024 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 405BDC6379D for ; Sat, 21 Nov 2020 20:31:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0843121D7E for ; Sat, 21 Nov 2020 20:31:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TDP5vhc/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728512AbgKUUay (ORCPT ); Sat, 21 Nov 2020 15:30:54 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:27375 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728402AbgKUUay (ORCPT ); Sat, 21 Nov 2020 15:30:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605990652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NS6++THCjQt8F/nyZ7tB/jnyYNnDzYzVyxOVUprHeKU=; b=TDP5vhc/0NYTWWygWm9puQZbb2YA0Ived5Q97gH+SJMLPdaWq5fmWSFH6rURA8/bplLSrs gEWG4s8zxJ9LWARLSG8ZcNCFlOlLxn8saDffzV+LvRj5U4i0KId8LDyPyUEJcBw3zk73Y6 Oy+Cn6lbr33KZKjk8Vi7XWu3AMypIX4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-mdN7A9DWPS2MZGZh6oPhGA-1; Sat, 21 Nov 2020 15:30:50 -0500 X-MC-Unique: mdN7A9DWPS2MZGZh6oPhGA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8B99F809DCC; Sat, 21 Nov 2020 20:30:49 +0000 (UTC) Received: from x1.localdomain (ovpn-112-24.ams2.redhat.com [10.36.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7457C18E4F; Sat, 21 Nov 2020 20:30:46 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown Cc: Hans de Goede , linux-acpi@vger.kernel.org Subject: [PATCH 4/7] ACPI: scan: Split root scanning into 2 steps Date: Sat, 21 Nov 2020 21:30:37 +0100 Message-Id: <20201121203040.146252-5-hdegoede@redhat.com> In-Reply-To: <20201121203040.146252-1-hdegoede@redhat.com> References: <20201121203040.146252-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org The ACPI scan code currently does not honor _DEP lists, except for ACPI battery nodes. This is an issue on some devices, where some of the methods used during device-addition may rely on OpRegions of other devices. An example of this is the Acer Switch 10E SW3-016 model. The _HID method of the ACPI node for the UART attached Bluetooth, reads GPIOs to detect the installed wifi chip and update the _HID for the Bluetooth's ACPI node accordingly. The current ACPI scan code calls _HID before the GPIO controller's OpRegions are available, leading to the wrong _HID being used and Bluetooth not working. This splits the scanning into 2 steps, deferring the addition of some devices which need access to OpRegions of other devices during scanning to the second step. This initial implementation takes a very simple approach to identify which devices need to have their device-addition deferred. It uses a static lists of HIDs for this. This list is initially populated with the HID reported for the Bluetooth on the Acer SW3-016. This uses the HID reported when the GPIO OpRegions are not yet available! A more elaborate approach, which actually looks at the _DEP list will be added by a follow up patch. This other approach has a big chance of causing regressions, so for now it will be hidden behind a kernel commandline option. Which is why the KISS approach chosen here is needed to fix the issue at hand, so that things will work OOTB on affected devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665610 Signed-off-by: Hans de Goede --- drivers/acpi/scan.c | 65 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 7dde66222648..407c8536568b 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -42,6 +42,15 @@ DEFINE_MUTEX(acpi_device_lock); LIST_HEAD(acpi_wakeup_device_list); static DEFINE_MUTEX(acpi_hp_context_lock); +/* + * Variables for the new 2 step scan scheme: + * Step 1. Add all devices for which acpi_should_defer_add() returns false + * Step 2. Add devices deferred during phase 1. + * These are protected by the acpi_scan_lock. + */ +static bool acpi_check_defer_add; +static LIST_HEAD(acpi_deferred_devices); + /* * The UART device described by the SPCR table is the only object which needs * special-casing. Everything else is covered by ACPI namespace paths in STAO @@ -55,6 +64,11 @@ struct acpi_dep_data { acpi_handle slave; }; +struct acpi_deferred_dev { + struct list_head node; + acpi_handle handle; +}; + void acpi_scan_lock_acquire(void) { mutex_lock(&acpi_scan_lock); @@ -741,6 +755,16 @@ static const char * const acpi_ignore_dep_hids[] = { NULL }; +/* + * List of HIDs for which we defer adding them to the second step of the + * scanning of the root, because some of their methods used during addition + * depend on OpRegions registered by the drivers for other ACPI devices. + */ +static const char * const acpi_defer_add_hids[] = { + "BCM2E5B", /* Acer SW3-016 bluetooth HID when GPIO OpRegs or not available yet */ + NULL +}; + static struct acpi_device *acpi_bus_get_parent(acpi_handle handle) { struct acpi_device *device = NULL; @@ -1631,18 +1655,42 @@ void acpi_device_add_finalize(struct acpi_device *device) kobject_uevent(&device->dev.kobj, KOBJ_ADD); } +static bool acpi_should_defer_add(acpi_handle handle, struct acpi_device_info *info) +{ + if (!acpi_check_defer_add || !info) + return false; + + if (acpi_info_matches_hids(info, acpi_defer_add_hids)) + return true; + + return false; +} + static int acpi_add_single_object(struct acpi_device **child, acpi_handle handle, int type, unsigned long long sta) { int result; struct acpi_device *device; + struct acpi_deferred_dev *deferred_dev; struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; struct acpi_device_info *info = NULL; if (handle != ACPI_ROOT_OBJECT && type == ACPI_BUS_TYPE_DEVICE) acpi_get_object_info(handle, &info); + if (acpi_should_defer_add(handle, info)) { + kfree(info); + + deferred_dev = kzalloc(sizeof(*deferred_dev), GFP_KERNEL); + if (!deferred_dev) + return -ENOMEM; + + deferred_dev->handle = handle; + list_add_tail(&deferred_dev->node, &acpi_deferred_devices); + return -EPROBE_DEFER; + } + device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL); if (!device) { printk(KERN_ERR PREFIX "Memory allocation error\n"); @@ -2201,6 +2249,7 @@ int __init acpi_scan_init(void) int result; acpi_status status; struct acpi_table_stao *stao_ptr; + struct acpi_deferred_dev *deferred_dev, *tmp; acpi_pci_root_init(); acpi_pci_link_init(); @@ -2248,7 +2297,9 @@ int __init acpi_scan_init(void) /* * Enumerate devices in the ACPI namespace. */ + acpi_check_defer_add = true; result = acpi_bus_scan(ACPI_ROOT_OBJECT); + acpi_check_defer_add = false; if (result) goto cleanup; @@ -2256,6 +2307,15 @@ int __init acpi_scan_init(void) if (result) goto cleanup; + list_for_each_entry_safe(deferred_dev, tmp, &acpi_deferred_devices, node) { + result = acpi_bus_scan(deferred_dev->handle); + if (result) + goto cleanup; + + list_del(&deferred_dev->node); + kfree(deferred_dev); + } + /* Fixed feature devices do not exist on HW-reduced platform */ if (!acpi_gbl_reduced_hardware) { result = acpi_bus_scan_fixed(); @@ -2275,6 +2335,11 @@ int __init acpi_scan_init(void) put_device(&acpi_root->dev); } + list_for_each_entry_safe(deferred_dev, tmp, &acpi_deferred_devices, node) { + list_del(&deferred_dev->node); + kfree(deferred_dev); + } + mutex_unlock(&acpi_scan_lock); return result; } From patchwork Sat Nov 21 20:30:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 330023 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6625CC6379F for ; Sat, 21 Nov 2020 20:31:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FC2122201 for ; Sat, 21 Nov 2020 20:31:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SWzVfoZ6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728402AbgKUUaz (ORCPT ); Sat, 21 Nov 2020 15:30:55 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:28787 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728511AbgKUUaz (ORCPT ); Sat, 21 Nov 2020 15:30:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605990653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qIFpuxY58mNlSwyojr2EBGs0nBeW01lQD7+vcwPzDfk=; b=SWzVfoZ6zNLlOkk9fJwK0aNxLZvRXbCRBDT6GO0Gs/49hx4LchCIIzu0+hEE6sYb+Rkjy0 k81cOs8bRfd+zeJ3TcGXGN6FJ8CsidKrXhWCw9s34JB2bI/BvckyEHQBONsajgNw9BprTZ cHNulgCFbqpsrQR4QcktdoriAK00ZhM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-522-WQ4DSXzMN_2V04SP7tlOfA-1; Sat, 21 Nov 2020 15:30:51 -0500 X-MC-Unique: WQ4DSXzMN_2V04SP7tlOfA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C0CDD803F41; Sat, 21 Nov 2020 20:30:50 +0000 (UTC) Received: from x1.localdomain (ovpn-112-24.ams2.redhat.com [10.36.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id D164818E4F; Sat, 21 Nov 2020 20:30:49 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown Cc: Hans de Goede , linux-acpi@vger.kernel.org Subject: [PATCH 5/7] ACPI: scan: Add support for deferring adding devices to the second scan phase based on the _DEP list Date: Sat, 21 Nov 2020 21:30:38 +0100 Message-Id: <20201121203040.146252-6-hdegoede@redhat.com> In-Reply-To: <20201121203040.146252-1-hdegoede@redhat.com> References: <20201121203040.146252-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org The current solution, of deferring adding of some devices because they need access during the OpRegions of other devices while they are added, is not very generic. And support for making the decision to defer adding a device based on its _DEP list, instead of the device's HID being in a fixed list of HIDs to defer, which should be a more generic way to deal with this. Since this is likely to cause issues on some hardware, this new method will only be used if the new acpi.defer_scan_based_on_dep kernel commandline option is set to 1. Signed-off-by: Hans de Goede --- drivers/acpi/scan.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 407c8536568b..9927036bfe77 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -31,6 +31,11 @@ extern struct acpi_device *acpi_root; #define INVALID_ACPI_HANDLE ((acpi_handle)empty_zero_page) +static int defer_scan_based_on_dep = -1; +module_param(defer_scan_based_on_dep, int, 0444); +MODULE_PARM_DESC(defer_scan_based_on_dep, + "Use new scan-scheme deferring addition of devices with non empty _DEP list (-1=auto, 0=no, 1=yes)"); + static const char *dummy_hid = "device"; static LIST_HEAD(acpi_dep_list); @@ -1657,11 +1662,45 @@ void acpi_device_add_finalize(struct acpi_device *device) static bool acpi_should_defer_add(acpi_handle handle, struct acpi_device_info *info) { + struct acpi_handle_list dep_devices; + acpi_status status; + int i; + if (!acpi_check_defer_add || !info) return false; - if (acpi_info_matches_hids(info, acpi_defer_add_hids)) + if (!defer_scan_based_on_dep) + return acpi_info_matches_hids(info, acpi_defer_add_hids); + + /* + * We check for _ADR here to avoid deferring the adding of the following: + * 1. PCI devices + * 2. ACPI nodes describing USB ports + * Note checking for _ADR catches more then just these cases... + */ + if (info->valid & ACPI_VALID_ADR) + return false; + + status = acpi_evaluate_reference(handle, "_DEP", NULL, &dep_devices); + if (ACPI_FAILURE(status)) + return false; + + for (i = 0; i < dep_devices.count; i++) { + struct acpi_device_info *dep_info; + bool ignore; + + status = acpi_get_object_info(dep_devices.handles[i], &dep_info); + if (ACPI_FAILURE(status)) + continue; + + ignore = acpi_info_matches_hids(dep_info, acpi_ignore_dep_hids); + kfree(dep_info); + + if (ignore) + continue; + return true; + } return false; } @@ -2251,6 +2290,10 @@ int __init acpi_scan_init(void) struct acpi_table_stao *stao_ptr; struct acpi_deferred_dev *deferred_dev, *tmp; + /* Currently no devices are known which need _dep based scan deferral */ + if (defer_scan_based_on_dep == -1) + defer_scan_based_on_dep = 0; + acpi_pci_root_init(); acpi_pci_link_init(); acpi_processor_init();