On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote: > Half of it ;-) > > I think it would be better to not have an architecture specific data > structure, just like it would be better not to have architecture specific > pcibios_* functions that get called by the PCI core. Note that the > architecture specific functions are the ones that rely on the architecture > specific data structures as well. If they only use the common fields, > it should also be possible to share the code. I don't understand... we'll never get rid of architecture specific hooks in one form or another. We'll always need to some things in an architecture or host-bridge specific way. Now if you don't want to call them arch hooks, then call them host bridge ops, but they are needed and thus they will need some kind of architecture specific extension to the base host bridge structure. EEH is one big nasty example on powerpc. Another random one that happens to be hot in my brain right now because we just finished debugging it: On powernv, we are just fixing a series of bugs caused by the generic code trying to do hot resets on PCIe "by hand" by directly toggling the secondary reset register in bridges. Well, on our root complexes, this triggers a link loss which triggers a fatal EEH "ER_all" interrupt which we escalate into a fence and all hell breaks loose. We need to mask some error traps in the hardware before doing something that can cause an intentional link loss... and unmask them when done. (Among other things, there are other issues on P7 with hot reset). So hot reset must be an architecture hook. PERST (fundamental reset) can *only* be a hook. The way to generate a PERST is not specified. In fact, on our machines, we have special GPIOs we can use to generate PERST on individual slots below a PLX bridge and a different methods for slots directly on a PHB. Eventually most of those hooks land into firmware, and as such it's akin to ACPI which also keeps a separate state structure and a pile of hooks. > I also don't realistically think we can get there on a lot of architectures > any time soon. Note that most architectures only have one PCI host > implementation, so the architecture structure is the same as the host > driver structure anyway. > > For architectures like powerpc and arm that have people actively working > on them, we have a chance to clean up that code in the way we want it > (if we can agree on the direction), but it's still not trivial to do. > > Speaking of arm32 in particular, I think we will end up with a split > approach: modern platforms (multiplatform, possibly all DT based) using > PCI core infrastructure directly and no architecture specific PCI > code on the one side, and a variation of today's code for the legacy > platforms on the other. > > 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
