All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"David Miller" <davem@davemloft.net>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Wei Yang" <weiyang@linux.vnet.ibm.com>,
	"Khalid Aziz" <khalid.aziz@oracle.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Christian König" <deathsimple@vodafone.de>
Subject: Re: [PATCH 11/13] PCI: Add has_mem64 for struct host_bridge
Date: Thu, 4 May 2017 18:04:25 -0500	[thread overview]
Message-ID: <20170504230425.GC9648@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20170421050500.13957-12-yinghai@kernel.org>

[+cc Christian]

On Thu, Apr 20, 2017 at 10:04:58PM -0700, Yinghai Lu wrote:
> Add has_mem64 for struct host_bridge, on root bus that does not support
> mmio64 above 4g, will not set that.
> 
> We will use that info next two following patches:
> 1. Don't treat non-pref mmio64 as pref mmio, so will not put
>    it under bridge's pref range when rescan the devices
> 2. will keep pref mmio64 and pref mmio32 under bridge pref bar.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
> ---
>  drivers/pci/probe.c | 7 +++++++
>  include/linux/pci.h | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 676b55f..8f439e0 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -818,6 +818,13 @@ int pci_register_host_bridge(struct pci_host_bridge *bridge)
>  			addr[0] = '\0';
>  
>  		dev_info(&bus->dev, "root bus resource %pR%s\n", res, addr);
> +
> +		if (resource_type(res) == IORESOURCE_MEM) {
> +			if ((res->end - offset) > 0xffffffff)
> +				bridge->has_mem64 = 1;

This part makes sense -- if any part of the window extends above 4G,
only a 64-bit BAR can use the part above 4G.

> +			if ((res->start - offset) > 0xffffffff)
> +				res->flags |= IORESOURCE_MEM_64;

But I don't understand this part.  You only set IORESOURCE_MEM_64 if
the *start* is above 4G?  If the window started at 2GB and ended at
6GB, you wouldn't set IORESOURCE_MEM_64?

And I don't understand where this IORESOURCE_MEM_64 in res->flags is
used.  It seems like the only possible place is this test added by the
last patch:

  int pci_bus_alloc_resource(bus, res, ...)
  {
    if (res->flags & mmio64) {

but this patch is setting IORESOURCE_MEM_64 in the host bridge window,
i.e., the bus resource, and pci_bus_alloc_resource() is testing the
flags of the resource we're allocating *from* the bus resource.

> +		}

I *think* this will be broken by the current implementation of
Christian's patch to enable a 64-bit host bridge window:

  https://lkml.kernel.org/r/1493890270-1188-5-git-send-email-deathsimple@vodafone.de

because pci_register_host_bridge() runs before we scan the bus, and
Christian's patch adds a quirk that runs when we enumerate the AMD
host bridge device.

If we apply this and Christian's patch, I think we could end up with
a host bridge window above 4G, but with bridge->has_mem64 not set.

>  	}
>  
>  	down_write(&pci_bus_sem);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index b14dd94..a3693ef 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -436,6 +436,7 @@ struct pci_host_bridge {
>  	void *release_data;
>  	struct msi_controller *msi;
>  	unsigned int ignore_reset_delay:1;	/* for entire hierarchy */
> +	unsigned int has_mem64:1;
>  	/* Resource alignment requirements */
>  	resource_size_t (*align_resource)(struct pci_dev *dev,
>  			const struct resource *res,
> -- 
> 2.9.3
> 

  reply	other threads:[~2017-05-04 23:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  5:04 [PATCH 00/13] PCI: sparc related 64bit resource fixup Yinghai Lu
2017-04-21  5:04 ` [PATCH 01/13] sparc/PCI: Use correct offset for bus address to resource Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-04-21  5:04 ` [PATCH 02/13] PCI: Add pci_find_bus_resource() Yinghai Lu
2017-04-21  5:04 ` [PATCH 03/13] sparc/PCI: Reserve legacy mmio after PCI mmio Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-03 22:03   ` Bjorn Helgaas
2017-05-03 22:03     ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 04/13] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-05 13:34   ` Bjorn Helgaas
2017-05-05 13:34     ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-04-21  5:04 ` [PATCH 06/13] powerpc/PCI: " Yinghai Lu
2017-04-21  5:04 ` [PATCH 07/13] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21  5:04 ` [PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource Yinghai Lu
2017-04-24 14:12   ` Rob Herring
2017-04-24 14:12     ` Rob Herring
2017-04-21  5:04 ` [PATCH 09/13] PCI: Check pref compatible bit for mem64 resource of PCIe device Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-04 21:19   ` Bjorn Helgaas
2017-05-04 21:19     ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 10/13] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 Yinghai Lu
2017-05-04 21:43   ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 11/13] PCI: Add has_mem64 for struct host_bridge Yinghai Lu
2017-05-04 23:04   ` Bjorn Helgaas [this message]
2017-05-08  8:54     ` Christian König
2017-05-08 13:25       ` Bjorn Helgaas
2017-05-09 11:38         ` Christian König
2017-04-21  5:04 ` [PATCH 12/13] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 Yinghai Lu
2017-04-21  5:05 ` [PATCH 13/13] PCI: Restore pref MMIO allocation logic for host bridge without mmio64 Yinghai Lu
2017-05-05  1:24   ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170504230425.GC9648@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=deathsimple@vodafone.de \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=weiyang@linux.vnet.ibm.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.