All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Sunil Kovvuri <sunil.kovvuri@gmail.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linaro-kernel <linaro-kernel@lists.linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Scott Lurndal <kdb@lurndal.org>,
	"yu.zhao@intel.com" <yu.zhao@intel.com>
Subject: Re: [PATCH v7 0/3] Add support for PCI in AArch64
Date: Tue, 20 May 2014 10:44:30 +0200	[thread overview]
Message-ID: <5759329.P75jKFdv3B@wuerfel> (raw)
In-Reply-To: <CA+sq2Ce+8YB+02B7zhxTXwropZXv9spy-w=AJ8YXCP69kr-_1A@mail.gmail.com>

On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
> >> In sriov_enable() (drivers/pci/iov.c)
> >>
> >>  296        for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >>  297                 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >>  298                 res = dev->resource + PCI_IOV_RESOURCES + i;
> >>  299                 if (res->parent)
> >>  300                         nres++;
> >>  301         }
> >>  302         if (nres != iov->nres) {
> >>  303                 dev_err(&dev->dev, "not enough MMIO resources for
> >>  SR-IOV\n");
> >>  304                 return -ENOMEM;
> >>  305         }
> >>
> >> Here its checking if physical function's IOV resource has a parent or not.
> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >> that resource.
> >>
> >> Added below api to your patch.
> >> This will try to claim a resource while creating a PCI device which
> >> inturn sets 'res->parent'.
> >
> > This looks like the wrong approach. The PCI host controller should
> > really have been registered with the root 'iomem_resource' during
> > the probe of the host controller.
> >
> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
> and inturn bridge connected to root port. Then the parent bus is not root,
> but the bridge.  The issue is either hierarchy should not be checked for
> SR-IOV resources or someone should set the hierarchy (i.e parent resources).

Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.

It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 0/3] Add support for PCI in AArch64
Date: Tue, 20 May 2014 10:44:30 +0200	[thread overview]
Message-ID: <5759329.P75jKFdv3B@wuerfel> (raw)
In-Reply-To: <CA+sq2Ce+8YB+02B7zhxTXwropZXv9spy-w=AJ8YXCP69kr-_1A@mail.gmail.com>

On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
> >> In sriov_enable() (drivers/pci/iov.c)
> >>
> >>  296        for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >>  297                 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >>  298                 res = dev->resource + PCI_IOV_RESOURCES + i;
> >>  299                 if (res->parent)
> >>  300                         nres++;
> >>  301         }
> >>  302         if (nres != iov->nres) {
> >>  303                 dev_err(&dev->dev, "not enough MMIO resources for
> >>  SR-IOV\n");
> >>  304                 return -ENOMEM;
> >>  305         }
> >>
> >> Here its checking if physical function's IOV resource has a parent or not.
> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >> that resource.
> >>
> >> Added below api to your patch.
> >> This will try to claim a resource while creating a PCI device which
> >> inturn sets 'res->parent'.
> >
> > This looks like the wrong approach. The PCI host controller should
> > really have been registered with the root 'iomem_resource' during
> > the probe of the host controller.
> >
> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
> and inturn bridge connected to root port. Then the parent bus is not root,
> but the bridge.  The issue is either hierarchy should not be checked for
> SR-IOV resources or someone should set the hierarchy (i.e parent resources).

Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.

It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Sunil Kovvuri <sunil.kovvuri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>,
	linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	linaro-kernel
	<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LAKML
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Tanmay Inamdar <tinamdar-qTEPVZfXA3Y@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	Scott Lurndal <kdb-JdWt/H98ok1AfugRpC6u6w@public.gmane.org>,
	"yu.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
	<yu.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v7 0/3] Add support for PCI in AArch64
