On Tue, 13 Jul 2010 12:02:02 -0400 Jason Chagas <jason.chagas@xxxxxxxxx> wrote: > > I think you can do this today with the arch-specific hooks provided to > > you, have you looked into that? > > > > The arch specific hooks are generic to the arch. The problem here is > that we have specific way for accessing a PCIe controller. It is > entirely conceivable that we could see other design implementations that > follow the same paradigm in other architectures in the near future. > Adding these extensions to "struct pci_ops" would make them generic > across all architectures. > > Also, "struct pci_ops" seems like a natural home for these HW specific > functions along with the other two read() and write() functions used for > PCI HW specific configuration. I did search for other options but this > was the one that had the _least_ impact. > > Thoughts? Another way of doing it, that would be slightly more general, would be to include these ops in dev_archdata like we do for dma_ops. As Greg pointed out though, the big downside is now we have two ways of doing the same thing. We'd like to avoid a proliferation of basic functions like this if we can. Adding a dev argument to the read/write functions would help other arches as well, but would be huge flag day (thought it's come up several times before). But it doesn't address this specific case very well unless some bus specific hooks were added like you're doing here. Greg, do you have a pointer to the earlier discussions? I can see the value in adding these hooks, I just want to mitigate the downsides... -- Jesse Barnes, Intel Open Source Technology Center -- 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
