[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150902200127.GA3347@sean.stalley.intel.com>
Date: Wed, 2 Sep 2015 13:01:27 -0700
From: "Sean O. Stalley" <sean.stalley@...el.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: Yinghai Lu <yinghai@...nel.org>, Rajat Jain <rajatxjain@...il.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Rafał Miłecki <zajec5@...il.com>,
"gong.chen@...ux.intel.com" <gong.chen@...ux.intel.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-api@...r.kernel.org
Subject: Re: [PATCH 2/2] PCI: Add support for Enhanced Allocation devices
On Wed, Sep 02, 2015 at 02:25:50PM -0500, Bjorn Helgaas wrote:
> On Wed, Sep 2, 2015 at 12:46 PM, Sean O. Stalley <sean.stalley@...el.com> wrote:
>
> > Would it be better to modify pci_claim_resource() to support EA instead of adding pci_ea_claim_resource()?
> > That way, EA entries would be claimed at the same time as traditional BARs.
>
> Yes, I think so.
Ok, I'll make it work this way in the next patchset.
> Why wouldn't pci_claim_resource() work as-is for EA? I see that
> pci_ea_get_parent_resource() defaults to iomem_resource or
> ioport_resource if we don't find a parent, but I don't understand why
> that's necessary.
EA resources may (or may not) be in the parent's range[1].
If the parent doesn't describe this range, we want to default to the top-level resource.
Other than that case, I think pci_claim_resource would work as-is.
-Sean
[1] From the EA ECN:
For a bridge function that is permitted to implement EA based on the rules above, it is
permitted, but not required, for the bridge function to use EA mechanisms to indicate
resource ranges that are located behind the bridge Function (see Section 6.9.1.2).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists