On Thu, Jul 10, 2014 at 3:47 AM, Liviu Dudau Liviu.Dudau@arm.com wrote:
I don't see a way out of adding new PCI interfaces if we want to have support in the PCI framework for unifying existing architectures. Of course, there is the painful alternative of changing the existing APIs and fixing arches in one go, but like you've said is going to be messy. I don't think I (or the people and companies wanting PCIe on arm64) should cop out and pick a quick fix that adds sysdata structure into arm64 just to avoid new APIs, as this is not going to help anyone in long term. What I can do is to create a set of parallel APIs for pci_{scan,create}_root_bus() that take a pci_host_bridge pointer and start converting architectures one by one to that API while deprecating the existing one. That way we can add arm64 easily as it would be the first architecture to use new code without breaking things *and* we provide a migration path.
A lot of the v7 discussion was about pci_register_io_range(). I apologize, because I think I really derailed things there and it was unwarranted. Arnd was right that migrating other arches should be a separate effort. I *think* I was probably thinking about the proposal of adding pci_create_root_bus_in_domain(), and my reservations about that got transferred to the pci_register_io_range() discussion. In any case, I'm completely fine with pci_register_io_range() now.
Most of the rest of the v7 discussion was about "Introduce a domain number for pci_host_bridge." I think we should add arm64 using the existing pci_scan_root_bus() and keep the domain number in the arm64 sysdata structure like every other arch does. Isn't that feasible? We can worry about domain unification later.
I haven't followed closely enough to know what other objections people had.
Bjorn