On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau [off-list ref] wrote:

On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:

quoted

On May 29, 2014, at 3:44 PM, Rob Herring [off-list ref] wrote:

quoted

On Thu, May 29, 2014 at 11:03 AM, Kumar Gala [off-list ref] wrote:

quoted

If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.

Config space should not be in ranges[1]. We have some cases that are,
but we don't want new ones.

For the cases we have I agree, however an ECAM based cfg seems completely legit.

quoted

quoted

Signed-off-by: Kumar Gala <redacted>
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c

@@ -122,6 +122,9 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
       u32 w = be32_to_cpup(addr);

       switch((w >> 24) & 0x03) {
+       case 0x00: /* cfg space */
+               flags |= IORESOURCE_MEM;
+               break;

How would you then distinguish actual memory ranges?

One assumes you are still looking at pci_space as part of of_pci_range

That doesn't happen when you start scanning the bus. The existing code will
use the IORESOURCE_MEM for allocating memory space for devices, which is
not what you want. Did you test your patch on any PCI system? I'm pretty
sure that with my patch series that tries to make a generic framework for
host controllers this will fail.

We really need a IORESOURCE_CFG flag for this space.

Maybe, but I'm not convinced yet.  The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces.  I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc.  The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.

quoted

quoted

[1] http://www.spinics.net/lists/linux-pci/msg30585.html