On Tuesday 29 January 2013, Bjorn Helgaas wrote: > If you need this, it can be done in architecture code, can't it? It's > true that there's nothing architecture-specific in this patch (other > than the fact that ARM is the only arch that needs it), but I'm not > sure there's anything useful for sharing here. Since we're moving the host bridge code to drivers/pci/host now, I think this code should live in the same place. It's entirely possible that it will be shared between arch/arm and arch/arm64, although I would hope that we can do away with the emulated bridge code entirely. More generally speaking, this is infrastructure code, and for any piece of infrastructure my rule is * don't add platform specific infrastructure if it can be done at the architecture level * don't add architecture specific infrastructure if it can be written in an architecture independent way * don't add global infrastructure if you can use or extend the existing infrastructure. > In fact, it seems like what you're after is not so much an emulated > bridge that has no corresponding hardware, as it is a wrapper that > presents a standard PCIe interface to hardware that exists but doesn't > conform to the PCIe spec. If you really do need to ultimately connect > this pci_sw_pci_bridge to a piece of hardware, that will certainly be > arch-specific. As Jason Gunthorpe suggested, we might not need this at all, if the Linux PCI code can be convinced not to need a configuration space for the devices that in case of the Marvell hardware don't provide one. Arnd -- 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
