On Tuesday 13 September 2022 16:11:43 Bjorn Helgaas wrote: > On Sun, Sep 11, 2022 at 01:20:22PM +0200, Pali Rohár wrote: > > Lot of PCI and PCIe controllers are using standard Config Address for PCI > > Configuration Mechanism #1 (as defined inPCI Local Bus Specification) or > > its extended version. > > > > So introduce new macros PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() in > > new include file linux/pci-conf1.h which can be suitable for PCI and PCIe > > controllers which uses this type of access to PCI config space. > > > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx> > > --- > > include/linux/pci-conf1.h | 51 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 51 insertions(+) > > create mode 100644 include/linux/pci-conf1.h > > This seems like a nice addition, but it would be nice if we could > encapsulate it in drivers/pci. > > I know it's parallel to the existing include/linux/pci-ecam.h. I wish > we could encapsulate *that* in drivers/pci, too. For pci-ecam.h, I > think the only things that prevent that are drivers/acpi/pci_mcfg.c, > loongarch, and a few arm64 things. As these macros describe original Intel x86 API, it can be used also in arch/x86 PCI code. > pci_mcfg.c arguably would make more sense in drivers/pci; it uses > acpi_table_parse(), but no other ACPI services. > > The arm64 code that uses pci-ecam.h is really generic code that would > not be in arch/arm64 except for the fact that x86 has really ugly > legacy x86-specific mmconfig code. IIRC that legacy x86-specific code is used also on modern AMD processors which have broken ECAM. AMD supports that extended version of CF8/CFC with access to PCIe extended config space registers. > I guess that's a long-winded way of saying that I think maybe we could > put this in drivers/pci/pci.h even though the parallel ECAM stuff is > in include/linux/pci-ecam.h. > > Bjorn Well, if you like this change, let me know where to put those new macros, into which file and in which subdirectory, and I can prepare a new patch version. But doing all those arm64, x86, ACPI cleanup is a huge cross-tree work which I'm really not going to do...
