From: "Sean O. Stalley" <sean.stalley@intel.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "David Daney" <ddaney@caviumnetworks.com>,
"David Daney" <ddaney.cavm@gmail.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-api@vger.kernel.org, "Rajat Jain" <rajatxjain@gmail.com>,
"gong.chen@linux.intel.com" <gong.chen@linux.intel.com>,
"David Daney" <david.daney@cavium.com>
Subject: Re: [PATCH v4 3/5] PCI: Handle IORESOURCE_PCI_FIXED when sizing and assigning resources.
Date: Mon, 5 Oct 2015 15:44:12 -0700 [thread overview]
Message-ID: <20151005224412.GB4821@sean.stalley.intel.com> (raw)
In-Reply-To: <CAE9FiQVr9E4w80ZSeTgKKwbGQ=NQiReSRnfoGF3D3+3NXj-G3Q@mail.gmail.com>
On Fri, Oct 02, 2015 at 08:00:20PM -0700, Yinghai Lu wrote:
> On Fri, Oct 2, 2015 at 4:38 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> > On 10/02/2015 04:14 PM, Yinghai Lu wrote:
> >>
> >> https://patchwork.kernel.org/patch/7304371/
> >> [v6,06/53] PCI: Claim fixed resource during remove/rescan path
> >
> >
> > This one is interesting, but I don't think it will work.
> >
> > pci_claim_resource() calls pci_find_parent_resource(), which will fail in
> > important use cases.
> >
> > It is perfectly legal for a bridge provisioned by EA to not specify any
> > resources. In this case we must walk up the bus tree until we find
> > something that contains the device resource, and can thus be a parent.
> >
> > That is a big part of what my patch is doing.
>
> looks we need another resource flags for EA in addition to
> FIXED as it could out side of bridge MMIO range.
I think I get what you are saying, but let me check.
If a bridge gets reconfigured, it needs to be able to tell if this resource is EA or not.
If it is a fixed EA resource, it doesn't need to include it in its MMIO range.
If it is fixed for some other reason,
we should make sure the bridges MMIO range includes the fixed region.
You are suggesting that we should add a flag for EA, so if a bridge tries to move,
the bridge knows weather or not the resource is EA,
and therefore if it needs to worry about the resource when setting it's range?
Is that what you are trying to say?
-Sean
next prev parent reply other threads:[~2015-10-05 22:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 22:37 [PATCH v4 0/5] PCI: Add support for PCI Enhanced Allocation "BARs" David Daney
2015-10-02 22:37 ` [PATCH v4 1/5] PCI: Add Enhanced Allocation register entries David Daney
2015-10-02 22:37 ` [PATCH v4 2/5] PCI: Add support for Enhanced Allocation devices David Daney
2015-10-02 22:37 ` [PATCH v4 4/5] PCI: Handle Enhanced Allocation (EA) capability for SRIOV devices David Daney
2015-10-02 22:37 ` [PATCH v4 5/5] PCI: Handle Enhanced Allocation (EA) capability for bridges David Daney
[not found] ` <1443825476-26880-6-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-05 22:54 ` Sean O. Stalley
2015-10-05 23:01 ` David Daney
[not found] ` <1443825476-26880-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-02 22:37 ` [PATCH v4 3/5] PCI: Handle IORESOURCE_PCI_FIXED when sizing and assigning resources David Daney
2015-10-02 23:14 ` Yinghai Lu
2015-10-02 23:38 ` David Daney
2015-10-03 3:00 ` Yinghai Lu
2015-10-05 22:44 ` Sean O. Stalley [this message]
[not found] ` <1443825476-26880-4-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-05 22:23 ` Sean O. Stalley
[not found] ` <20151005222351.GA4821-KQ5zpJUXklQTH34CoL1+91DQ4js95KgL@public.gmane.org>
2015-10-06 20:58 ` David Daney
2015-10-02 23:47 ` [PATCH v4 0/5] PCI: Add support for PCI Enhanced Allocation "BARs" Sean O. Stalley
2015-10-03 3:16 ` Yinghai Lu
[not found] ` <CAE9FiQXT0ux42gQ+DhpVv2K=BR4jC++LmNdCSLiK4Wy0BhL=HQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-05 16:49 ` David Daney
2015-10-05 23:05 ` Sean O. Stalley
2015-10-06 1:17 ` David Daney
2015-10-06 15:47 ` Sean O. Stalley
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=20151005224412.GB4821@sean.stalley.intel.com \
--to=sean.stalley@intel.com \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=ddaney@caviumnetworks.com \
--cc=gong.chen@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=rajatxjain@gmail.com \
--cc=yinghai@kernel.org \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).