On Monday 10 March 2014 14:45:19 Liviu Dudau wrote: > > So, if I understand you correctly, you would prefer to fail here and hence stop the > parsing for the x86, rather than pretending everything is OK and going through the > motions? Yes, on x86 it is clearly a bug if we end up calling this function. > That was not my original thinking when I've introduced this function here. The main > purpose of the function is to help the correct translation of IO addresses in > pci_address_to_pio(). As Jason has explained very nicely, we have 3 types of > architectures here that we try to support: > - the ones that have separate IO address space (x86) > - the ones that have 1:1 mapping between physical IO addresses and logical ports Still not convinced this second one actually exists. > - the architectures that memory map the IO addresses in virtual address space > and then translate the logical addresses into virtual based on a given offset. > > For the first two types we don't want to do anything special. Architectures that > fall in the last category will have to provide their own version of this function, > with the arm64 version being generic enough to be used as de facto? The page flags might be different across architectures: arm32 currently uses MT_DEVICE, which only exists on arm32 and derived architectures (unicore32, arm64). > But I can see your point of view as well. I just don't know if that is good enough > for powerpc and microblaze. With the way things are in my patch, they should be able > to switch to of_create_pci_host_bridge() easily*, with your suggestion they will > have to provide their implementation for pci_register_io_range(). I think there would still be a lot to do have powerpc switch over to of_create_pci_host_bridge(), the more likely thing to happen is to have that architecture implement its own copy that calls the same internal helpers and does some more things that we may not want on other architectures. Microblaze can probably be changed to use of_create_pci_host_bridge() and need no custom code at all, it should need only a subset of what we need for arm64. > We really need to get another architecture converted. If there are no other takers I > will make a stab once the current push towards upstreaming AArch64 hardware support > slows down. Moving over microblaze I think would be a good start. It has rather specific requirements since there is only one host driver, but then again that PCI host implementation might be shared with zynq (or synthesizable there). I also wonder whether it's actually related to the X-gene PCI, since I know some of the ppc4xx use Xilinx PCI and X-gene is also based on those. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
