On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala [off-list ref] wrote:

On Jun 2, 2014, at 10:09 AM, Grant Likely [off-list ref] wrote:

quoted

On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann [off-list ref] wrote:

quoted

On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:

quoted

We would like to be able to describe PCIe ECAM resources as
IORESOURCE_MEM blocks while distinguish them from standard
memory resources. Add an IORESOURCE_BIT entry for this case.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

I still don't see any value in this at all. What is the advantage
of doing this opposed to just having a standardized 'reg' property
for a particular compatible string?

I'm inclined to agree. It doesn't seem appropriate to put config space
in ranges, and the host controller binding is responsible for
identifying how config space is memory mapped.

g.

I don???t agree when it comes to ECAM, but we can drop this for now
until someone really does that.

Okay, humor me then. What would a ranges property look like for ECAM? Do
you have an example? I believe there would need to be a separate entry
for each and every PCI device on the bus to get the config spaces to be
contiguous.

However, what do we do with the 2 cases that exist in upstream that
are using ranges for cfg space?

Ignore them in the core code? Make the specific host controller handle
them I would think.

g.