| Message ID | 20220911112024.14304-2-pali@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | PCI: Introduce new PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() macros | expand |
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@kernel.org> > --- > 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. 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. 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
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@kernel.org> > > --- > > 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...
On Tue, Sep 13, 2022 at 11:24:21PM +0200, Pali Rohár wrote: > 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@kernel.org> > > > --- > > > 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. I would love to see that happen, too, and that could be a reason to put pci-conf.h in include/linux. But this series doesn't include that. > > 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. > > 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. drivers/pci/pci.h > But doing all those arm64, x86, ACPI cleanup is a huge cross-tree work > which I'm really not going to do... Of course not, I didn't suggest or expect that. What I'm trying to point out is that I don't think we have very good reasons for pci-ecam.h to be public. And therefore, I don't think we need pci-conf1.h to be next to it. Unless you want to convert the arch/x86 code to use them as well. I'm not asking you to do that either, just that if you *did* do that, it would be an argument for keeping the macros where you put them. Bjorn
diff --git a/include/linux/pci-conf1.h b/include/linux/pci-conf1.h new file mode 100644 index 000000000000..12d2c581a67f --- /dev/null +++ b/include/linux/pci-conf1.h @@ -0,0 +1,51 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright 2022 Pali Rohár <pali@kernel.org> */ +#ifndef PCI_CONF1_H +#define PCI_CONF1_H + +/* + * Config Address for PCI Configuration Mechanism #1 + * + * See PCI Local Bus Specification, Revision 3.0, + * Section 3.2.2.3.2, Figure 3-2, p. 50. + */ + +#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ +#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ +#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ + +#define PCI_CONF1_BUS_MASK 0xff +#define PCI_CONF1_DEV_MASK 0x1f +#define PCI_CONF1_FUNC_MASK 0x7 +#define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ + +#define PCI_CONF1_ENABLE BIT(31) +#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) +#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) +#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) +#define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) + +#define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ + (PCI_CONF1_ENABLE | \ + PCI_CONF1_BUS(bus) | \ + PCI_CONF1_DEV(dev) | \ + PCI_CONF1_FUNC(func) | \ + PCI_CONF1_REG(reg)) + +/* + * Extension of PCI Config Address for accessing extended PCIe registers + * + * No standardized specification, but used on lot of non-ECAM-compliant ARM SoCs + * or on AMD Barcelona and new CPUs. Reserved bits [27:24] of PCI Config Address + * are used for specifying additional 4 high bits of PCI Express register. + */ + +#define PCI_CONF1_EXT_REG_SHIFT 16 +#define PCI_CONF1_EXT_REG_MASK 0xf00 +#define PCI_CONF1_EXT_REG(x) (((x) & PCI_CONF1_EXT_REG_MASK) << PCI_CONF1_EXT_REG_SHIFT) + +#define PCI_CONF1_EXT_ADDRESS(bus, dev, func, reg) \ + (PCI_CONF1_ADDRESS(bus, dev, func, reg) | \ + PCI_CONF1_EXT_REG(reg)) + +#endif
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@kernel.org> --- include/linux/pci-conf1.h | 51 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 include/linux/pci-conf1.h