On Thu, 2014-10-16 at 13:55 +1100, Michael Ellerman wrote: > Yes, we already provide our own version of pci_address_to_pio(). > > The problem is it's too early to call it when we come in from > find_and_init_phbs() -> pci_process_bridge_OF_ranges(), so it returns junk. > > I think you were expecting us to hit the #ifndef PCI_IOBASE case, which looks > like it might have worked. > > For now we're just going to stop using of_pci_range_to_resource(). Right, this is a band-aid to fix things now. For the long run, I think we could exploit Liviu's code with a few changes: - We would want to add a variant of pci_register_io_range() that takes the actual PIO address as an argument so we can use it to "register" our ranges on ppc64 since we decide where in IO space they go using our own algorithm and we don't want to change that. That would make the generic pci_pio_to_address() and pci_address_to_pio() work for us. At least for ppc64. - For ppc32, we might want to consider changing the horrible pointer arithmetic we do today (which keeps breaking) and just switch to the allocator inside pci_register_io_range() and use it like ARM does. - I object to of_pci_range_to_resource() implicitly doing the allocation/registration of the range. It should fail if the range isn't registered. The architecture code should explicitly register the IO ranges before trying to turn them into resources. Now, this will take a bit more time to sort out (and the latter comment will mean, if addressed, some changes to the new ARM code which I don't think I have the bandwidth to do), so I'm happy to settle for whatever band-aid Michael is coming up with for 3.18 but we should consider improving things for .19 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
