On Thu, 2014-10-16 at 10:05 +0100, Liviu Dudau wrote: > So you are going to continue converting IO ranges as IORESOURCE_MEM resources but with a > different flag. Is that something that powerpc depends on or is it an artifact of too > much code living around the kernel that has built in assumption of that being the fact? > I'm trying to understand the world around powerpc so as to attempt to make a useful > contribution in the future. I'm not sure I understand what you mean and which specific resources you are talking about. For PCI devices, the IO BAR resources have IORESOURCE_IO ... The case where we might get an IORESOURCE_MEM, at least that's how my old code used to work, was is if we try to use the device-tree to convert a PCI IO device address before we have initialized our mappings (ie, before we have probed our PCI host bridges). In that case, we would get an IORESOURCE_MEM (which is functional as long as one ioremap's and uses the proper accessors for memory resources). Once we have the PCI host bridges probed, the IO space is assigned, and such conversion routines will transform the addresses properly into IO resources. Note that it's fairly rare that we use the device-tree for PCI based resources anyway and even rarer than we do that before the PCI host bridges have been properly setup and thus their IO space allocated. Note that the problems exposed by these patches can be entirely reproduced in qemu using virtio, so you should be able to test a little bit if you have a reasonably fast x86 box to run qemu on. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
