From patchwork Tue Sep 13 12:19:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mika Westerberg X-Patchwork-Id: 9328929 X-Patchwork-Delegate: bhelgaas@google.com 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 75EC46048F for ; Tue, 13 Sep 2016 12:20:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 69DE5293F1 for ; Tue, 13 Sep 2016 12:20:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5E9AC293F5; Tue, 13 Sep 2016 12:20:51 +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 30558293F4 for ; Tue, 13 Sep 2016 12:20:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753274AbcIMMUr (ORCPT ); Tue, 13 Sep 2016 08:20:47 -0400 Received: from mga09.intel.com ([134.134.136.24]:23085 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753684AbcIMMUr (ORCPT ); Tue, 13 Sep 2016 08:20:47 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 13 Sep 2016 05:20:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,328,1470726000"; d="scan'208";a="1029258851" Received: from black.fi.intel.com ([10.237.72.56]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2016 05:20:43 -0700 Received: by black.fi.intel.com (Postfix, from userid 1001) id 9ECCC115; Tue, 13 Sep 2016 15:19:42 +0300 (EEST) From: Mika Westerberg To: Bjorn Helgaas , "Rafael J . Wysocki" Cc: Aaron Durbin , Andy Shevchenko , Mika Westerberg , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org Subject: [PATCH 2/2] ACPI / platform: Pay attention to parent device's resources Date: Tue, 13 Sep 2016 15:19:42 +0300 Message-Id: <20160913121942.80356-2-mika.westerberg@linux.intel.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20160913121942.80356-1-mika.westerberg@linux.intel.com> References: <20160913121942.80356-1-mika.westerberg@linux.intel.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Given following simplified device hierarchy: // PCI device having BAR0 (RMEM) split between 4 GPIO devices. Device (P2S) { Name (_ADR, 0x000d0000) Device (GPO0) { Name (_HID, "INT3452") Name (_UID, 1) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000) }) } Device (GPO1) { Name (_HID, "INT3452") Name (_UID, 2) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000) }) } Device (GPO2) { Name (_HID, "INT3452") Name (_UID, 3) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000) }) } Device (GPO3) { Name (_HID, "INT3452") Name (_UID, 4) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000) }) } } The current ACPI platform enumeration code allocates resources from the global MMIO resource pool (/proc/iomem) for all the four GPIO devices. After this PCI core calls pcibios_resource_survey() to allocate resources for all PCI devices including the parent device for these GPIO devices (P2S). Since that resource range has already been reserved the allocation fails. The reason for this is that we never bother with parent device's resources when ACPI platform devices are created. Fix this by checking whether there is a parent device and in that case make sure we assign correct parent resource to the resources for the child ACPI platform device. Currently we only deal with parent devices if they are PCI devices but we may expand this later to cover other bus types as well. Reported-by: Aaron Durbin Signed-off-by: Mika Westerberg --- drivers/acpi/acpi_platform.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 159f7f19abce..b200ae1f3c6f 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include "internal.h" @@ -30,6 +31,22 @@ static const struct acpi_device_id forbidden_id_list[] = { {"", 0}, }; +static void acpi_platform_fill_resource(struct acpi_device *adev, + const struct resource *src, struct resource *dest) +{ + struct device *parent; + + *dest = *src; + + /* + * If the device has parent we need to take its resources into + * account as well because this device might consume part of those. + */ + parent = acpi_get_first_physical_node(adev->parent); + if (parent && dev_is_pci(parent)) + dest->parent = pci_find_resource(to_pci_dev(parent), dest); +} + /** * acpi_create_platform_device - Create platform device for ACPI device node * @adev: ACPI device node to create a platform device for. @@ -70,7 +87,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) } count = 0; list_for_each_entry(rentry, &resource_list, node) - resources[count++] = *rentry->res; + acpi_platform_fill_resource(adev, rentry->res, + &resources[count++]); acpi_dev_free_resource_list(&resource_list); }