Hi Greg, Thanks for your feedback. Please see my comments below: > Ick. I'm pretty sure this came up a few years ago and was shot down > then. Have you checked the archives? > I just searched the 'linux-pci' archives for "struct pci_ops" on both 'gmane.org' and 'spinics.net' but I couldn't find any proposal to extend "struct pci_ops". Should I also look elsewhere (i.e. linux-kernel archives)? > > + > > + return (ops->hw_readl)?(ops->hw_readl(__hw_mem_pci(hw->regs + reg))): > > + (readl(hw->regs + reg)); > > Doesn't this imply that you should just be changing your arch's readl() > function to handle this type of thing properly? Do you really want to > add this type of logic to _EVERY_ device driver out there (hint, no.) The thing is 'readl()' applies to all devices as 'pci_ops->hw_readl()' is PCIe controller specific. So, I can't simply change 'readl()' without impacting other drivers or even portions of the same driver PCIe device that may need to access other non PCIe HW specific registers. Using the 'pci_ops->hw_readl()' would _only_ be required for device drivers that interact with PCIe controllers that cannot map PCI memory to CPU memory space. That's the PXA168's case where the standard 'readl()' can not access the endpoint. All reads and writes need go through specialized functions that abstract the 4 step process to access to the PIO channels. I see no need update all existing drivers to support HW specific reads and writes. This could happen over time as the need arises. > 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? Jason -- 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