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 <[email protected]>
---
include/linux/pci-conf1.h | 51 +++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 include/linux/pci-conf1.h
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 <[email protected]> */
+#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
--
2.20.1
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 <[email protected]>
> ---
> 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 <[email protected]>
> > ---
> > 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 <[email protected]>
> > > ---
> > > 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