Date: Tue, 20 May 2014 10:44:30 +0200	[thread overview]
Message-ID: <5759329.P75jKFdv3B@wuerfel> (raw)
In-Reply-To: <CA+sq2Ce+8YB+02B7zhxTXwropZXv9spy-w=AJ8YXCP69kr-_1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
> >> In sriov_enable() (drivers/pci/iov.c)
> >>
> >>  296        for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >>  297                 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >>  298                 res = dev->resource + PCI_IOV_RESOURCES + i;
> >>  299                 if (res->parent)
> >>  300                         nres++;
> >>  301         }
> >>  302         if (nres != iov->nres) {
> >>  303                 dev_err(&dev->dev, "not enough MMIO resources for
> >>  SR-IOV\n");
> >>  304                 return -ENOMEM;
> >>  305         }
> >>
> >> Here its checking if physical function's IOV resource has a parent or not.
> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >> that resource.
> >>
> >> Added below api to your patch.
> >> This will try to claim a resource while creating a PCI device which
> >> inturn sets 'res->parent'.
> >
> > This looks like the wrong approach. The PCI host controller should
> > really have been registered with the root 'iomem_resource' during
> > the probe of the host controller.
> >
> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
> and inturn bridge connected to root port. Then the parent bus is not root,
> but the bridge.  The issue is either hierarchy should not be checked for
> SR-IOV resources or someone should set the hierarchy (i.e parent resources).

Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.

It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-05-20  8:44 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14 15:34 [PATCH v7 0/3] Add support for PCI in AArch64 Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 1/3] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases Liviu Dudau
2014-03-14 15:34   ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 2/3] arm64: Extend the PCI I/O space to 16MB Liviu Dudau
2014-03-14 15:34   ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 3/3] arm64: Add architecture support for PCI Liviu Dudau
2014-03-14 15:34   ` Liviu Dudau
2014-03-14 17:14   ` Catalin Marinas
2014-03-14 17:14     ` Catalin Marinas
2014-03-14 17:38     ` Arnd Bergmann
2014-03-14 17:38       ` Arnd Bergmann
2014-03-14 17:38       ` Arnd Bergmann
2014-03-14 18:05       ` Liviu Dudau
2014-03-14 18:05         ` Liviu Dudau
2014-03-14 19:10         ` Arnd Bergmann
2014-03-14 19:10           ` Arnd Bergmann
2014-03-16  6:22           ` Benjamin Herrenschmidt
2014-03-16  6:22             ` Benjamin Herrenschmidt
2014-03-16  6:22             ` Benjamin Herrenschmidt
2014-03-17 17:38         ` Catalin Marinas
2014-03-17 17:38           ` Catalin Marinas
2014-03-17 18:05           ` Liviu Dudau
2014-03-17 18:05             ` Liviu Dudau
2014-03-19 13:56             ` Catalin Marinas
2014-03-19 13:56               ` Catalin Marinas
2014-03-19 17:21               ` Liviu Dudau
2014-03-19 17:21                 ` Liviu Dudau
2014-03-19 17:53                 ` Rob Herring
2014-03-19 17:53                   ` Rob Herring
2014-03-19 17:53                   ` Rob Herring
2014-03-19 18:36                   ` Arnd Bergmann
2014-03-19 18:36                     ` Arnd Bergmann
2014-03-19 18:37                 ` Arnd Bergmann
2014-03-19 18:37                   ` Arnd Bergmann
2014-03-20  9:46                   ` Liviu Dudau
2014-03-20  9:46                     ` Liviu Dudau
2014-03-20 11:17                     ` Arnd Bergmann
2014-03-20 11:17                       ` Arnd Bergmann
2014-03-20 11:38                       ` Liviu Dudau
2014-03-20 11:38                         ` Liviu Dudau
2014-03-20 12:26                         ` Arnd Bergmann
2014-03-20 12:26                           ` Arnd Bergmann
2014-03-20 12:26                           ` Arnd Bergmann
2014-03-20 12:50                           ` Liviu Dudau
2014-03-20 12:50                             ` Liviu Dudau
2014-03-17 16:05   ` Rob Herring
2014-03-17 16:05     ` Rob Herring
2014-03-17 16:05     ` Rob Herring
2014-03-17 16:22     ` Liviu Dudau
2014-03-17 16:22       ` Liviu Dudau
2014-04-07 23:58   ` Bjorn Helgaas
2014-04-07 23:58     ` Bjorn Helgaas
2014-04-08  9:52     ` Liviu Dudau
2014-04-08  9:52       ` Liviu Dudau
2014-04-08  9:52       ` Liviu Dudau
2014-04-22  8:58 ` [PATCH v7 0/3] Add support for PCI in AArch64 Sandeepa Prabhu
2014-04-22  8:58   ` Sandeepa Prabhu
2014-04-22 10:11   ` Liviu Dudau
2014-04-22 10:11     ` Liviu Dudau
2014-04-22 10:11     ` Liviu Dudau
2014-04-22 11:50     ` Sandeepa Prabhu
2014-04-22 11:50       ` Sandeepa Prabhu
2014-04-22 12:34       ` Liviu Dudau
2014-04-22 12:34         ` Liviu Dudau
2014-04-23 20:32       ` Tanmay Inamdar
2014-04-23 20:32         ` Tanmay Inamdar
2014-04-24  3:08         ` Sandeepa Prabhu
2014-04-24  3:08           ` Sandeepa Prabhu
2014-05-16 10:33 ` Sunil Kovvuri
2014-05-16 10:33   ` Sunil Kovvuri
2014-05-16 13:24   ` Liviu Dudau
2014-05-16 13:24     ` Liviu Dudau
2014-05-16 13:24     ` Liviu Dudau
2014-05-16 17:42     ` Sunil Kovvuri
2014-05-16 17:42       ` Sunil Kovvuri
2014-05-21 11:15       ` Sunil Kovvuri
2014-05-21 11:15         ` Sunil Kovvuri
2014-05-21 11:34         ` Liviu Dudau
2014-05-21 11:34           ` Liviu Dudau
2014-05-21 11:34           ` Liviu Dudau
2014-05-21 17:06           ` Jason Gunthorpe
2014-05-21 17:06             ` Jason Gunthorpe
2014-05-21 17:06             ` Jason Gunthorpe
2014-05-19 13:01   ` Arnd Bergmann
2014-05-19 13:01     ` Arnd Bergmann
2014-05-20  4:22     ` Sunil Kovvuri
2014-05-20  4:22       ` Sunil Kovvuri
2014-05-20  8:44       ` Arnd Bergmann [this message]
2014-05-20  8:44         ` Arnd Bergmann
2014-05-20  8:44         ` Arnd Bergmann
2014-05-20  8:55         ` Sunil Kovvuri
2014-05-20  8:55           ` Sunil Kovvuri
2014-05-20  8:55           ` Sunil Kovvuri

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=5759329.P75jKFdv3B@wuerfel \
    --to=arnd@arndb.de \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kdb@lurndal.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sunil.kovvuri@gmail.com \
    --cc=tinamdar@apm.com \
    --cc=yu.zhao@intel.com \
    /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.