From patchwork Thu Apr 17 03:30:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yinghai Lu X-Patchwork-Id: 4005511 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D54149F2BA for ; Thu, 17 Apr 2014 03:30:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6FF462034F for ; Thu, 17 Apr 2014 03:30:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 986A72034A for ; Thu, 17 Apr 2014 03:30:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757107AbaDQDav (ORCPT ); Wed, 16 Apr 2014 23:30:51 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:43444 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756882AbaDQDau (ORCPT ); Wed, 16 Apr 2014 23:30:50 -0400 Received: by mail-ie0-f171.google.com with SMTP id ar20so11484271iec.30 for ; Wed, 16 Apr 2014 20:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0c2Rg5gvVm+vVtpdOez6I07daTOb46JDqvDglEMP3FQ=; b=lOmeRlJGTLGAeWIvBu+Zwi69p8y1emhbX+HnoPVV7NcGc49QXemI6DVYvbCgo4mWa3 gxCkUodpWdMU1bk/di1WdK+ZzlbLaEnXTipQD9HjJ0i/Cgpfvx/Pq38maCknC58wdYnL 285G9TZPsAoVeKag0wjo1cvSw61s7eqNrtqMgi+x/dibewk0ThftT7k3TkLFCjJVX87X 6Co+OYOFt4zWcRYao6e/phhgxx+QsCYQcjqFiNQ2RhLpwwDqjmU9AaB16LVz6C4TWblP xgz4W5jp+vnny1v29AXOtPq2j5J8mNdnmRA1PBzv/FQIghkpmwx13AqYEi8m1u7yLb9K Lu3w== MIME-Version: 1.0 X-Received: by 10.50.154.66 with SMTP id vm2mr14141714igb.4.1397705450353; Wed, 16 Apr 2014 20:30:50 -0700 (PDT) Received: by 10.64.168.72 with HTTP; Wed, 16 Apr 2014 20:30:50 -0700 (PDT) In-Reply-To: References: <1394222924-28886-1-git-send-email-yinghai@kernel.org> <20140408025738.GA3198@yanx> <20140409075215.GA3173@yanx> <20140415115450.GA7792@yanx> Date: Wed, 16 Apr 2014 20:30:50 -0700 X-Google-Sender-Auth: xDARfzPAtniCPqkWxX_nnSM5ri8 Message-ID: Subject: Re: [PATCH v7] PCI: Try best to allocate pref mmio 64bit above 4g From: Yinghai Lu To: Bjorn Helgaas Cc: Guo Chao , Benjamin Herrenschmidt , Wei Yang , Gavin Shan , Jack Morgenstein , Amir Vadai , Or Gerlitz , Eugenia Emantayev , talal@mellanox.com, "linux-pci@vger.kernel.org" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Apr 16, 2014 at 10:06 AM, Bjorn Helgaas wrote: > I think we should stop putting PCI_PREF_RANGE_TYPE_64 in res->flags. > I don't think we ever test for PCI_PREF_RANGE_TYPE_64 today, except > for the trivial usage in pci_read_bridge_mmio_pref(), which can be > easily removed. > > Everywhere else, we use IORESOURCE_MEM, IORESOURCE_MEM_64, and > IORESOURCE_PREFETCH to keep track of the properties of the hardware > underlying the struct resource, i.e., the BAR. Why shouldn't we do > the same for bridge windows? > > The struct resource flags should tell us the *possible* properties of > the window, e.g., what the bridge can support. These properties are > fixed by the bridge hardware, regardless of what devices happen to be > below the bridge. We discover those properties at enumeration-time, > and we shouldn't change them afterwards. After this patch (we check exact type with 64bit pref), actually bridge flags IORESOURCE_MEM_64 would not get cleared. so we don't check that in pbus_size_mem anymore. Following patch could be applied later. Subject: [PATCH] PCI: don't update bridge resource flags according to children After PCI: Try best to allocate pref mmio 64bit above 4g We don't need to check if children support 64bit, and update bridge resource flags anymore. As the code size and assign according exact type already. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) Subject: [PATCH] PCI: don't update bridge resource flags according to children After PCI: Try best to allocate pref mmio 64bit above 4g We don't need to check if children support 64bit, and update bridge resource flags anymore. As the code size and assign according exact type already. Signed-off-by: Yinghai Lu --- drivers/pci/setup-bus.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -926,7 +926,6 @@ static int pbus_size_mem(struct pci_bus int order, max_order; struct resource *b_res = find_free_bus_resource(bus, mask | IORESOURCE_PREFETCH, type); - unsigned int mem64_mask = 0; resource_size_t children_add_size = 0; if (!b_res) @@ -936,9 +935,6 @@ static int pbus_size_mem(struct pci_bus max_order = 0; size = 0; - mem64_mask = b_res->flags & IORESOURCE_MEM_64; - b_res->flags &= ~IORESOURCE_MEM_64; - list_for_each_entry(dev, &bus->devices, bus_list) { int i; @@ -980,7 +976,6 @@ static int pbus_size_mem(struct pci_bus aligns[order] += align; if (order > max_order) max_order = order; - mem64_mask &= r->flags & IORESOURCE_MEM_64; if (realloc_head) children_add_size += get_res_add_size(realloc_head, r); @@ -1005,7 +1000,7 @@ static int pbus_size_mem(struct pci_bus } b_res->start = min_align; b_res->end = size0 + min_align - 1; - b_res->flags |= IORESOURCE_STARTALIGN | mem64_mask; + b_res->flags |= IORESOURCE_STARTALIGN; if (size1 > size0 && realloc_head) { add_to_list(realloc_head, bus->self, b_res, size1-size0, min_align); dev_printk(KERN_DEBUG, &bus->self->dev, "bridge window "