From patchwork Wed Apr 15 19:42:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 461633 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CC56C1402D6 for ; Thu, 16 Apr 2015 05:42:33 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="verification failed; unprotected key" header.d=google.com header.i=@google.com header.b=bGCVRrKe; dkim-adsp=none (unprotected policy); dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754419AbbDOTmb (ORCPT ); Wed, 15 Apr 2015 15:42:31 -0400 Received: from mail-ie0-f179.google.com ([209.85.223.179]:34829 "EHLO mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751972AbbDOTma (ORCPT ); Wed, 15 Apr 2015 15:42:30 -0400 Received: by iejt8 with SMTP id t8so35750442iej.2 for ; Wed, 15 Apr 2015 12:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=miEAIHmgdejH9k0toLdDey6oNg9wXgbUHtGhvq1vV5c=; b=bGCVRrKetCdJ/OHUXnxGr29Kmi3ORGQAbnPC+LmE8yoPw4LpgdKXTFN4MoQuf/zfqL JZfXO9mj75zAUrHcuPL0tMhs2HF5a85TmtRU7rROLn3sxQigerQX1XQtfclAoQeHj39E dtnPezRIVZfVR0OfoI5Ldl4Tmmc/mYSP5a84RScTuQ1Ba7wmC2ZNrPlbGBIFVPzDoULo /u7jYv/Z0OBehvdvHmkVF0XZn44R4tYdDWvFGSIZj4V+FQuKJMAJuUmMhrOSsbOhL/YL wdEt8GKOvUG2/VAbS5uxM+x79ZzN8BAlUsgKCTLnTWv8Yg4K1CPex/qAdGABh52gsbGh GvMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=miEAIHmgdejH9k0toLdDey6oNg9wXgbUHtGhvq1vV5c=; b=b+xQOn7Yc5USCOKlN4xuTAuDlaNEvva+BMycoiKMuDp3UQp/yYSNWaCV2ugl66wNfu Phs+EVUlZKOcJWGSu0wxhGGYaYq+f3Q5kmA7zIp0QGs3dNxMXtqzoDF9/DpVKsPG3p0g Wh3W5h9I/7Lb5Q98HENpp2V03R22e82NhIgNJeQ3C6jukiPM9ZXZfydRMLtQfKNyZjzG QkdimC8lJo6rMaKmIjsIvozXtwUKDOiOoXDnCQGZ7ONoVWe1Tnfi68eUubZO/wka457F 6BaQlXbKLmsla35sqNzfLx6+eiKKQnb5nxZO/1cbGHHATdOY8+O0PAG+DZM27r5wz/eU oLBA== X-Gm-Message-State: ALoCoQkJI6C/92SGTDRq40Dw+fT1/SWgxYP+FnrsLcgJeOsgWhDdw/WtwUBVjmHcXlph9A6RBwBv X-Received: by 10.107.47.163 with SMTP id v35mr37036171iov.86.1429126949473; Wed, 15 Apr 2015 12:42:29 -0700 (PDT) Received: from google.com ([69.71.1.1]) by mx.google.com with ESMTPSA id w33sm2974162ioi.17.2015.04.15.12.42.28 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 15 Apr 2015 12:42:28 -0700 (PDT) Date: Wed, 15 Apr 2015 14:42:26 -0500 From: Bjorn Helgaas To: Tony Luck Cc: "linux-pci@vger.kernel.org" , linux-acpi , "Rafael J . Wysocki" , Jiang Liu Subject: Re: [PATCH v1 2/4] PCI: Mark invalid BARs as unassigned Message-ID: <20150415194226.GA27352@google.com> References: <20150312173201.1052.28341.stgit@bhelgaas-glaptop2.roam.corp.google.com> <20150312173533.1052.46464.stgit@bhelgaas-glaptop2.roam.corp.google.com> <20150415144819.GD19151@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org [+cc Rafael, Jiang] On Wed, Apr 15, 2015 at 09:27:41AM -0700, Tony Luck wrote: > > + /* ACPI_RESOURCE_TYPE_IRQ etc. */ > > + printk("host bridge resource %02d length %#02x\n", res->type, > > + res->length); > > + print_hex_dump(KERN_INFO, " : ", DUMP_PREFIX_OFFSET, 16, 1, > > + &res->data, res->length, 0); > > + > > Patch applied to the tree with the offending commit reverted. Serial > log attached, Thanks. Your log shows several descriptors that we currently ignore because their Producer/Consumer bits are set to "Consumer". Here's one that contains the MMIO area used by these igb and mptsas devices: host bridge resource 12 length 0x38 ACPI_RESOURCE_TYPE_ADDRESS32 : 00000000: 00 01 00 01 01 01 00 00 00 00 00 00 00 00 00 00 : 00000010: 00 00 00 a0 ff ff ff ef 00 00 00 00 00 00 00 50 : 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000030: 0d 00 00 00 50 00 00 00 [mem 0xa0000000-0xefffffff] I think we're about to conclude that the Producer/Consumer bit is useless and should be ignored. Can you drop the previous debug patch and try this one? --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c index 48cc65705db4..cd96ddc2bc6c 100644 --- a/arch/ia64/pci/pci.c +++ b/arch/ia64/pci/pci.c @@ -240,15 +240,12 @@ static acpi_status resource_to_window(struct acpi_resource *resource, * We're only interested in _CRS descriptors that are * - address space descriptors for memory or I/O space * - non-zero size - * - producers, i.e., the address space is routed downstream, - * not consumed by the bridge itself */ status = acpi_resource_to_address64(resource, addr); if (ACPI_SUCCESS(status) && (addr->resource_type == ACPI_MEMORY_RANGE || addr->resource_type == ACPI_IO_RANGE) && - addr->address.address_length && - addr->producer_consumer == ACPI_PRODUCER) + addr->address.address_length) return AE_OK; return AE_ERROR; @@ -276,6 +273,12 @@ static acpi_status add_window(struct acpi_resource *res, void *data) unsigned long flags, offset = 0; struct resource *root; + /* ACPI_RESOURCE_TYPE_IRQ etc. */ + printk("host bridge resource %02d length %#02x\n", res->type, + res->length); + print_hex_dump(KERN_INFO, " : ", DUMP_PREFIX_OFFSET, 16, 1, + &res->data, res->length, 0); + /* Return AE_OK for non-window resources to keep scanning for more */ status = resource_to_window(res, &addr); if (!ACPI_SUCCESS(status)) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 5589a6e2a023..ae5534a6bce7 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -483,6 +483,11 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares, struct resource *res = &win.res; int i; + printk("process resource %02d length %#02x\n", ares->type, + ares->length); + print_hex_dump(KERN_INFO, " : ", DUMP_PREFIX_OFFSET, 16, 1, + &ares->data, ares->length, 0); + if (c->preproc) { int ret;