[RFC PATCH V2 0/2] ECAM quirks handling for ARM64 platforms

[RFC PATCH V2 0/2] ECAM quirks handling for ARM64 platforms

[Dongdong Liu]

This series bases on pending ACPI PCI support for ARM64:
https://lkml.org/lkml/2016/6/10/706

Quirk handling relies on an idea of matching MCFG OEM ID and OEM TABLE ID
(the ones from standard header of MCFG table). Linker section is used
so that quirks can be registered using special macro (see patches) and
kept self contained.

v1 -> v2
- use oem_id and oem_table_id to replace oem_id and oem_revision to make 
  a difference between different platforms.
- change pci_cfg_fixup __mcfg_fixup_##system##dom##bus to
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus. With oem_id and oem_table_id
  is to ensure that the object is unique.

Tomasz Nowicki (2):
  ACPI/PCI: Match PCI config space accessors against platfrom specific
    ECAM quirks
  ARM64/PCI: Start using quirks handling for ACPI based PCI host
    controller

 arch/arm64/kernel/pci.c           |  7 ++++---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 4 files changed, 69 insertions(+), 6 deletions(-)

-- 
1.9.1

[RFC PATCH V2 0/2] ECAM quirks handling for ARM64 platforms

[Dongdong Liu]

This series bases on pending ACPI PCI support for ARM64:
https://lkml.org/lkml/2016/6/10/706

Quirk handling relies on an idea of matching MCFG OEM ID and OEM TABLE ID
(the ones from standard header of MCFG table). Linker section is used
so that quirks can be registered using special macro (see patches) and
kept self contained.

v1 -> v2
- use oem_id and oem_table_id to replace oem_id and oem_revision to make 
  a difference between different platforms.
- change pci_cfg_fixup __mcfg_fixup_##system##dom##bus to
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus. With oem_id and oem_table_id
  is to ensure that the object is unique.

Tomasz Nowicki (2):
  ACPI/PCI: Match PCI config space accessors against platfrom specific
    ECAM quirks
  ARM64/PCI: Start using quirks handling for ACPI based PCI host
    controller

 arch/arm64/kernel/pci.c           |  7 ++++---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 4 files changed, 69 insertions(+), 6 deletions(-)

-- 
1.9.1

[RFC PATCH V2 0/2] ECAM quirks handling for ARM64 platforms

[Dongdong Liu]

This series bases on pending ACPI PCI support for ARM64:
https://lkml.org/lkml/2016/6/10/706

Quirk handling relies on an idea of matching MCFG OEM ID and OEM TABLE ID
(the ones from standard header of MCFG table). Linker section is used
so that quirks can be registered using special macro (see patches) and
kept self contained.

v1 -> v2
- use oem_id and oem_table_id to replace oem_id and oem_revision to make 
  a difference between different platforms.
- change pci_cfg_fixup __mcfg_fixup_##system##dom##bus to
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus. With oem_id and oem_table_id
  is to ensure that the object is unique.

Tomasz Nowicki (2):
  ACPI/PCI: Match PCI config space accessors against platfrom specific
    ECAM quirks
  ARM64/PCI: Start using quirks handling for ACPI based PCI host
    controller

 arch/arm64/kernel/pci.c           |  7 ++++---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 4 files changed, 69 insertions(+), 6 deletions(-)

-- 
1.9.1

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set. Algorithm traverses available quirk list, matches against
<oem_id, oem_table_id, domain, bus number> tuple and returns corresponding
PCI config ops. oem_id and oem_table_id come from MCFG table standard header.
All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
kept self contained. Example:

/* Custom PCI config ops */
static struct pci_generic_ecam_ops foo_pci_ops = {
	.bus_shift	= 24,
	.pci_ops = {
		.map_bus = pci_ecam_map_bus,
		.read = foo_ecam_config_read,
		.write = foo_ecam_config_write,
	}
};

DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>, <domain_nr>, <bus_nr>);

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 3 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index d3c3e85..49612b3 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -22,6 +22,10 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/pci-acpi.h>
+#include <linux/pci-ecam.h>
+
+/* Root pointer to the mapped MCFG table */
+static struct acpi_table_mcfg *mcfg_table;
 
 /* Structure to hold entries from the MCFG table */
 struct mcfg_entry {
@@ -35,6 +39,38 @@ struct mcfg_entry {
 /* List to save mcfg entries */
 static LIST_HEAD(pci_mcfg_list);
 
+extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
+
+struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	int bus_num = root->secondary.start;
+	int domain = root->segment;
+	struct pci_cfg_fixup *f;
+
+	if (!mcfg_table)
+		return &pci_generic_ecam_ops;
+
+	/*
+	 * Match against platform specific quirks and return corresponding
+	 * CAM ops.
+	 *
+	 * First match against PCI topology <domain:bus> then use OEM ID and
+	 * OEM revision from MCFG table standard header.
+	 */
+	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
+			      ACPI_OEM_ID_SIZE)) &&
+		    (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
+			      ACPI_OEM_TABLE_ID_SIZE)))
+			return f->ops;
+	}
+	/* No quirks, use ECAM */
+	return &pci_generic_ecam_ops;
+}
+
 phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 {
 	struct mcfg_entry *e;
@@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 
 static __init int pci_mcfg_parse(struct acpi_table_header *header)
 {
-	struct acpi_table_mcfg *mcfg;
 	struct acpi_mcfg_allocation *mptr;
 	struct mcfg_entry *e, *arr;
 	int i, n;
@@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 
 	n = (header->length - sizeof(struct acpi_table_mcfg)) /
 					sizeof(struct acpi_mcfg_allocation);
-	mcfg = (struct acpi_table_mcfg *)header;
-	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
+	mcfg_table = (struct acpi_table_mcfg *)header;
+	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
 
 	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
 	if (!arr)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a67ab9..43604fc 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -300,6 +300,13 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
 	}								\
 									\
+	/* ACPI MCFG quirks */						\
+	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
+		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
+		*(.acpi_fixup_mcfg)					\
+		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
+	}								\
+									\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 7d63a66..088a1da 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
 extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
 
 extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
+extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
 
 static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
 {
@@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
 	int (*prepare_resources)(struct acpi_pci_root_info *info);
 };
 
+struct pci_cfg_fixup {
+	struct pci_ecam_ops *ops;
+	char *oem_id;
+	char *oem_table_id;
+	int domain;
+	int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY	-1
+#define PCI_MCFG_BUS_ANY	-1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)	\
+	static const struct pci_cfg_fixup				\
+	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
+	__used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ ops, oem_id, oem_table_id, dom, bus };
+
 extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
 extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 					    struct acpi_pci_root_ops *ops,
-- 
1.9.1

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set. Algorithm traverses available quirk list, matches against
<oem_id, oem_table_id, domain, bus number> tuple and returns corresponding
PCI config ops. oem_id and oem_table_id come from MCFG table standard header.
All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
kept self contained. Example:

/* Custom PCI config ops */
static struct pci_generic_ecam_ops foo_pci_ops = {
	.bus_shift	= 24,
	.pci_ops = {
		.map_bus = pci_ecam_map_bus,
		.read = foo_ecam_config_read,
		.write = foo_ecam_config_write,
	}
};

DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>, <domain_nr>, <bus_nr>);

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 3 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index d3c3e85..49612b3 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -22,6 +22,10 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/pci-acpi.h>
+#include <linux/pci-ecam.h>
+
+/* Root pointer to the mapped MCFG table */
+static struct acpi_table_mcfg *mcfg_table;
 
 /* Structure to hold entries from the MCFG table */
 struct mcfg_entry {
@@ -35,6 +39,38 @@ struct mcfg_entry {
 /* List to save mcfg entries */
 static LIST_HEAD(pci_mcfg_list);
 
+extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
+
+struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	int bus_num = root->secondary.start;
+	int domain = root->segment;
+	struct pci_cfg_fixup *f;
+
+	if (!mcfg_table)
+		return &pci_generic_ecam_ops;
+
+	/*
+	 * Match against platform specific quirks and return corresponding
+	 * CAM ops.
+	 *
+	 * First match against PCI topology <domain:bus> then use OEM ID and
+	 * OEM revision from MCFG table standard header.
+	 */
+	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
+			      ACPI_OEM_ID_SIZE)) &&
+		    (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
+			      ACPI_OEM_TABLE_ID_SIZE)))
+			return f->ops;
+	}
+	/* No quirks, use ECAM */
+	return &pci_generic_ecam_ops;
+}
+
 phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 {
 	struct mcfg_entry *e;
@@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 
 static __init int pci_mcfg_parse(struct acpi_table_header *header)
 {
-	struct acpi_table_mcfg *mcfg;
 	struct acpi_mcfg_allocation *mptr;
 	struct mcfg_entry *e, *arr;
 	int i, n;
@@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 
 	n = (header->length - sizeof(struct acpi_table_mcfg)) /
 					sizeof(struct acpi_mcfg_allocation);
-	mcfg = (struct acpi_table_mcfg *)header;
-	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
+	mcfg_table = (struct acpi_table_mcfg *)header;
+	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
 
 	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
 	if (!arr)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a67ab9..43604fc 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -300,6 +300,13 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
 	}								\
 									\
+	/* ACPI MCFG quirks */						\
+	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
+		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
+		*(.acpi_fixup_mcfg)					\
+		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
+	}								\
+									\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 7d63a66..088a1da 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
 extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
 
 extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
+extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
 
 static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
 {
@@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
 	int (*prepare_resources)(struct acpi_pci_root_info *info);
 };
 
+struct pci_cfg_fixup {
+	struct pci_ecam_ops *ops;
+	char *oem_id;
+	char *oem_table_id;
+	int domain;
+	int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY	-1
+#define PCI_MCFG_BUS_ANY	-1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)	\
+	static const struct pci_cfg_fixup				\
+	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
+	__used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ ops, oem_id, oem_table_id, dom, bus };
+
 extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
 extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 					    struct acpi_pci_root_ops *ops,
-- 
1.9.1

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set. Algorithm traverses available quirk list, matches against
<oem_id, oem_table_id, domain, bus number> tuple and returns corresponding
PCI config ops. oem_id and oem_table_id come from MCFG table standard header.
All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
kept self contained. Example:

/* Custom PCI config ops */
static struct pci_generic_ecam_ops foo_pci_ops = {
	.bus_shift	= 24,
	.pci_ops = {
		.map_bus = pci_ecam_map_bus,
		.read = foo_ecam_config_read,
		.write = foo_ecam_config_write,
	}
};

DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>, <domain_nr>, <bus_nr>);

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
 drivers/acpi/pci_mcfg.c           | 41 ++++++++++++++++++++++++++++++++++++---
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 20 +++++++++++++++++++
 3 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index d3c3e85..49612b3 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -22,6 +22,10 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/pci-acpi.h>
+#include <linux/pci-ecam.h>
+
+/* Root pointer to the mapped MCFG table */
+static struct acpi_table_mcfg *mcfg_table;
 
 /* Structure to hold entries from the MCFG table */
 struct mcfg_entry {
@@ -35,6 +39,38 @@ struct mcfg_entry {
 /* List to save mcfg entries */
 static LIST_HEAD(pci_mcfg_list);
 
+extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
+
+struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	int bus_num = root->secondary.start;
+	int domain = root->segment;
+	struct pci_cfg_fixup *f;
+
+	if (!mcfg_table)
+		return &pci_generic_ecam_ops;
+
+	/*
+	 * Match against platform specific quirks and return corresponding
+	 * CAM ops.
+	 *
+	 * First match against PCI topology <domain:bus> then use OEM ID and
+	 * OEM revision from MCFG table standard header.
+	 */
+	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
+			      ACPI_OEM_ID_SIZE)) &&
+		    (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
+			      ACPI_OEM_TABLE_ID_SIZE)))
+			return f->ops;
+	}
+	/* No quirks, use ECAM */
+	return &pci_generic_ecam_ops;
+}
+
 phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 {
 	struct mcfg_entry *e;
@@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
 
 static __init int pci_mcfg_parse(struct acpi_table_header *header)
 {
-	struct acpi_table_mcfg *mcfg;
 	struct acpi_mcfg_allocation *mptr;
 	struct mcfg_entry *e, *arr;
 	int i, n;
@@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 
 	n = (header->length - sizeof(struct acpi_table_mcfg)) /
 					sizeof(struct acpi_mcfg_allocation);
-	mcfg = (struct acpi_table_mcfg *)header;
-	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
+	mcfg_table = (struct acpi_table_mcfg *)header;
+	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
 
 	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
 	if (!arr)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a67ab9..43604fc 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -300,6 +300,13 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
 	}								\
 									\
+	/* ACPI MCFG quirks */						\
+	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
+		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
+		*(.acpi_fixup_mcfg)					\
+		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
+	}								\
+									\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 7d63a66..088a1da 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
 extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
 
 extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
+extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
 
 static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
 {
@@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
 	int (*prepare_resources)(struct acpi_pci_root_info *info);
 };
 
+struct pci_cfg_fixup {
+	struct pci_ecam_ops *ops;
+	char *oem_id;
+	char *oem_table_id;
+	int domain;
+	int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY	-1
+#define PCI_MCFG_BUS_ANY	-1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)	\
+	static const struct pci_cfg_fixup				\
+	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
+	__used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ ops, oem_id, oem_table_id, dom, bus };
+
 extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
 extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 					    struct acpi_pci_root_ops *ops,
-- 
1.9.1

[RFC PATCH V2 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

pci_generic_ecam_ops is used by default. Since there are platforms
which have non-compliant ECAM space we need to overwrite these
accessors prior to PCI buses enumeration. In order to do that
we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
we can use proper PCI config space accessors and bus_shift.

pci_generic_ecam_ops is still used for platforms free from quirks.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 arch/arm64/kernel/pci.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 94cd43c..a891bda 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 	struct pci_config_window *cfg;
 	struct resource cfgres;
 	unsigned int bsz;
+	struct pci_ecam_ops *ops;
 
 	/* Use address from _CBA if present, otherwise lookup MCFG */
 	if (!root->mcfg_addr)
@@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 		return NULL;
 	}
 
-	bsz = 1 << pci_generic_ecam_ops.bus_shift;
+	ops = pci_mcfg_get_ops(root);
+	bsz = 1 << ops->bus_shift;
 	cfgres.start = root->mcfg_addr + bus_res->start * bsz;
 	cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
 	cfgres.flags = IORESOURCE_MEM;
-	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res,
-			      &pci_generic_ecam_ops);
+	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res, ops);
 	if (IS_ERR(cfg)) {
 		dev_err(&root->device->dev, "%04x:%pR error %ld mapping ECAM\n",
 			seg, bus_res, PTR_ERR(cfg));
-- 
1.9.1

[RFC PATCH V2 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

pci_generic_ecam_ops is used by default. Since there are platforms
which have non-compliant ECAM space we need to overwrite these
accessors prior to PCI buses enumeration. In order to do that
we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
we can use proper PCI config space accessors and bus_shift.

pci_generic_ecam_ops is still used for platforms free from quirks.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 arch/arm64/kernel/pci.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 94cd43c..a891bda 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 	struct pci_config_window *cfg;
 	struct resource cfgres;
 	unsigned int bsz;
+	struct pci_ecam_ops *ops;
 
 	/* Use address from _CBA if present, otherwise lookup MCFG */
 	if (!root->mcfg_addr)
@@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 		return NULL;
 	}
 
-	bsz = 1 << pci_generic_ecam_ops.bus_shift;
+	ops = pci_mcfg_get_ops(root);
+	bsz = 1 << ops->bus_shift;
 	cfgres.start = root->mcfg_addr + bus_res->start * bsz;
 	cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
 	cfgres.flags = IORESOURCE_MEM;
-	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res,
-			      &pci_generic_ecam_ops);
+	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res, ops);
 	if (IS_ERR(cfg)) {
 		dev_err(&root->device->dev, "%04x:%pR error %ld mapping ECAM\n",
 			seg, bus_res, PTR_ERR(cfg));
-- 
1.9.1

[RFC PATCH V2 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Dongdong Liu]

From: Tomasz Nowicki <tn@semihalf.com>

pci_generic_ecam_ops is used by default. Since there are platforms
which have non-compliant ECAM space we need to overwrite these
accessors prior to PCI buses enumeration. In order to do that
we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
we can use proper PCI config space accessors and bus_shift.

pci_generic_ecam_ops is still used for platforms free from quirks.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 arch/arm64/kernel/pci.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 94cd43c..a891bda 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 	struct pci_config_window *cfg;
 	struct resource cfgres;
 	unsigned int bsz;
+	struct pci_ecam_ops *ops;
 
 	/* Use address from _CBA if present, otherwise lookup MCFG */
 	if (!root->mcfg_addr)
@@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
 		return NULL;
 	}
 
-	bsz = 1 << pci_generic_ecam_ops.bus_shift;
+	ops = pci_mcfg_get_ops(root);
+	bsz = 1 << ops->bus_shift;
 	cfgres.start = root->mcfg_addr + bus_res->start * bsz;
 	cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
 	cfgres.flags = IORESOURCE_MEM;
-	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res,
-			      &pci_generic_ecam_ops);
+	cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res, ops);
 	if (IS_ERR(cfg)) {
 		dev_err(&root->device->dev, "%04x:%pR error %ld mapping ECAM\n",
 			seg, bus_res, PTR_ERR(cfg));
-- 
1.9.1

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Tomasz, Jon

> -----Original Message-----
> From: liudongdong (C)
> Sent: 13 June 2016 14:02
> To: helgaas@kernel.org; arnd@arndb.de; will.deacon@arm.com;
> catalin.marinas@arm.com; rafael@kernel.org; hanjun.guo@linaro.org;
> Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org; jchandra@broadcom.com;
> tn@semihalf.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; liudongdong (C);
> cov@codeaurora.org; Gabriele Paoloni; Chenxin (Charles); Linuxarm
> Subject: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors
> against platfrom specific ECAM quirks
> 
> From: Tomasz Nowicki <tn@semihalf.com>
> 
> Some platforms may not be fully compliant with generic set of PCI
> config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list, matches against
> <oem_id, oem_table_id, domain, bus number> tuple and returns
> corresponding
> PCI config ops. oem_id and oem_table_id come from MCFG table standard
> header.
> All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
> kept self contained. Example:
> 
> /* Custom PCI config ops */
> static struct pci_generic_ecam_ops foo_pci_ops = {
> 	.bus_shift	= 24,
> 	.pci_ops = {
> 		.map_bus = pci_ecam_map_bus,
> 		.read = foo_ecam_config_read,
> 		.write = foo_ecam_config_write,
> 	}
> };
> 
> DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>,
> <domain_nr>, <bus_nr>);
> 
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
>  drivers/acpi/pci_mcfg.c           | 41
> ++++++++++++++++++++++++++++++++++++---
>  include/asm-generic/vmlinux.lds.h |  7 +++++++
>  include/linux/pci-acpi.h          | 20 +++++++++++++++++++
>  3 files changed, 65 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include <linux/kernel.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> +#include <linux/pci-ecam.h>
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
> 
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
> 
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	int bus_num = root->secondary.start;
> +	int domain = root->segment;
> +	struct pci_cfg_fixup *f;
> +
> +	if (!mcfg_table)
> +		return &pci_generic_ecam_ops;
> +
> +	/*
> +	 * Match against platform specific quirks and return
> corresponding
> +	 * CAM ops.
> +	 *
> +	 * First match against PCI topology <domain:bus> then use OEM ID
> and
> +	 * OEM revision from MCFG table standard header.
> +	 */
> +	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
> f++) {
> +		if ((f->domain == domain || f->domain ==
> PCI_MCFG_DOMAIN_ANY) &&
> +		    (f->bus_num == bus_num || f->bus_num ==
> PCI_MCFG_BUS_ANY) &&
> +		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +			      ACPI_OEM_ID_SIZE)) &&
> +		    (!strncmp(f->oem_table_id, mcfg_table-
> >header.oem_table_id,
> +			      ACPI_OEM_TABLE_ID_SIZE)))

As you can see here Liudongdong has replaced oem_revision with
oem_table_id.

Now it seems that there are some platforms that have already shipped
using a matching based on the oem_revision (right Jon?)

However I guess that if in FW they have defined oem_table_id properly
they should be able to use this mechanism without needing to a FW update.

Can these vendors confirm this?

Tomasz do you think this can work for Cavium Thunder?

Thanks

Gab


> +			return f->ops;
> +	}
> +	/* No quirks, use ECAM */
> +	return &pci_generic_ecam_ops;
> +}
> +
>  phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
>  {
>  	struct mcfg_entry *e;
> @@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource
> *bus_res)
> 
>  static __init int pci_mcfg_parse(struct acpi_table_header *header)
>  {
> -	struct acpi_table_mcfg *mcfg;
>  	struct acpi_mcfg_allocation *mptr;
>  	struct mcfg_entry *e, *arr;
>  	int i, n;
> @@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct
> acpi_table_header *header)
> 
>  	n = (header->length - sizeof(struct acpi_table_mcfg)) /
>  					sizeof(struct acpi_mcfg_allocation);
> -	mcfg = (struct acpi_table_mcfg *)header;
> -	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
> +	mcfg_table = (struct acpi_table_mcfg *)header;
> +	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
> 
>  	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
>  	if (!arr)
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-
> generic/vmlinux.lds.h
> index 6a67ab9..43604fc 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -300,6 +300,13 @@
>  		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
>  	}								\
>  									\
> +	/* ACPI MCFG quirks */						\
> +	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
> +		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
> +		*(.acpi_fixup_mcfg)					\
> +		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
> +	}								\
> +									\
>  	/* Built-in firmware blobs */					\
>  	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
>  		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status
> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
> 
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
> *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
> *root);
> 
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
> *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>  	int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
> 
> +struct pci_cfg_fixup {
> +	struct pci_ecam_ops *ops;
> +	char *oem_id;
> +	char *oem_table_id;
> +	int domain;
> +	int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY	-1
> +#define PCI_MCFG_BUS_ANY	-1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)
> 	\
> +	static const struct pci_cfg_fixup				\
> +	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
> +	__used	__attribute__((__section__(".acpi_fixup_mcfg"),
> 	\
> +				aligned((sizeof(void *))))) =		\
> +	{ ops, oem_id, oem_table_id, dom, bus };
> +
>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
> *info);
>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  					    struct acpi_pci_root_ops *ops,
> --
> 1.9.1

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Tomasz, Jon

> -----Original Message-----
> From: liudongdong (C)
> Sent: 13 June 2016 14:02
> To: helgaas@kernel.org; arnd@arndb.de; will.deacon@arm.com;
> catalin.marinas@arm.com; rafael@kernel.org; hanjun.guo@linaro.org;
> Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org; jchandra@broadcom.com;
> tn@semihalf.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; liudongdong (C);
> cov@codeaurora.org; Gabriele Paoloni; Chenxin (Charles); Linuxarm
> Subject: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors
> against platfrom specific ECAM quirks
> 
> From: Tomasz Nowicki <tn@semihalf.com>
> 
> Some platforms may not be fully compliant with generic set of PCI
> config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list, matches against
> <oem_id, oem_table_id, domain, bus number> tuple and returns
> corresponding
> PCI config ops. oem_id and oem_table_id come from MCFG table standard
> header.
> All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
> kept self contained. Example:
> 
> /* Custom PCI config ops */
> static struct pci_generic_ecam_ops foo_pci_ops = {
> 	.bus_shift	= 24,
> 	.pci_ops = {
> 		.map_bus = pci_ecam_map_bus,
> 		.read = foo_ecam_config_read,
> 		.write = foo_ecam_config_write,
> 	}
> };
> 
> DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>,
> <domain_nr>, <bus_nr>);
> 
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
>  drivers/acpi/pci_mcfg.c           | 41
> ++++++++++++++++++++++++++++++++++++---
>  include/asm-generic/vmlinux.lds.h |  7 +++++++
>  include/linux/pci-acpi.h          | 20 +++++++++++++++++++
>  3 files changed, 65 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include <linux/kernel.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> +#include <linux/pci-ecam.h>
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
> 
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
> 
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	int bus_num = root->secondary.start;
> +	int domain = root->segment;
> +	struct pci_cfg_fixup *f;
> +
> +	if (!mcfg_table)
> +		return &pci_generic_ecam_ops;
> +
> +	/*
> +	 * Match against platform specific quirks and return
> corresponding
> +	 * CAM ops.
> +	 *
> +	 * First match against PCI topology <domain:bus> then use OEM ID
> and
> +	 * OEM revision from MCFG table standard header.
> +	 */
> +	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
> f++) {
> +		if ((f->domain == domain || f->domain ==
> PCI_MCFG_DOMAIN_ANY) &&
> +		    (f->bus_num == bus_num || f->bus_num ==
> PCI_MCFG_BUS_ANY) &&
> +		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +			      ACPI_OEM_ID_SIZE)) &&
> +		    (!strncmp(f->oem_table_id, mcfg_table-
> >header.oem_table_id,
> +			      ACPI_OEM_TABLE_ID_SIZE)))

As you can see here Liudongdong has replaced oem_revision with
oem_table_id.

Now it seems that there are some platforms that have already shipped
using a matching based on the oem_revision (right Jon?)

However I guess that if in FW they have defined oem_table_id properly
they should be able to use this mechanism without needing to a FW update.

Can these vendors confirm this?

Tomasz do you think this can work for Cavium Thunder?

Thanks

Gab


> +			return f->ops;
> +	}
> +	/* No quirks, use ECAM */
> +	return &pci_generic_ecam_ops;
> +}
> +
>  phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
>  {
>  	struct mcfg_entry *e;
> @@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource
> *bus_res)
> 
>  static __init int pci_mcfg_parse(struct acpi_table_header *header)
>  {
> -	struct acpi_table_mcfg *mcfg;
>  	struct acpi_mcfg_allocation *mptr;
>  	struct mcfg_entry *e, *arr;
>  	int i, n;
> @@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct
> acpi_table_header *header)
> 
>  	n = (header->length - sizeof(struct acpi_table_mcfg)) /
>  					sizeof(struct acpi_mcfg_allocation);
> -	mcfg = (struct acpi_table_mcfg *)header;
> -	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
> +	mcfg_table = (struct acpi_table_mcfg *)header;
> +	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
> 
>  	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
>  	if (!arr)
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-
> generic/vmlinux.lds.h
> index 6a67ab9..43604fc 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -300,6 +300,13 @@
>  		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
>  	}								\
>  									\
> +	/* ACPI MCFG quirks */						\
> +	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
> +		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
> +		*(.acpi_fixup_mcfg)					\
> +		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
> +	}								\
> +									\
>  	/* Built-in firmware blobs */					\
>  	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
>  		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status
> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
> 
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
> *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
> *root);
> 
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
> *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>  	int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
> 
> +struct pci_cfg_fixup {
> +	struct pci_ecam_ops *ops;
> +	char *oem_id;
> +	char *oem_table_id;
> +	int domain;
> +	int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY	-1
> +#define PCI_MCFG_BUS_ANY	-1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)
> 	\
> +	static const struct pci_cfg_fixup				\
> +	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
> +	__used	__attribute__((__section__(".acpi_fixup_mcfg"),
> 	\
> +				aligned((sizeof(void *))))) =		\
> +	{ ops, oem_id, oem_table_id, dom, bus };
> +
>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
> *info);
>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  					    struct acpi_pci_root_ops *ops,
> --
> 1.9.1

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

SGkgVG9tYXN6LCBKb24NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBs
aXVkb25nZG9uZyAoQykNCj4gU2VudDogMTMgSnVuZSAyMDE2IDE0OjAyDQo+IFRvOiBoZWxnYWFz
QGtlcm5lbC5vcmc7IGFybmRAYXJuZGIuZGU7IHdpbGwuZGVhY29uQGFybS5jb207DQo+IGNhdGFs
aW4ubWFyaW5hc0Bhcm0uY29tOyByYWZhZWxAa2VybmVsLm9yZzsgaGFuanVuLmd1b0BsaW5hcm8u
b3JnOw0KPiBMb3JlbnpvLlBpZXJhbGlzaUBhcm0uY29tOyBva2F5YUBjb2RlYXVyb3JhLm9yZzsg
amNoYW5kcmFAYnJvYWRjb20uY29tOw0KPiB0bkBzZW1paGFsZi5jb20NCj4gQ2M6IHJvYmVydC5y
aWNodGVyQGNhdml1bW5ldHdvcmtzLmNvbTsgbXdAc2VtaWhhbGYuY29tOw0KPiBMaXZpdS5EdWRh
dUBhcm0uY29tOyBkZGFuZXlAY2F2aXVtbmV0d29ya3MuY29tOyBXYW5neWlqaW5nOw0KPiBTdXJh
dmVlLlN1dGhpa3VscGFuaXRAYW1kLmNvbTsgbXNhbHRlckByZWRoYXQuY29tOyBsaW51eC0NCj4g
cGNpQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3Jn
OyBsaW51eC0NCj4gYWNwaUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5l
bC5vcmc7IGxpbmFyby0NCj4gYWNwaUBsaXN0cy5saW5hcm8ub3JnOyBqY21AcmVkaGF0LmNvbTsg
YW5kcmVhLmdhbGxvQGxpbmFyby5vcmc7DQo+IGRoZGFuZ0BhcG0uY29tOyBqZXJlbXkubGludG9u
QGFybS5jb207IGxpdWRvbmdkb25nIChDKTsNCj4gY292QGNvZGVhdXJvcmEub3JnOyBHYWJyaWVs
ZSBQYW9sb25pOyBDaGVueGluIChDaGFybGVzKTsgTGludXhhcm0NCj4gU3ViamVjdDogW1JGQyBQ
QVRDSCBWMiAxLzJdIEFDUEkvUENJOiBNYXRjaCBQQ0kgY29uZmlnIHNwYWNlIGFjY2Vzc29ycw0K
PiBhZ2FpbnN0IHBsYXRmcm9tIHNwZWNpZmljIEVDQU0gcXVpcmtzDQo+IA0KPiBGcm9tOiBUb21h
c3ogTm93aWNraSA8dG5Ac2VtaWhhbGYuY29tPg0KPiANCj4gU29tZSBwbGF0Zm9ybXMgbWF5IG5v
dCBiZSBmdWxseSBjb21wbGlhbnQgd2l0aCBnZW5lcmljIHNldCBvZiBQQ0kNCj4gY29uZmlnDQo+
IGFjY2Vzc29ycy4gRm9yIHRoZXNlIGNhc2VzIHdlIGltcGxlbWVudCB0aGUgd2F5IHRvIG92ZXJ3
cml0ZSBhY2Nlc3NvcnMNCj4gc2V0LiBBbGdvcml0aG0gdHJhdmVyc2VzIGF2YWlsYWJsZSBxdWly
ayBsaXN0LCBtYXRjaGVzIGFnYWluc3QNCj4gPG9lbV9pZCwgb2VtX3RhYmxlX2lkLCBkb21haW4s
IGJ1cyBudW1iZXI+IHR1cGxlIGFuZCByZXR1cm5zDQo+IGNvcnJlc3BvbmRpbmcNCj4gUENJIGNv
bmZpZyBvcHMuIG9lbV9pZCBhbmQgb2VtX3RhYmxlX2lkIGNvbWUgZnJvbSBNQ0ZHIHRhYmxlIHN0
YW5kYXJkDQo+IGhlYWRlci4NCj4gQWxsIHF1aXJrcyBjYW4gYmUgZGVmaW5lZCB1c2luZyBERUNM
QVJFX0FDUElfTUNGR19GSVhVUCgpIG1hY3JvIGFuZA0KPiBrZXB0IHNlbGYgY29udGFpbmVkLiBF
eGFtcGxlOg0KPiANCj4gLyogQ3VzdG9tIFBDSSBjb25maWcgb3BzICovDQo+IHN0YXRpYyBzdHJ1
Y3QgcGNpX2dlbmVyaWNfZWNhbV9vcHMgZm9vX3BjaV9vcHMgPSB7DQo+IAkuYnVzX3NoaWZ0CT0g
MjQsDQo+IAkucGNpX29wcyA9IHsNCj4gCQkubWFwX2J1cyA9IHBjaV9lY2FtX21hcF9idXMsDQo+
IAkJLnJlYWQgPSBmb29fZWNhbV9jb25maWdfcmVhZCwNCj4gCQkud3JpdGUgPSBmb29fZWNhbV9j
b25maWdfd3JpdGUsDQo+IAl9DQo+IH07DQo+IA0KPiBERUNMQVJFX0FDUElfTUNGR19GSVhVUCgm
Zm9vX3BjaV9vcHMsIDxvZW1faWRfc3RyPiwgPG9lbV90YWJsZV9pZD4sDQo+IDxkb21haW5fbnI+
LCA8YnVzX25yPik7DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBUb21hc3ogTm93aWNraSA8dG5Ac2Vt
aWhhbGYuY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBEb25nZG9uZyBMaXUgPGxpdWRvbmdkb25nM0Bo
dWF3ZWkuY29tPg0KPiAtLS0NCj4gIGRyaXZlcnMvYWNwaS9wY2lfbWNmZy5jICAgICAgICAgICB8
IDQxDQo+ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLQ0KPiAgaW5jbHVk
ZS9hc20tZ2VuZXJpYy92bWxpbnV4Lmxkcy5oIHwgIDcgKysrKysrKw0KPiAgaW5jbHVkZS9saW51
eC9wY2ktYWNwaS5oICAgICAgICAgIHwgMjAgKysrKysrKysrKysrKysrKysrKw0KPiAgMyBmaWxl
cyBjaGFuZ2VkLCA2NSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAt
LWdpdCBhL2RyaXZlcnMvYWNwaS9wY2lfbWNmZy5jIGIvZHJpdmVycy9hY3BpL3BjaV9tY2ZnLmMN
Cj4gaW5kZXggZDNjM2U4NS4uNDk2MTJiMyAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy9hY3BpL3Bj
aV9tY2ZnLmMNCj4gKysrIGIvZHJpdmVycy9hY3BpL3BjaV9tY2ZnLmMNCj4gQEAgLTIyLDYgKzIy
LDEwIEBADQo+ICAjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQo+ICAjaW5jbHVkZSA8bGludXgv
cGNpLmg+DQo+ICAjaW5jbHVkZSA8bGludXgvcGNpLWFjcGkuaD4NCj4gKyNpbmNsdWRlIDxsaW51
eC9wY2ktZWNhbS5oPg0KPiArDQo+ICsvKiBSb290IHBvaW50ZXIgdG8gdGhlIG1hcHBlZCBNQ0ZH
IHRhYmxlICovDQo+ICtzdGF0aWMgc3RydWN0IGFjcGlfdGFibGVfbWNmZyAqbWNmZ190YWJsZTsN
Cj4gDQo+ICAvKiBTdHJ1Y3R1cmUgdG8gaG9sZCBlbnRyaWVzIGZyb20gdGhlIE1DRkcgdGFibGUg
Ki8NCj4gIHN0cnVjdCBtY2ZnX2VudHJ5IHsNCj4gQEAgLTM1LDYgKzM5LDM4IEBAIHN0cnVjdCBt
Y2ZnX2VudHJ5IHsNCj4gIC8qIExpc3QgdG8gc2F2ZSBtY2ZnIGVudHJpZXMgKi8NCj4gIHN0YXRp
YyBMSVNUX0hFQUQocGNpX21jZmdfbGlzdCk7DQo+IA0KPiArZXh0ZXJuIHN0cnVjdCBwY2lfY2Zn
X2ZpeHVwIF9fc3RhcnRfYWNwaV9tY2ZnX2ZpeHVwc1tdOw0KPiArZXh0ZXJuIHN0cnVjdCBwY2lf
Y2ZnX2ZpeHVwIF9fZW5kX2FjcGlfbWNmZ19maXh1cHNbXTsNCj4gKw0KPiArc3RydWN0IHBjaV9l
Y2FtX29wcyAqcGNpX21jZmdfZ2V0X29wcyhzdHJ1Y3QgYWNwaV9wY2lfcm9vdCAqcm9vdCkNCj4g
K3sNCj4gKwlpbnQgYnVzX251bSA9IHJvb3QtPnNlY29uZGFyeS5zdGFydDsNCj4gKwlpbnQgZG9t
YWluID0gcm9vdC0+c2VnbWVudDsNCj4gKwlzdHJ1Y3QgcGNpX2NmZ19maXh1cCAqZjsNCj4gKw0K
PiArCWlmICghbWNmZ190YWJsZSkNCj4gKwkJcmV0dXJuICZwY2lfZ2VuZXJpY19lY2FtX29wczsN
Cj4gKw0KPiArCS8qDQo+ICsJICogTWF0Y2ggYWdhaW5zdCBwbGF0Zm9ybSBzcGVjaWZpYyBxdWly
a3MgYW5kIHJldHVybg0KPiBjb3JyZXNwb25kaW5nDQo+ICsJICogQ0FNIG9wcy4NCj4gKwkgKg0K
PiArCSAqIEZpcnN0IG1hdGNoIGFnYWluc3QgUENJIHRvcG9sb2d5IDxkb21haW46YnVzPiB0aGVu
IHVzZSBPRU0gSUQNCj4gYW5kDQo+ICsJICogT0VNIHJldmlzaW9uIGZyb20gTUNGRyB0YWJsZSBz
dGFuZGFyZCBoZWFkZXIuDQo+ICsJICovDQo+ICsJZm9yIChmID0gX19zdGFydF9hY3BpX21jZmdf
Zml4dXBzOyBmIDwgX19lbmRfYWNwaV9tY2ZnX2ZpeHVwczsNCj4gZisrKSB7DQo+ICsJCWlmICgo
Zi0+ZG9tYWluID09IGRvbWFpbiB8fCBmLT5kb21haW4gPT0NCj4gUENJX01DRkdfRE9NQUlOX0FO
WSkgJiYNCj4gKwkJICAgIChmLT5idXNfbnVtID09IGJ1c19udW0gfHwgZi0+YnVzX251bSA9PQ0K
PiBQQ0lfTUNGR19CVVNfQU5ZKSAmJg0KPiArCQkgICAgKCFzdHJuY21wKGYtPm9lbV9pZCwgbWNm
Z190YWJsZS0+aGVhZGVyLm9lbV9pZCwNCj4gKwkJCSAgICAgIEFDUElfT0VNX0lEX1NJWkUpKSAm
Jg0KPiArCQkgICAgKCFzdHJuY21wKGYtPm9lbV90YWJsZV9pZCwgbWNmZ190YWJsZS0NCj4gPmhl
YWRlci5vZW1fdGFibGVfaWQsDQo+ICsJCQkgICAgICBBQ1BJX09FTV9UQUJMRV9JRF9TSVpFKSkp
DQoNCkFzIHlvdSBjYW4gc2VlIGhlcmUgTGl1ZG9uZ2RvbmcgaGFzIHJlcGxhY2VkIG9lbV9yZXZp
c2lvbiB3aXRoDQpvZW1fdGFibGVfaWQuDQoNCk5vdyBpdCBzZWVtcyB0aGF0IHRoZXJlIGFyZSBz
b21lIHBsYXRmb3JtcyB0aGF0IGhhdmUgYWxyZWFkeSBzaGlwcGVkDQp1c2luZyBhIG1hdGNoaW5n
IGJhc2VkIG9uIHRoZSBvZW1fcmV2aXNpb24gKHJpZ2h0IEpvbj8pDQoNCkhvd2V2ZXIgSSBndWVz
cyB0aGF0IGlmIGluIEZXIHRoZXkgaGF2ZSBkZWZpbmVkIG9lbV90YWJsZV9pZCBwcm9wZXJseQ0K
dGhleSBzaG91bGQgYmUgYWJsZSB0byB1c2UgdGhpcyBtZWNoYW5pc20gd2l0aG91dCBuZWVkaW5n
IHRvIGEgRlcgdXBkYXRlLg0KDQpDYW4gdGhlc2UgdmVuZG9ycyBjb25maXJtIHRoaXM/DQoNClRv
bWFzeiBkbyB5b3UgdGhpbmsgdGhpcyBjYW4gd29yayBmb3IgQ2F2aXVtIFRodW5kZXI/DQoNClRo
YW5rcw0KDQpHYWINCg0KDQo+ICsJCQlyZXR1cm4gZi0+b3BzOw0KPiArCX0NCj4gKwkvKiBObyBx
dWlya3MsIHVzZSBFQ0FNICovDQo+ICsJcmV0dXJuICZwY2lfZ2VuZXJpY19lY2FtX29wczsNCj4g
K30NCj4gKw0KPiAgcGh5c19hZGRyX3QgcGNpX21jZmdfbG9va3VwKHUxNiBzZWcsIHN0cnVjdCBy
ZXNvdXJjZSAqYnVzX3JlcykNCj4gIHsNCj4gIAlzdHJ1Y3QgbWNmZ19lbnRyeSAqZTsNCj4gQEAg
LTU0LDcgKzkwLDYgQEAgcGh5c19hZGRyX3QgcGNpX21jZmdfbG9va3VwKHUxNiBzZWcsIHN0cnVj
dCByZXNvdXJjZQ0KPiAqYnVzX3JlcykNCj4gDQo+ICBzdGF0aWMgX19pbml0IGludCBwY2lfbWNm
Z19wYXJzZShzdHJ1Y3QgYWNwaV90YWJsZV9oZWFkZXIgKmhlYWRlcikNCj4gIHsNCj4gLQlzdHJ1
Y3QgYWNwaV90YWJsZV9tY2ZnICptY2ZnOw0KPiAgCXN0cnVjdCBhY3BpX21jZmdfYWxsb2NhdGlv
biAqbXB0cjsNCj4gIAlzdHJ1Y3QgbWNmZ19lbnRyeSAqZSwgKmFycjsNCj4gIAlpbnQgaSwgbjsN
Cj4gQEAgLTY0LDggKzk5LDggQEAgc3RhdGljIF9faW5pdCBpbnQgcGNpX21jZmdfcGFyc2Uoc3Ry
dWN0DQo+IGFjcGlfdGFibGVfaGVhZGVyICpoZWFkZXIpDQo+IA0KPiAgCW4gPSAoaGVhZGVyLT5s
ZW5ndGggLSBzaXplb2Yoc3RydWN0IGFjcGlfdGFibGVfbWNmZykpIC8NCj4gIAkJCQkJc2l6ZW9m
KHN0cnVjdCBhY3BpX21jZmdfYWxsb2NhdGlvbik7DQo+IC0JbWNmZyA9IChzdHJ1Y3QgYWNwaV90
YWJsZV9tY2ZnICopaGVhZGVyOw0KPiAtCW1wdHIgPSAoc3RydWN0IGFjcGlfbWNmZ19hbGxvY2F0
aW9uICopICZtY2ZnWzFdOw0KPiArCW1jZmdfdGFibGUgPSAoc3RydWN0IGFjcGlfdGFibGVfbWNm
ZyAqKWhlYWRlcjsNCj4gKwltcHRyID0gKHN0cnVjdCBhY3BpX21jZmdfYWxsb2NhdGlvbiAqKSAm
bWNmZ190YWJsZVsxXTsNCj4gDQo+ICAJYXJyID0ga2NhbGxvYyhuLCBzaXplb2YoKmFyciksIEdG
UF9LRVJORUwpOw0KPiAgCWlmICghYXJyKQ0KPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9hc20tZ2Vu
ZXJpYy92bWxpbnV4Lmxkcy5oIGIvaW5jbHVkZS9hc20tDQo+IGdlbmVyaWMvdm1saW51eC5sZHMu
aA0KPiBpbmRleCA2YTY3YWI5Li40MzYwNGZjIDEwMDY0NA0KPiAtLS0gYS9pbmNsdWRlL2FzbS1n
ZW5lcmljL3ZtbGludXgubGRzLmgNCj4gKysrIGIvaW5jbHVkZS9hc20tZ2VuZXJpYy92bWxpbnV4
Lmxkcy5oDQo+IEBAIC0zMDAsNiArMzAwLDEzIEBADQo+ICAJCVZNTElOVVhfU1lNQk9MKF9fZW5k
X3BjaV9maXh1cHNfc3VzcGVuZF9sYXRlKSA9IC47CVwNCj4gIAl9CQkJCQkJCQlcDQo+ICAJCQkJ
CQkJCQlcDQo+ICsJLyogQUNQSSBNQ0ZHIHF1aXJrcyAqLwkJCQkJCVwNCj4gKwkuYWNwaV9maXh1
cCAgICAgICAgOiBBVChBRERSKC5hY3BpX2ZpeHVwKSAtIExPQURfT0ZGU0VUKSB7CVwNCj4gKwkJ
Vk1MSU5VWF9TWU1CT0woX19zdGFydF9hY3BpX21jZmdfZml4dXBzKSA9IC47CQlcDQo+ICsJCSoo
LmFjcGlfZml4dXBfbWNmZykJCQkJCVwNCj4gKwkJVk1MSU5VWF9TWU1CT0woX19lbmRfYWNwaV9t
Y2ZnX2ZpeHVwcykgPSAuOwkJXA0KPiArCX0JCQkJCQkJCVwNCj4gKwkJCQkJCQkJCVwNCj4gIAkv
KiBCdWlsdC1pbiBmaXJtd2FyZSBibG9icyAqLwkJCQkJXA0KPiAgCS5idWlsdGluX2Z3ICAgICAg
ICA6IEFUKEFERFIoLmJ1aWx0aW5fZncpIC0gTE9BRF9PRkZTRVQpIHsJXA0KPiAgCQlWTUxJTlVY
X1NZTUJPTChfX3N0YXJ0X2J1aWx0aW5fZncpID0gLjsJCQlcDQo+IGRpZmYgLS1naXQgYS9pbmNs
dWRlL2xpbnV4L3BjaS1hY3BpLmggYi9pbmNsdWRlL2xpbnV4L3BjaS1hY3BpLmgNCj4gaW5kZXgg
N2Q2M2E2Ni4uMDg4YTFkYSAxMDA2NDQNCj4gLS0tIGEvaW5jbHVkZS9saW51eC9wY2ktYWNwaS5o
DQo+ICsrKyBiL2luY2x1ZGUvbGludXgvcGNpLWFjcGkuaA0KPiBAQCAtMjUsNiArMjUsNyBAQCBz
dGF0aWMgaW5saW5lIGFjcGlfc3RhdHVzDQo+IHBjaV9hY3BpX3JlbW92ZV9wbV9ub3RpZmllcihz
dHJ1Y3QgYWNwaV9kZXZpY2UgKmRldikNCj4gIGV4dGVybiBwaHlzX2FkZHJfdCBhY3BpX3BjaV9y
b290X2dldF9tY2ZnX2FkZHIoYWNwaV9oYW5kbGUgaGFuZGxlKTsNCj4gDQo+ICBleHRlcm4gcGh5
c19hZGRyX3QgcGNpX21jZmdfbG9va3VwKHUxNiBkb21haW4sIHN0cnVjdCByZXNvdXJjZQ0KPiAq
YnVzX3Jlcyk7DQo+ICtleHRlcm4gc3RydWN0IHBjaV9lY2FtX29wcyAqcGNpX21jZmdfZ2V0X29w
cyhzdHJ1Y3QgYWNwaV9wY2lfcm9vdA0KPiAqcm9vdCk7DQo+IA0KPiAgc3RhdGljIGlubGluZSBh
Y3BpX2hhbmRsZSBhY3BpX2ZpbmRfcm9vdF9icmlkZ2VfaGFuZGxlKHN0cnVjdCBwY2lfZGV2DQo+
ICpwZGV2KQ0KPiAgew0KPiBAQCAtNzIsNiArNzMsMjUgQEAgc3RydWN0IGFjcGlfcGNpX3Jvb3Rf
b3BzIHsNCj4gIAlpbnQgKCpwcmVwYXJlX3Jlc291cmNlcykoc3RydWN0IGFjcGlfcGNpX3Jvb3Rf
aW5mbyAqaW5mbyk7DQo+ICB9Ow0KPiANCj4gK3N0cnVjdCBwY2lfY2ZnX2ZpeHVwIHsNCj4gKwlz
dHJ1Y3QgcGNpX2VjYW1fb3BzICpvcHM7DQo+ICsJY2hhciAqb2VtX2lkOw0KPiArCWNoYXIgKm9l
bV90YWJsZV9pZDsNCj4gKwlpbnQgZG9tYWluOw0KPiArCWludCBidXNfbnVtOw0KPiArfTsNCj4g
Kw0KPiArI2RlZmluZSBQQ0lfTUNGR19ET01BSU5fQU5ZCS0xDQo+ICsjZGVmaW5lIFBDSV9NQ0ZH
X0JVU19BTlkJLTENCj4gKw0KPiArLyogRGVzaWduYXRlIGEgcm91dGluZSB0byBmaXggdXAgYnVn
Z3kgTUNGRyAqLw0KPiArI2RlZmluZSBERUNMQVJFX0FDUElfTUNGR19GSVhVUChvcHMsIG9lbV9p
ZCwgb2VtX3RhYmxlX2lkLCBkb20sIGJ1cykNCj4gCVwNCj4gKwlzdGF0aWMgY29uc3Qgc3RydWN0
IHBjaV9jZmdfZml4dXAJCQkJXA0KPiArCV9fbWNmZ19maXh1cF8jI29lbV9pZCMjb2VtX3RhYmxl
X2lkIyNkb20jI2J1cwkJCVwNCj4gKwlfX3VzZWQJX19hdHRyaWJ1dGVfXygoX19zZWN0aW9uX18o
Ii5hY3BpX2ZpeHVwX21jZmciKSwNCj4gCVwNCj4gKwkJCQlhbGlnbmVkKChzaXplb2Yodm9pZCAq
KSkpKSkgPQkJXA0KPiArCXsgb3BzLCBvZW1faWQsIG9lbV90YWJsZV9pZCwgZG9tLCBidXMgfTsN
Cj4gKw0KPiAgZXh0ZXJuIGludCBhY3BpX3BjaV9wcm9iZV9yb290X3Jlc291cmNlcyhzdHJ1Y3Qg
YWNwaV9wY2lfcm9vdF9pbmZvDQo+ICppbmZvKTsNCj4gIGV4dGVybiBzdHJ1Y3QgcGNpX2J1cyAq
YWNwaV9wY2lfcm9vdF9jcmVhdGUoc3RydWN0IGFjcGlfcGNpX3Jvb3QgKnJvb3QsDQo+ICAJCQkJ
CSAgICBzdHJ1Y3QgYWNwaV9wY2lfcm9vdF9vcHMgKm9wcywNCj4gLS0NCj4gMS45LjENCg0K

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Tomasz, Jon

> -----Original Message-----
> From: liudongdong (C)
> Sent: 13 June 2016 14:02
> To: helgaas at kernel.org; arnd at arndb.de; will.deacon at arm.com;
> catalin.marinas at arm.com; rafael at kernel.org; hanjun.guo at linaro.org;
> Lorenzo.Pieralisi at arm.com; okaya at codeaurora.org; jchandra at broadcom.com;
> tn at semihalf.com
> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org;
> dhdang at apm.com; jeremy.linton at arm.com; liudongdong (C);
> cov at codeaurora.org; Gabriele Paoloni; Chenxin (Charles); Linuxarm
> Subject: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors
> against platfrom specific ECAM quirks
> 
> From: Tomasz Nowicki <tn@semihalf.com>
> 
> Some platforms may not be fully compliant with generic set of PCI
> config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list, matches against
> <oem_id, oem_table_id, domain, bus number> tuple and returns
> corresponding
> PCI config ops. oem_id and oem_table_id come from MCFG table standard
> header.
> All quirks can be defined using DECLARE_ACPI_MCFG_FIXUP() macro and
> kept self contained. Example:
> 
> /* Custom PCI config ops */
> static struct pci_generic_ecam_ops foo_pci_ops = {
> 	.bus_shift	= 24,
> 	.pci_ops = {
> 		.map_bus = pci_ecam_map_bus,
> 		.read = foo_ecam_config_read,
> 		.write = foo_ecam_config_write,
> 	}
> };
> 
> DECLARE_ACPI_MCFG_FIXUP(&foo_pci_ops, <oem_id_str>, <oem_table_id>,
> <domain_nr>, <bus_nr>);
> 
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
>  drivers/acpi/pci_mcfg.c           | 41
> ++++++++++++++++++++++++++++++++++++---
>  include/asm-generic/vmlinux.lds.h |  7 +++++++
>  include/linux/pci-acpi.h          | 20 +++++++++++++++++++
>  3 files changed, 65 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include <linux/kernel.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> +#include <linux/pci-ecam.h>
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
> 
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
> 
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	int bus_num = root->secondary.start;
> +	int domain = root->segment;
> +	struct pci_cfg_fixup *f;
> +
> +	if (!mcfg_table)
> +		return &pci_generic_ecam_ops;
> +
> +	/*
> +	 * Match against platform specific quirks and return
> corresponding
> +	 * CAM ops.
> +	 *
> +	 * First match against PCI topology <domain:bus> then use OEM ID
> and
> +	 * OEM revision from MCFG table standard header.
> +	 */
> +	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
> f++) {
> +		if ((f->domain == domain || f->domain ==
> PCI_MCFG_DOMAIN_ANY) &&
> +		    (f->bus_num == bus_num || f->bus_num ==
> PCI_MCFG_BUS_ANY) &&
> +		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +			      ACPI_OEM_ID_SIZE)) &&
> +		    (!strncmp(f->oem_table_id, mcfg_table-
> >header.oem_table_id,
> +			      ACPI_OEM_TABLE_ID_SIZE)))

As you can see here Liudongdong has replaced oem_revision with
oem_table_id.

Now it seems that there are some platforms that have already shipped
using a matching based on the oem_revision (right Jon?)

However I guess that if in FW they have defined oem_table_id properly
they should be able to use this mechanism without needing to a FW update.

Can these vendors confirm this?

Tomasz do you think this can work for Cavium Thunder?

Thanks

Gab


> +			return f->ops;
> +	}
> +	/* No quirks, use ECAM */
> +	return &pci_generic_ecam_ops;
> +}
> +
>  phys_addr_t pci_mcfg_lookup(u16 seg, struct resource *bus_res)
>  {
>  	struct mcfg_entry *e;
> @@ -54,7 +90,6 @@ phys_addr_t pci_mcfg_lookup(u16 seg, struct resource
> *bus_res)
> 
>  static __init int pci_mcfg_parse(struct acpi_table_header *header)
>  {
> -	struct acpi_table_mcfg *mcfg;
>  	struct acpi_mcfg_allocation *mptr;
>  	struct mcfg_entry *e, *arr;
>  	int i, n;
> @@ -64,8 +99,8 @@ static __init int pci_mcfg_parse(struct
> acpi_table_header *header)
> 
>  	n = (header->length - sizeof(struct acpi_table_mcfg)) /
>  					sizeof(struct acpi_mcfg_allocation);
> -	mcfg = (struct acpi_table_mcfg *)header;
> -	mptr = (struct acpi_mcfg_allocation *) &mcfg[1];
> +	mcfg_table = (struct acpi_table_mcfg *)header;
> +	mptr = (struct acpi_mcfg_allocation *) &mcfg_table[1];
> 
>  	arr = kcalloc(n, sizeof(*arr), GFP_KERNEL);
>  	if (!arr)
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-
> generic/vmlinux.lds.h
> index 6a67ab9..43604fc 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -300,6 +300,13 @@
>  		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
>  	}								\
>  									\
> +	/* ACPI MCFG quirks */						\
> +	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
> +		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
> +		*(.acpi_fixup_mcfg)					\
> +		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
> +	}								\
> +									\
>  	/* Built-in firmware blobs */					\
>  	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
>  		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status
> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
> 
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
> *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
> *root);
> 
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
> *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>  	int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
> 
> +struct pci_cfg_fixup {
> +	struct pci_ecam_ops *ops;
> +	char *oem_id;
> +	char *oem_table_id;
> +	int domain;
> +	int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY	-1
> +#define PCI_MCFG_BUS_ANY	-1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)
> 	\
> +	static const struct pci_cfg_fixup				\
> +	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\
> +	__used	__attribute__((__section__(".acpi_fixup_mcfg"),
> 	\
> +				aligned((sizeof(void *))))) =		\
> +	{ ops, oem_id, oem_table_id, dom, bus };
> +
>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
> *info);
>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  					    struct acpi_pci_root_ops *ops,
> --
> 1.9.1

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Sinan Kaya]

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
> 
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.
> 
> Can these vendors confirm this?
> 
> Tomasz do you think this can work for Cavium Thunder?
> 
> Thanks
> 
> Gab

Why not have all three of them? 

The initial approach was OEM id and revision id. 

Jeff Hugo indicated that addition (not removing any other fields) of table id
would make more sense.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Sinan Kaya]

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
> 
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.
> 
> Can these vendors confirm this?
> 
> Tomasz do you think this can work for Cavium Thunder?
> 
> Thanks
> 
> Gab

Why not have all three of them? 

The initial approach was OEM id and revision id. 

Jeff Hugo indicated that addition (not removing any other fields) of table id
would make more sense.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Sinan Kaya]

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
> 
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.
> 
> Can these vendors confirm this?
> 
> Tomasz do you think this can work for Cavium Thunder?
> 
> Thanks
> 
> Gab

Why not have all three of them? 

The initial approach was OEM id and revision id. 

Jeff Hugo indicated that addition (not removing any other fields) of table id
would make more sense.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Sinan Kaya]

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
> 
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.
> 
> Can these vendors confirm this?
> 
> Tomasz do you think this can work for Cavium Thunder?
> 
> Thanks
> 
> Gab

Why not have all three of them? 

The initial approach was OEM id and revision id. 

Jeff Hugo indicated that addition (not removing any other fields) of table id
would make more sense.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Sinan

> -----Original Message-----
> From: Sinan Kaya [mailto:okaya@codeaurora.org]
> Sent: 13 June 2016 15:03
> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
> jchandra@broadcom.com; tn@semihalf.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
> (Charles); Linuxarm
> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
> accessors against platfrom specific ECAM quirks
> 
> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> > As you can see here Liudongdong has replaced oem_revision with
> > oem_table_id.
> >
> > Now it seems that there are some platforms that have already shipped
> > using a matching based on the oem_revision (right Jon?)
> >
> > However I guess that if in FW they have defined oem_table_id properly
> > they should be able to use this mechanism without needing to a FW
> update.
> >
> > Can these vendors confirm this?
> >
> > Tomasz do you think this can work for Cavium Thunder?
> >
> > Thanks
> >
> > Gab
> 
> Why not have all three of them?
> 
> The initial approach was OEM id and revision id.
> 
> Jeff Hugo indicated that addition (not removing any other fields) of
> table id
> would make more sense.

Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
PCI config space accessors against platfrom specific ECAM quirks."

I quote:

 "Using the OEM revision 
 field does not seem to be appropriate since these are different 
 platforms and the revision field appears to be for the purpose of 
 tracking differences within a single platform.  Therefore, Cov is 
 proposing using the OEM table id as a mechanism to distinguish
 platform A (needs quirk applied) vs platform B (no quirks) from the
 same OEM."

So it looks to me that he pointed out that using the OEM revision field
is wrong...and this is why I have asked if replacing it with the table
id can work for other vendors....

Thanks

Gab


> 
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Sinan

> -----Original Message-----
> From: Sinan Kaya [mailto:okaya@codeaurora.org]
> Sent: 13 June 2016 15:03
> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
> jchandra@broadcom.com; tn@semihalf.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
> (Charles); Linuxarm
> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
> accessors against platfrom specific ECAM quirks
> 
> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> > As you can see here Liudongdong has replaced oem_revision with
> > oem_table_id.
> >
> > Now it seems that there are some platforms that have already shipped
> > using a matching based on the oem_revision (right Jon?)
> >
> > However I guess that if in FW they have defined oem_table_id properly
> > they should be able to use this mechanism without needing to a FW
> update.
> >
> > Can these vendors confirm this?
> >
> > Tomasz do you think this can work for Cavium Thunder?
> >
> > Thanks
> >
> > Gab
> 
> Why not have all three of them?
> 
> The initial approach was OEM id and revision id.
> 
> Jeff Hugo indicated that addition (not removing any other fields) of
> table id
> would make more sense.

Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
PCI config space accessors against platfrom specific ECAM quirks."

I quote:

 "Using the OEM revision 
 field does not seem to be appropriate since these are different 
 platforms and the revision field appears to be for the purpose of 
 tracking differences within a single platform.  Therefore, Cov is 
 proposing using the OEM table id as a mechanism to distinguish
 platform A (needs quirk applied) vs platform B (no quirks) from the
 same OEM."

So it looks to me that he pointed out that using the OEM revision field
is wrong...and this is why I have asked if replacing it with the table
id can work for other vendors....

Thanks

Gab


> 
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

SGkgU2luYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaW5hbiBL
YXlhIFttYWlsdG86b2theWFAY29kZWF1cm9yYS5vcmddDQo+IFNlbnQ6IDEzIEp1bmUgMjAxNiAx
NTowMw0KPiBUbzogR2FicmllbGUgUGFvbG9uaTsgbGl1ZG9uZ2RvbmcgKEMpOyBoZWxnYWFzQGtl
cm5lbC5vcmc7DQo+IGFybmRAYXJuZGIuZGU7IHdpbGwuZGVhY29uQGFybS5jb207IGNhdGFsaW4u
bWFyaW5hc0Bhcm0uY29tOw0KPiByYWZhZWxAa2VybmVsLm9yZzsgaGFuanVuLmd1b0BsaW5hcm8u
b3JnOyBMb3JlbnpvLlBpZXJhbGlzaUBhcm0uY29tOw0KPiBqY2hhbmRyYUBicm9hZGNvbS5jb207
IHRuQHNlbWloYWxmLmNvbQ0KPiBDYzogcm9iZXJ0LnJpY2h0ZXJAY2F2aXVtbmV0d29ya3MuY29t
OyBtd0BzZW1paGFsZi5jb207DQo+IExpdml1LkR1ZGF1QGFybS5jb207IGRkYW5leUBjYXZpdW1u
ZXR3b3Jrcy5jb207IFdhbmd5aWppbmc7DQo+IFN1cmF2ZWUuU3V0aGlrdWxwYW5pdEBhbWQuY29t
OyBtc2FsdGVyQHJlZGhhdC5jb207IGxpbnV4LQ0KPiBwY2lAdmdlci5rZXJuZWwub3JnOyBsaW51
eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGxpbnV4LQ0KPiBhY3BpQHZnZXIua2Vy
bmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGluYXJvLQ0KPiBhY3BpQGxp
c3RzLmxpbmFyby5vcmc7IGpjbUByZWRoYXQuY29tOyBhbmRyZWEuZ2FsbG9AbGluYXJvLm9yZzsN
Cj4gZGhkYW5nQGFwbS5jb207IGplcmVteS5saW50b25AYXJtLmNvbTsgY292QGNvZGVhdXJvcmEu
b3JnOyBDaGVueGluDQo+IChDaGFybGVzKTsgTGludXhhcm0NCj4gU3ViamVjdDogUmU6IFtSRkMg
UEFUQ0ggVjIgMS8yXSBBQ1BJL1BDSTogTWF0Y2ggUENJIGNvbmZpZyBzcGFjZQ0KPiBhY2Nlc3Nv
cnMgYWdhaW5zdCBwbGF0ZnJvbSBzcGVjaWZpYyBFQ0FNIHF1aXJrcw0KPiANCj4gT24gNi8xMy8y
MDE2IDk6NTQgQU0sIEdhYnJpZWxlIFBhb2xvbmkgd3JvdGU6DQo+ID4gQXMgeW91IGNhbiBzZWUg
aGVyZSBMaXVkb25nZG9uZyBoYXMgcmVwbGFjZWQgb2VtX3JldmlzaW9uIHdpdGgNCj4gPiBvZW1f
dGFibGVfaWQuDQo+ID4NCj4gPiBOb3cgaXQgc2VlbXMgdGhhdCB0aGVyZSBhcmUgc29tZSBwbGF0
Zm9ybXMgdGhhdCBoYXZlIGFscmVhZHkgc2hpcHBlZA0KPiA+IHVzaW5nIGEgbWF0Y2hpbmcgYmFz
ZWQgb24gdGhlIG9lbV9yZXZpc2lvbiAocmlnaHQgSm9uPykNCj4gPg0KPiA+IEhvd2V2ZXIgSSBn
dWVzcyB0aGF0IGlmIGluIEZXIHRoZXkgaGF2ZSBkZWZpbmVkIG9lbV90YWJsZV9pZCBwcm9wZXJs
eQ0KPiA+IHRoZXkgc2hvdWxkIGJlIGFibGUgdG8gdXNlIHRoaXMgbWVjaGFuaXNtIHdpdGhvdXQg
bmVlZGluZyB0byBhIEZXDQo+IHVwZGF0ZS4NCj4gPg0KPiA+IENhbiB0aGVzZSB2ZW5kb3JzIGNv
bmZpcm0gdGhpcz8NCj4gPg0KPiA+IFRvbWFzeiBkbyB5b3UgdGhpbmsgdGhpcyBjYW4gd29yayBm
b3IgQ2F2aXVtIFRodW5kZXI/DQo+ID4NCj4gPiBUaGFua3MNCj4gPg0KPiA+IEdhYg0KPiANCj4g
V2h5IG5vdCBoYXZlIGFsbCB0aHJlZSBvZiB0aGVtPw0KPiANCj4gVGhlIGluaXRpYWwgYXBwcm9h
Y2ggd2FzIE9FTSBpZCBhbmQgcmV2aXNpb24gaWQuDQo+IA0KPiBKZWZmIEh1Z28gaW5kaWNhdGVk
IHRoYXQgYWRkaXRpb24gKG5vdCByZW1vdmluZyBhbnkgb3RoZXIgZmllbGRzKSBvZg0KPiB0YWJs
ZSBpZA0KPiB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UuDQoNCk1tbSBmcm9tIGxhc3QgZW1haWwgb2Yg
SmVmZiBIdWdvIG9uICJbUkZDIFBBVENIIDEvM10gcGNpLCBhY3BpOiBNYXRjaA0KUENJIGNvbmZp
ZyBzcGFjZSBhY2Nlc3NvcnMgYWdhaW5zdCBwbGF0ZnJvbSBzcGVjaWZpYyBFQ0FNIHF1aXJrcy4i
DQoNCkkgcXVvdGU6DQoNCiAiVXNpbmcgdGhlIE9FTSByZXZpc2lvbiANCiBmaWVsZCBkb2VzIG5v
dCBzZWVtIHRvIGJlIGFwcHJvcHJpYXRlIHNpbmNlIHRoZXNlIGFyZSBkaWZmZXJlbnQgDQogcGxh
dGZvcm1zIGFuZCB0aGUgcmV2aXNpb24gZmllbGQgYXBwZWFycyB0byBiZSBmb3IgdGhlIHB1cnBv
c2Ugb2YgDQogdHJhY2tpbmcgZGlmZmVyZW5jZXMgd2l0aGluIGEgc2luZ2xlIHBsYXRmb3JtLiAg
VGhlcmVmb3JlLCBDb3YgaXMgDQogcHJvcG9zaW5nIHVzaW5nIHRoZSBPRU0gdGFibGUgaWQgYXMg
YSBtZWNoYW5pc20gdG8gZGlzdGluZ3Vpc2gNCiBwbGF0Zm9ybSBBIChuZWVkcyBxdWlyayBhcHBs
aWVkKSB2cyBwbGF0Zm9ybSBCIChubyBxdWlya3MpIGZyb20gdGhlDQogc2FtZSBPRU0uIg0KDQpT
byBpdCBsb29rcyB0byBtZSB0aGF0IGhlIHBvaW50ZWQgb3V0IHRoYXQgdXNpbmcgdGhlIE9FTSBy
ZXZpc2lvbiBmaWVsZA0KaXMgd3JvbmcuLi5hbmQgdGhpcyBpcyB3aHkgSSBoYXZlIGFza2VkIGlm
IHJlcGxhY2luZyBpdCB3aXRoIHRoZSB0YWJsZQ0KaWQgY2FuIHdvcmsgZm9yIG90aGVyIHZlbmRv
cnMuLi4uDQoNClRoYW5rcw0KDQpHYWINCg0KDQo+IA0KPiAtLQ0KPiBTaW5hbiBLYXlhDQo+IFF1
YWxjb21tIFRlY2hub2xvZ2llcywgSW5jLiBvbiBiZWhhbGYgb2YgUXVhbGNvbW0gSW5ub3ZhdGlv
biBDZW50ZXIsDQo+IEluYy4NCj4gUXVhbGNvbW0gSW5ub3ZhdGlvbiBDZW50ZXIsIEluYy4gaXMg
YSBtZW1iZXIgb2YgQ29kZSBBdXJvcmEgRm9ydW0sIGENCj4gTGludXggRm91bmRhdGlvbiBDb2xs
YWJvcmF0aXZlIFByb2plY3QNCg==

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Gabriele Paoloni]

Hi Sinan

> -----Original Message-----
> From: Sinan Kaya [mailto:okaya at codeaurora.org]
> Sent: 13 June 2016 15:03
> To: Gabriele Paoloni; liudongdong (C); helgaas at kernel.org;
> arnd at arndb.de; will.deacon at arm.com; catalin.marinas at arm.com;
> rafael at kernel.org; hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com;
> jchandra at broadcom.com; tn at semihalf.com
> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org;
> dhdang at apm.com; jeremy.linton at arm.com; cov at codeaurora.org; Chenxin
> (Charles); Linuxarm
> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
> accessors against platfrom specific ECAM quirks
> 
> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> > As you can see here Liudongdong has replaced oem_revision with
> > oem_table_id.
> >
> > Now it seems that there are some platforms that have already shipped
> > using a matching based on the oem_revision (right Jon?)
> >
> > However I guess that if in FW they have defined oem_table_id properly
> > they should be able to use this mechanism without needing to a FW
> update.
> >
> > Can these vendors confirm this?
> >
> > Tomasz do you think this can work for Cavium Thunder?
> >
> > Thanks
> >
> > Gab
> 
> Why not have all three of them?
> 
> The initial approach was OEM id and revision id.
> 
> Jeff Hugo indicated that addition (not removing any other fields) of
> table id
> would make more sense.

Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
PCI config space accessors against platfrom specific ECAM quirks."

I quote:

 "Using the OEM revision 
 field does not seem to be appropriate since these are different 
 platforms and the revision field appears to be for the purpose of 
 tracking differences within a single platform.  Therefore, Cov is 
 proposing using the OEM table id as a mechanism to distinguish
 platform A (needs quirk applied) vs platform B (no quirks) from the
 same OEM."

So it looks to me that he pointed out that using the OEM revision field
is wrong...and this is why I have asked if replacing it with the table
id can work for other vendors....

Thanks

Gab


> 
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[okaya]

On 2016-06-13 10:29, Gabriele Paoloni wrote:
> Hi Sinan
> 
>> -----Original Message-----
>> From: Sinan Kaya [mailto:okaya@codeaurora.org]
>> Sent: 13 June 2016 15:03
>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
>> jchandra@broadcom.com; tn@semihalf.com
>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
>> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
>> (Charles); Linuxarm
>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>> accessors against platfrom specific ECAM quirks
>> 
>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>> > As you can see here Liudongdong has replaced oem_revision with
>> > oem_table_id.
>> >
>> > Now it seems that there are some platforms that have already shipped
>> > using a matching based on the oem_revision (right Jon?)
>> >
>> > However I guess that if in FW they have defined oem_table_id properly
>> > they should be able to use this mechanism without needing to a FW
>> update.
>> >
>> > Can these vendors confirm this?
>> >
>> > Tomasz do you think this can work for Cavium Thunder?
>> >
>> > Thanks
>> >
>> > Gab
>> 
>> Why not have all three of them?
>> 
>> The initial approach was OEM id and revision id.
>> 
>> Jeff Hugo indicated that addition (not removing any other fields) of
>> table id
>> would make more sense.
> 
> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
> PCI config space accessors against platfrom specific ECAM quirks."
> 
> I quote:
> 
>  "Using the OEM revision
>  field does not seem to be appropriate since these are different
>  platforms and the revision field appears to be for the purpose of
>  tracking differences within a single platform.  Therefore, Cov is
>  proposing using the OEM table id as a mechanism to distinguish
>  platform A (needs quirk applied) vs platform B (no quirks) from the
>  same OEM."
> 
> So it looks to me that he pointed out that using the OEM revision field
> is wrong...and this is why I have asked if replacing it with the table
> id can work for other vendors....
> 
> Thanks
> 
> Gab
> 

I had an internal discussion with jeff and cov before posting on the 
maillist.

I think there is missing info in the email.

Usage of oem id + table id + revision is ok.

Usage of oem id + revision is not ok as one oem can build multiple chips 
with the same oem id and revision id but different table id. Otherwise, 
we can run out of revisions very quickly.

> 
>> 
>> --
>> Sinan Kaya
>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>> Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[okaya at codeaurora.org]

On 2016-06-13 10:29, Gabriele Paoloni wrote:
> Hi Sinan
> 
>> -----Original Message-----
>> From: Sinan Kaya [mailto:okaya at codeaurora.org]
>> Sent: 13 June 2016 15:03
>> To: Gabriele Paoloni; liudongdong (C); helgaas at kernel.org;
>> arnd at arndb.de; will.deacon at arm.com; catalin.marinas at arm.com;
>> rafael at kernel.org; hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com;
>> jchandra at broadcom.com; tn at semihalf.com
>> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com;
>> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
>> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
>> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
>> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org;
>> dhdang at apm.com; jeremy.linton at arm.com; cov at codeaurora.org; Chenxin
>> (Charles); Linuxarm
>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>> accessors against platfrom specific ECAM quirks
>> 
>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>> > As you can see here Liudongdong has replaced oem_revision with
>> > oem_table_id.
>> >
>> > Now it seems that there are some platforms that have already shipped
>> > using a matching based on the oem_revision (right Jon?)
>> >
>> > However I guess that if in FW they have defined oem_table_id properly
>> > they should be able to use this mechanism without needing to a FW
>> update.
>> >
>> > Can these vendors confirm this?
>> >
>> > Tomasz do you think this can work for Cavium Thunder?
>> >
>> > Thanks
>> >
>> > Gab
>> 
>> Why not have all three of them?
>> 
>> The initial approach was OEM id and revision id.
>> 
>> Jeff Hugo indicated that addition (not removing any other fields) of
>> table id
>> would make more sense.
> 
> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
> PCI config space accessors against platfrom specific ECAM quirks."
> 
> I quote:
> 
>  "Using the OEM revision
>  field does not seem to be appropriate since these are different
>  platforms and the revision field appears to be for the purpose of
>  tracking differences within a single platform.  Therefore, Cov is
>  proposing using the OEM table id as a mechanism to distinguish
>  platform A (needs quirk applied) vs platform B (no quirks) from the
>  same OEM."
> 
> So it looks to me that he pointed out that using the OEM revision field
> is wrong...and this is why I have asked if replacing it with the table
> id can work for other vendors....
> 
> Thanks
> 
> Gab
> 

I had an internal discussion with jeff and cov before posting on the 
maillist.

I think there is missing info in the email.

Usage of oem id + table id + revision is ok.

Usage of oem id + revision is not ok as one oem can build multiple chips 
with the same oem id and revision id but different table id. Otherwise, 
we can run out of revisions very quickly.

> 
>> 
>> --
>> Sinan Kaya
>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>> Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Christopher Covington]

Hi Dongdong,

On 06/13/2016 09:02 AM, Dongdong Liu wrote:
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include <linux/kernel.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> +#include <linux/pci-ecam.h>
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
>  
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
>  
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	int bus_num = root->secondary.start;
> +	int domain = root->segment;
> +	struct pci_cfg_fixup *f;
> +
> +	if (!mcfg_table)
> +		return &pci_generic_ecam_ops;
> +
> +	/*
> +	 * Match against platform specific quirks and return corresponding
> +	 * CAM ops.
> +	 *
> +	 * First match against PCI topology <domain:bus> then use OEM ID and
> +	 * OEM revision from MCFG table standard header.
> +	 */
> +	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
> +		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
> +		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
> +		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +			      ACPI_OEM_ID_SIZE)) &&
> +		    (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
> +			      ACPI_OEM_TABLE_ID_SIZE)))

This would just be a small convenience, but if the character count used here were

min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)

then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
wouldn't need to be padded out to the full length.

> +			return f->ops;
> +	}
> +	/* No quirks, use ECAM */
> +	return &pci_generic_ecam_ops;
> +}

> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>  
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>  
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>  	int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
>  
> +struct pci_cfg_fixup {
> +	struct pci_ecam_ops *ops;
> +	char *oem_id;
> +	char *oem_table_id;
> +	int domain;
> +	int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY	-1
> +#define PCI_MCFG_BUS_ANY	-1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)	\
> +	static const struct pci_cfg_fixup				\
> +	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\

I'm not entirely sure that this is the right fix--I'm pretty blindly
following a GCC documentation suggestion [1]--but removing the first two
preprocessor concatenation operators "##" solved the following build error
for me.

include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
  ^
arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ‘DECLARE_ACPI_MCFG_FIXUP’
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
 ^
arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                            ^
include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                 ^
arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
ng token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                                    ^
include/linux/pci-acpi.h:90:25: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                         ^
arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                            ^
include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                 ^
make[1]: *** [arch/arm64/kernel/pci.o] Error 1
make: *** [arch/arm64/kernel] Error 2

1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation

> +	__used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
> +				aligned((sizeof(void *))))) =		\
> +	{ ops, oem_id, oem_table_id, dom, bus };
> +
>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  					    struct acpi_pci_root_ops *ops,
> 

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Christopher Covington]

Hi Dongdong,

On 06/13/2016 09:02 AM, Dongdong Liu wrote:
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include <linux/kernel.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> +#include <linux/pci-ecam.h>
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
>  
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
>  
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	int bus_num = root->secondary.start;
> +	int domain = root->segment;
> +	struct pci_cfg_fixup *f;
> +
> +	if (!mcfg_table)
> +		return &pci_generic_ecam_ops;
> +
> +	/*
> +	 * Match against platform specific quirks and return corresponding
> +	 * CAM ops.
> +	 *
> +	 * First match against PCI topology <domain:bus> then use OEM ID and
> +	 * OEM revision from MCFG table standard header.
> +	 */
> +	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
> +		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
> +		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
> +		    (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +			      ACPI_OEM_ID_SIZE)) &&
> +		    (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
> +			      ACPI_OEM_TABLE_ID_SIZE)))

This would just be a small convenience, but if the character count used here were

min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)

then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
wouldn't need to be padded out to the full length.

> +			return f->ops;
> +	}
> +	/* No quirks, use ECAM */
> +	return &pci_generic_ecam_ops;
> +}

> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>  
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>  
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>  	int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
>  
> +struct pci_cfg_fixup {
> +	struct pci_ecam_ops *ops;
> +	char *oem_id;
> +	char *oem_table_id;
> +	int domain;
> +	int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY	-1
> +#define PCI_MCFG_BUS_ANY	-1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus)	\
> +	static const struct pci_cfg_fixup				\
> +	__mcfg_fixup_##oem_id##oem_table_id##dom##bus			\

I'm not entirely sure that this is the right fix--I'm pretty blindly
following a GCC documentation suggestion [1]--but removing the first two
preprocessor concatenation operators "##" solved the following build error
for me.

include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
  ^
arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ?DECLARE_ACPI_MCFG_FIXUP?
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
 ^
arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                            ^
include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                 ^
arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
ng token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                                    ^
include/linux/pci-acpi.h:90:25: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                         ^
arch/arm64/kernel/pci.c:225:44: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before string constant
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
                                            ^
include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
                 ^
make[1]: *** [arch/arm64/kernel/pci.o] Error 1
make: *** [arch/arm64/kernel] Error 2

1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation

> +	__used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
> +				aligned((sizeof(void *))))) =		\
> +	{ ops, oem_id, oem_table_id, dom, bus };
> +
>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  					    struct acpi_pci_root_ops *ops,
> 

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jeffrey Hugo]

On 6/13/2016 9:12 AM, okaya@codeaurora.org wrote:
> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>> Hi Sinan
>>
>>> -----Original Message-----
>>> From: Sinan Kaya [mailto:okaya@codeaurora.org]
>>> Sent: 13 June 2016 15:03
>>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
>>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
>>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
>>> jchandra@broadcom.com; tn@semihalf.com
>>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
>>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
>>> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
>>> (Charles); Linuxarm
>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>>> accessors against platfrom specific ECAM quirks
>>>
>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>>> > As you can see here Liudongdong has replaced oem_revision with
>>> > oem_table_id.
>>> >
>>> > Now it seems that there are some platforms that have already shipped
>>> > using a matching based on the oem_revision (right Jon?)
>>> >
>>> > However I guess that if in FW they have defined oem_table_id properly
>>> > they should be able to use this mechanism without needing to a FW
>>> update.
>>> >
>>> > Can these vendors confirm this?
>>> >
>>> > Tomasz do you think this can work for Cavium Thunder?
>>> >
>>> > Thanks
>>> >
>>> > Gab
>>>
>>> Why not have all three of them?
>>>
>>> The initial approach was OEM id and revision id.
>>>
>>> Jeff Hugo indicated that addition (not removing any other fields) of
>>> table id
>>> would make more sense.
>>
>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>> PCI config space accessors against platfrom specific ECAM quirks."
>>
>> I quote:
>>
>>  "Using the OEM revision
>>  field does not seem to be appropriate since these are different
>>  platforms and the revision field appears to be for the purpose of
>>  tracking differences within a single platform.  Therefore, Cov is
>>  proposing using the OEM table id as a mechanism to distinguish
>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>  same OEM."
>>
>> So it looks to me that he pointed out that using the OEM revision field
>> is wrong...and this is why I have asked if replacing it with the table
>> id can work for other vendors....
>>
>> Thanks
>>
>> Gab
>>
>
> I had an internal discussion with jeff and cov before posting on the
> maillist.
>
> I think there is missing info in the email.
>
> Usage of oem id + table id + revision is ok.
>
> Usage of oem id + revision is not ok as one oem can build multiple chips
> with the same oem id and revision id but different table id. Otherwise,
> we can run out of revisions very quickly.

Agreed.

I'm sorry for the confusion.  My intent was to point out that revision 
alone appeared insufficient to address all the identified problems, but 
I believe there is still a case for using revision. Table id is useful 
for differentiating between platforms/chips.  Revision is useful for 
differentiation between different versions of a single platform/chip 
assuming the silicon is respun or some other fix is applied.  Both solve 
different scenarios, and I'm not aware of a reason why they could not be 
used together to solve all currently identified cases.

>
>>
>>>
>>> --
>>> Sinan Kaya
>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>>> Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>> Linux Foundation Collaborative Project
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Jeffrey Hugo
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jeffrey Hugo]

On 6/13/2016 9:12 AM, okaya at codeaurora.org wrote:
> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>> Hi Sinan
>>
>>> -----Original Message-----
>>> From: Sinan Kaya [mailto:okaya at codeaurora.org]
>>> Sent: 13 June 2016 15:03
>>> To: Gabriele Paoloni; liudongdong (C); helgaas at kernel.org;
>>> arnd at arndb.de; will.deacon at arm.com; catalin.marinas at arm.com;
>>> rafael at kernel.org; hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com;
>>> jchandra at broadcom.com; tn at semihalf.com
>>> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com;
>>> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
>>> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
>>> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
>>> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org;
>>> dhdang at apm.com; jeremy.linton at arm.com; cov at codeaurora.org; Chenxin
>>> (Charles); Linuxarm
>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>>> accessors against platfrom specific ECAM quirks
>>>
>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>>> > As you can see here Liudongdong has replaced oem_revision with
>>> > oem_table_id.
>>> >
>>> > Now it seems that there are some platforms that have already shipped
>>> > using a matching based on the oem_revision (right Jon?)
>>> >
>>> > However I guess that if in FW they have defined oem_table_id properly
>>> > they should be able to use this mechanism without needing to a FW
>>> update.
>>> >
>>> > Can these vendors confirm this?
>>> >
>>> > Tomasz do you think this can work for Cavium Thunder?
>>> >
>>> > Thanks
>>> >
>>> > Gab
>>>
>>> Why not have all three of them?
>>>
>>> The initial approach was OEM id and revision id.
>>>
>>> Jeff Hugo indicated that addition (not removing any other fields) of
>>> table id
>>> would make more sense.
>>
>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>> PCI config space accessors against platfrom specific ECAM quirks."
>>
>> I quote:
>>
>>  "Using the OEM revision
>>  field does not seem to be appropriate since these are different
>>  platforms and the revision field appears to be for the purpose of
>>  tracking differences within a single platform.  Therefore, Cov is
>>  proposing using the OEM table id as a mechanism to distinguish
>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>  same OEM."
>>
>> So it looks to me that he pointed out that using the OEM revision field
>> is wrong...and this is why I have asked if replacing it with the table
>> id can work for other vendors....
>>
>> Thanks
>>
>> Gab
>>
>
> I had an internal discussion with jeff and cov before posting on the
> maillist.
>
> I think there is missing info in the email.
>
> Usage of oem id + table id + revision is ok.
>
> Usage of oem id + revision is not ok as one oem can build multiple chips
> with the same oem id and revision id but different table id. Otherwise,
> we can run out of revisions very quickly.

Agreed.

I'm sorry for the confusion.  My intent was to point out that revision 
alone appeared insufficient to address all the identified problems, but 
I believe there is still a case for using revision. Table id is useful 
for differentiating between platforms/chips.  Revision is useful for 
differentiation between different versions of a single platform/chip 
assuming the silicon is respun or some other fix is applied.  Both solve 
different scenarios, and I'm not aware of a reason why they could not be 
used together to solve all currently identified cases.

>
>>
>>>
>>> --
>>> Sinan Kaya
>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>>> Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>> Linux Foundation Collaborative Project
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Jeffrey Hugo
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
<cov@codeaurora.org> wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include <linux/kernel.h>
>>  #include <linux/pci.h>
>>  #include <linux/pci-acpi.h>
>> +#include <linux/pci-ecam.h>
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> +     int bus_num = root->secondary.start;
>> +     int domain = root->segment;
>> +     struct pci_cfg_fixup *f;
>> +
>> +     if (!mcfg_table)
>> +             return &pci_generic_ecam_ops;
>> +
>> +     /*
>> +      * Match against platform specific quirks and return corresponding
>> +      * CAM ops.
>> +      *
>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>> +      * OEM revision from MCFG table standard header.
>> +      */
>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +                           ACPI_OEM_ID_SIZE)) &&
>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used here were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
> wouldn't need to be padded out to the full length.
>
>> +                     return f->ops;
>> +     }
>> +     /* No quirks, use ECAM */
>> +     return &pci_generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>       int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> +     struct pci_ecam_ops *ops;
>> +     char *oem_id;
>> +     char *oem_table_id;
>> +     int domain;
>> +     int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY     -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> +     static const struct pci_cfg_fixup                               \
>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build error
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
        static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
> ng token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                                     ^
> include/linux/pci-acpi.h:90:25: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                          ^
> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
> make: *** [arch/arm64/kernel] Error 2
>
> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>
>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>> +                             aligned((sizeof(void *))))) =           \
>> +     { ops, oem_id, oem_table_id, dom, bus };
>> +
>>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>                                           struct acpi_pci_root_ops *ops,
>>
>
> Thanks,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
<cov@codeaurora.org> wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include <linux/kernel.h>
>>  #include <linux/pci.h>
>>  #include <linux/pci-acpi.h>
>> +#include <linux/pci-ecam.h>
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> +     int bus_num = root->secondary.start;
>> +     int domain = root->segment;
>> +     struct pci_cfg_fixup *f;
>> +
>> +     if (!mcfg_table)
>> +             return &pci_generic_ecam_ops;
>> +
>> +     /*
>> +      * Match against platform specific quirks and return corresponding
>> +      * CAM ops.
>> +      *
>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>> +      * OEM revision from MCFG table standard header.
>> +      */
>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +                           ACPI_OEM_ID_SIZE)) &&
>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used here were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
> wouldn't need to be padded out to the full length.
>
>> +                     return f->ops;
>> +     }
>> +     /* No quirks, use ECAM */
>> +     return &pci_generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>       int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> +     struct pci_ecam_ops *ops;
>> +     char *oem_id;
>> +     char *oem_table_id;
>> +     int domain;
>> +     int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY     -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> +     static const struct pci_cfg_fixup                               \
>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build error
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
        static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
> ng token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                                     ^
> include/linux/pci-acpi.h:90:25: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                          ^
> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
> make: *** [arch/arm64/kernel] Error 2
>
> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>
>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>> +                             aligned((sizeof(void *))))) =           \
>> +     { ops, oem_id, oem_table_id, dom, bus };
>> +
>>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>                                           struct acpi_pci_root_ops *ops,
>>
>
> Thanks,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
<cov@codeaurora.org> wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include <linux/kernel.h>
>>  #include <linux/pci.h>
>>  #include <linux/pci-acpi.h>
>> +#include <linux/pci-ecam.h>
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> +     int bus_num =3D root->secondary.start;
>> +     int domain =3D root->segment;
>> +     struct pci_cfg_fixup *f;
>> +
>> +     if (!mcfg_table)
>> +             return &pci_generic_ecam_ops;
>> +
>> +     /*
>> +      * Match against platform specific quirks and return corresponding
>> +      * CAM ops.
>> +      *
>> +      * First match against PCI topology <domain:bus> then use OEM ID a=
nd
>> +      * OEM revision from MCFG table standard header.
>> +      */
>> +     for (f =3D __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f=
++) {
>> +             if ((f->domain =3D=3D domain || f->domain =3D=3D PCI_MCFG_=
DOMAIN_ANY) &&
>> +                 (f->bus_num =3D=3D bus_num || f->bus_num =3D=3D PCI_MC=
FG_BUS_ANY) &&
>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +                           ACPI_OEM_ID_SIZE)) &&
>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_tabl=
e_id,
>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used h=
ere were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings =
and
> wouldn't need to be padded out to the full length.
>
>> +                     return f->ops;
>> +     }
>> +     /* No quirks, use ECAM */
>> +     return &pci_generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(=
struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res=
);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root=
);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *=
pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>       int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> +     struct pci_ecam_ops *ops;
>> +     char *oem_id;
>> +     char *oem_table_id;
>> +     int domain;
>> +     int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY     -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> +     static const struct pci_cfg_fixup                               \
>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build erro=
r
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"=
" does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
        static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =3D           \
        { ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro =E2=80=98DECLA=
RE_ACPI_MCFG_FIXUP=E2=80=99
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_D=
OMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" d=
oes not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_D=
OMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro =E2=80=98DEC=
LARE_ACPI_MCFG_FIXUP=E2=80=99
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_=
DOMAIN_ANY" does not give a valid preprocessi
> ng token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_D=
OMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                                     ^
> include/linux/pci-acpi.h:90:25: note: in definition of macro =E2=80=98DEC=
LARE_ACPI_MCFG_FIXUP=E2=80=99
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                          ^
> arch/arm64/kernel/pci.c:225:44: error: expected =E2=80=98=3D=E2=80=99, =
=E2=80=98,=E2=80=99, =E2=80=98;=E2=80=99, =E2=80=98asm=E2=80=99 or =E2=80=
=98__attribute__=E2=80=99 before string constant
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_D=
OMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro =E2=80=98DEC=
LARE_ACPI_MCFG_FIXUP=E2=80=99
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
> make: *** [arch/arm64/kernel] Error 2
>
> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>
>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>> +                             aligned((sizeof(void *))))) =3D           =
\
>> +     { ops, oem_id, oem_table_id, dom, bus };
>> +
>>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *inf=
o);
>>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>                                           struct acpi_pci_root_ops *ops,
>>
>
> Thanks,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo <jhugo@codeaurora.org> wrote:
> On 6/13/2016 9:12 AM, okaya@codeaurora.org wrote:
>>
>> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>>>
>>> Hi Sinan
>>>
>>>> -----Original Message-----
>>>> From: Sinan Kaya [mailto:okaya@codeaurora.org]
>>>> Sent: 13 June 2016 15:03
>>>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
>>>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
>>>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
>>>> jchandra@broadcom.com; tn@semihalf.com
>>>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
>>>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
>>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
>>>> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
>>>> (Charles); Linuxarm
>>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>>>> accessors against platfrom specific ECAM quirks
>>>>
>>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>>>> > As you can see here Liudongdong has replaced oem_revision with
>>>> > oem_table_id.
>>>> >
>>>> > Now it seems that there are some platforms that have already shipped
>>>> > using a matching based on the oem_revision (right Jon?)
>>>> >
>>>> > However I guess that if in FW they have defined oem_table_id properly
>>>> > they should be able to use this mechanism without needing to a FW
>>>> update.
>>>> >
>>>> > Can these vendors confirm this?
>>>> >
>>>> > Tomasz do you think this can work for Cavium Thunder?
>>>> >
>>>> > Thanks
>>>> >
>>>> > Gab
>>>>
>>>> Why not have all three of them?
>>>>
>>>> The initial approach was OEM id and revision id.
>>>>
>>>> Jeff Hugo indicated that addition (not removing any other fields) of
>>>> table id
>>>> would make more sense.
>>>
>>>
>>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>>> PCI config space accessors against platfrom specific ECAM quirks."
>>>
>>> I quote:
>>>
>>>  "Using the OEM revision
>>>  field does not seem to be appropriate since these are different
>>>  platforms and the revision field appears to be for the purpose of
>>>  tracking differences within a single platform.  Therefore, Cov is
>>>  proposing using the OEM table id as a mechanism to distinguish
>>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>>  same OEM."
>>>
>>> So it looks to me that he pointed out that using the OEM revision field
>>> is wrong...and this is why I have asked if replacing it with the table
>>> id can work for other vendors....
>>>
>>> Thanks
>>>
>>> Gab
>>>
>>
>> I had an internal discussion with jeff and cov before posting on the
>> maillist.
>>
>> I think there is missing info in the email.
>>
>> Usage of oem id + table id + revision is ok.
>>
>> Usage of oem id + revision is not ok as one oem can build multiple chips
>> with the same oem id and revision id but different table id. Otherwise,
>> we can run out of revisions very quickly.
>
>
> Agreed.
>
> I'm sorry for the confusion.  My intent was to point out that revision alone
> appeared insufficient to address all the identified problems, but I believe
> there is still a case for using revision. Table id is useful for
> differentiating between platforms/chips.  Revision is useful for
> differentiation between different versions of a single platform/chip
> assuming the silicon is respun or some other fix is applied.  Both solve
> different scenarios, and I'm not aware of a reason why they could not be
> used together to solve all currently identified cases.

Using OEM ID + Table ID + Revision will work for X-Gene platforms as well.

Regards,
Duc Dang.
>
>>
>>>
>>>>
>>>> --
>>>> Sinan Kaya
>>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>>>> Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>>> Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Jeffrey Hugo
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo <jhugo@codeaurora.org> wrote:
> On 6/13/2016 9:12 AM, okaya@codeaurora.org wrote:
>>
>> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>>>
>>> Hi Sinan
>>>
>>>> -----Original Message-----
>>>> From: Sinan Kaya [mailto:okaya@codeaurora.org]
>>>> Sent: 13 June 2016 15:03
>>>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org;
>>>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
>>>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
>>>> jchandra@broadcom.com; tn@semihalf.com
>>>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
>>>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
>>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
>>>> dhdang@apm.com; jeremy.linton@arm.com; cov@codeaurora.org; Chenxin
>>>> (Charles); Linuxarm
>>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>>>> accessors against platfrom specific ECAM quirks
>>>>
>>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>>>> > As you can see here Liudongdong has replaced oem_revision with
>>>> > oem_table_id.
>>>> >
>>>> > Now it seems that there are some platforms that have already shipped
>>>> > using a matching based on the oem_revision (right Jon?)
>>>> >
>>>> > However I guess that if in FW they have defined oem_table_id properly
>>>> > they should be able to use this mechanism without needing to a FW
>>>> update.
>>>> >
>>>> > Can these vendors confirm this?
>>>> >
>>>> > Tomasz do you think this can work for Cavium Thunder?
>>>> >
>>>> > Thanks
>>>> >
>>>> > Gab
>>>>
>>>> Why not have all three of them?
>>>>
>>>> The initial approach was OEM id and revision id.
>>>>
>>>> Jeff Hugo indicated that addition (not removing any other fields) of
>>>> table id
>>>> would make more sense.
>>>
>>>
>>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>>> PCI config space accessors against platfrom specific ECAM quirks."
>>>
>>> I quote:
>>>
>>>  "Using the OEM revision
>>>  field does not seem to be appropriate since these are different
>>>  platforms and the revision field appears to be for the purpose of
>>>  tracking differences within a single platform.  Therefore, Cov is
>>>  proposing using the OEM table id as a mechanism to distinguish
>>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>>  same OEM."
>>>
>>> So it looks to me that he pointed out that using the OEM revision field
>>> is wrong...and this is why I have asked if replacing it with the table
>>> id can work for other vendors....
>>>
>>> Thanks
>>>
>>> Gab
>>>
>>
>> I had an internal discussion with jeff and cov before posting on the
>> maillist.
>>
>> I think there is missing info in the email.
>>
>> Usage of oem id + table id + revision is ok.
>>
>> Usage of oem id + revision is not ok as one oem can build multiple chips
>> with the same oem id and revision id but different table id. Otherwise,
>> we can run out of revisions very quickly.
>
>
> Agreed.
>
> I'm sorry for the confusion.  My intent was to point out that revision alone
> appeared insufficient to address all the identified problems, but I believe
> there is still a case for using revision. Table id is useful for
> differentiating between platforms/chips.  Revision is useful for
> differentiation between different versions of a single platform/chip
> assuming the silicon is respun or some other fix is applied.  Both solve
> different scenarios, and I'm not aware of a reason why they could not be
> used together to solve all currently identified cases.

Using OEM ID + Table ID + Revision will work for X-Gene platforms as well.

Regards,
Duc Dang.
>
>>
>>>
>>>>
>>>> --
>>>> Sinan Kaya
>>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>>>> Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>>> Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Jeffrey Hugo
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

在 2016/6/14 4:57, Duc Dang 写道:
> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
> <cov@codeaurora.org> wrote:
>> Hi Dongdong,
>>
>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>> index d3c3e85..49612b3 100644
>>> --- a/drivers/acpi/pci_mcfg.c
>>> +++ b/drivers/acpi/pci_mcfg.c
>>> @@ -22,6 +22,10 @@
>>>   #include <linux/kernel.h>
>>>   #include <linux/pci.h>
>>>   #include <linux/pci-acpi.h>
>>> +#include <linux/pci-ecam.h>
>>> +
>>> +/* Root pointer to the mapped MCFG table */
>>> +static struct acpi_table_mcfg *mcfg_table;
>>>
>>>   /* Structure to hold entries from the MCFG table */
>>>   struct mcfg_entry {
>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>   /* List to save mcfg entries */
>>>   static LIST_HEAD(pci_mcfg_list);
>>>
>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>> +
>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>> +{
>>> +     int bus_num = root->secondary.start;
>>> +     int domain = root->segment;
>>> +     struct pci_cfg_fixup *f;
>>> +
>>> +     if (!mcfg_table)
>>> +             return &pci_generic_ecam_ops;
>>> +
>>> +     /*
>>> +      * Match against platform specific quirks and return corresponding
>>> +      * CAM ops.
>>> +      *
>>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>>> +      * OEM revision from MCFG table standard header.
>>> +      */
>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>> +                           ACPI_OEM_ID_SIZE)) &&
>>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>
>> This would just be a small convenience, but if the character count used here were
>>
>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>
>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
>> wouldn't need to be padded out to the full length.
>>
>>> +                     return f->ops;
>>> +     }
>>> +     /* No quirks, use ECAM */
>>> +     return &pci_generic_ecam_ops;
>>> +}
>>
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 7d63a66..088a1da 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>
>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>>
>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>>   {
>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>   };
>>>
>>> +struct pci_cfg_fixup {
>>> +     struct pci_ecam_ops *ops;
>>> +     char *oem_id;
>>> +     char *oem_table_id;
>>> +     int domain;
>>> +     int bus_num;
>>> +};
>>> +
>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>> +#define PCI_MCFG_BUS_ANY     -1
>>> +
>>> +/* Designate a routine to fix up buggy MCFG */
>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>> +     static const struct pci_cfg_fixup                               \
>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>
>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>> following a GCC documentation suggestion [1]--but removing the first two
>> preprocessor concatenation operators "##" solved the following build error
>> for me.
>>
>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
> I think the problem is gcc is not happy with quoted string when
> processing these tokens
> (""QCOM"", the extra "" are added by gcc). So should we not concat
> string tokens and
> use the fixup definition in v1 of this RFC:
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \
>          { ops, oem_id, rev, dom, bus };

V1 fixup exist the redefinition error when compiling mutiple DECLARE_ACPI_MCFG_FIXUP
with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.

#define EFI_ACPI_HISI_OEM_ID "HISI"
#define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
#define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
include/linux/pci-acpi.h:98:43: error: redefinition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'
  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
  ^
include/linux/pci-acpi.h:98:43: note: previous definition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'


V2 fixup can resolve the redefinition error, but need to use macro.
We can see that the name of macro is not replace with it's value in
"__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".

Any good idea is appreciated.

Thanks
Dongdong

>
> Regards,
> Duc Dang.
>
>
>>    ^
>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>   ^
>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>> ng token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                                      ^
>> include/linux/pci-acpi.h:90:25: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                           ^
>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>> make: *** [arch/arm64/kernel] Error 2
>>
>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>
>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>> +                             aligned((sizeof(void *))))) =           \
>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>> +
>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>>                                            struct acpi_pci_root_ops *ops,
>>>
>>
>> Thanks,
>> Cov
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

在 2016/6/14 4:57, Duc Dang 写道:
> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
> <cov@codeaurora.org> wrote:
>> Hi Dongdong,
>>
>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>> index d3c3e85..49612b3 100644
>>> --- a/drivers/acpi/pci_mcfg.c
>>> +++ b/drivers/acpi/pci_mcfg.c
>>> @@ -22,6 +22,10 @@
>>>   #include <linux/kernel.h>
>>>   #include <linux/pci.h>
>>>   #include <linux/pci-acpi.h>
>>> +#include <linux/pci-ecam.h>
>>> +
>>> +/* Root pointer to the mapped MCFG table */
>>> +static struct acpi_table_mcfg *mcfg_table;
>>>
>>>   /* Structure to hold entries from the MCFG table */
>>>   struct mcfg_entry {
>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>   /* List to save mcfg entries */
>>>   static LIST_HEAD(pci_mcfg_list);
>>>
>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>> +
>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>> +{
>>> +     int bus_num = root->secondary.start;
>>> +     int domain = root->segment;
>>> +     struct pci_cfg_fixup *f;
>>> +
>>> +     if (!mcfg_table)
>>> +             return &pci_generic_ecam_ops;
>>> +
>>> +     /*
>>> +      * Match against platform specific quirks and return corresponding
>>> +      * CAM ops.
>>> +      *
>>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>>> +      * OEM revision from MCFG table standard header.
>>> +      */
>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>> +                           ACPI_OEM_ID_SIZE)) &&
>>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>
>> This would just be a small convenience, but if the character count used here were
>>
>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>
>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
>> wouldn't need to be padded out to the full length.
>>
>>> +                     return f->ops;
>>> +     }
>>> +     /* No quirks, use ECAM */
>>> +     return &pci_generic_ecam_ops;
>>> +}
>>
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 7d63a66..088a1da 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>
>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>>
>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>>   {
>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>   };
>>>
>>> +struct pci_cfg_fixup {
>>> +     struct pci_ecam_ops *ops;
>>> +     char *oem_id;
>>> +     char *oem_table_id;
>>> +     int domain;
>>> +     int bus_num;
>>> +};
>>> +
>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>> +#define PCI_MCFG_BUS_ANY     -1
>>> +
>>> +/* Designate a routine to fix up buggy MCFG */
>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>> +     static const struct pci_cfg_fixup                               \
>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>
>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>> following a GCC documentation suggestion [1]--but removing the first two
>> preprocessor concatenation operators "##" solved the following build error
>> for me.
>>
>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
> I think the problem is gcc is not happy with quoted string when
> processing these tokens
> (""QCOM"", the extra "" are added by gcc). So should we not concat
> string tokens and
> use the fixup definition in v1 of this RFC:
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \
>          { ops, oem_id, rev, dom, bus };

V1 fixup exist the redefinition error when compiling mutiple DECLARE_ACPI_MCFG_FIXUP
with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.

#define EFI_ACPI_HISI_OEM_ID "HISI"
#define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
#define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
include/linux/pci-acpi.h:98:43: error: redefinition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'
  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
  ^
include/linux/pci-acpi.h:98:43: note: previous definition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'


V2 fixup can resolve the redefinition error, but need to use macro.
We can see that the name of macro is not replace with it's value in
"__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".

Any good idea is appreciated.

Thanks
Dongdong

>
> Regards,
> Duc Dang.
>
>
>>    ^
>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>   ^
>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>> ng token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                                      ^
>> include/linux/pci-acpi.h:90:25: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                           ^
>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ‘DECLARE_ACPI_MCFG_FIXUP’
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>> make: *** [arch/arm64/kernel] Error 2
>>
>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>
>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>> +                             aligned((sizeof(void *))))) =           \
>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>> +
>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>>                                            struct acpi_pci_root_ops *ops,
>>>
>>
>> Thanks,
>> Cov
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>
> .
>

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

? 2016/6/14 4:57, Duc Dang ??:
> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
> <cov@codeaurora.org> wrote:
>> Hi Dongdong,
>>
>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>> index d3c3e85..49612b3 100644
>>> --- a/drivers/acpi/pci_mcfg.c
>>> +++ b/drivers/acpi/pci_mcfg.c
>>> @@ -22,6 +22,10 @@
>>>   #include <linux/kernel.h>
>>>   #include <linux/pci.h>
>>>   #include <linux/pci-acpi.h>
>>> +#include <linux/pci-ecam.h>
>>> +
>>> +/* Root pointer to the mapped MCFG table */
>>> +static struct acpi_table_mcfg *mcfg_table;
>>>
>>>   /* Structure to hold entries from the MCFG table */
>>>   struct mcfg_entry {
>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>   /* List to save mcfg entries */
>>>   static LIST_HEAD(pci_mcfg_list);
>>>
>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>> +
>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>> +{
>>> +     int bus_num = root->secondary.start;
>>> +     int domain = root->segment;
>>> +     struct pci_cfg_fixup *f;
>>> +
>>> +     if (!mcfg_table)
>>> +             return &pci_generic_ecam_ops;
>>> +
>>> +     /*
>>> +      * Match against platform specific quirks and return corresponding
>>> +      * CAM ops.
>>> +      *
>>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>>> +      * OEM revision from MCFG table standard header.
>>> +      */
>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>> +                           ACPI_OEM_ID_SIZE)) &&
>>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>
>> This would just be a small convenience, but if the character count used here were
>>
>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>
>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
>> wouldn't need to be padded out to the full length.
>>
>>> +                     return f->ops;
>>> +     }
>>> +     /* No quirks, use ECAM */
>>> +     return &pci_generic_ecam_ops;
>>> +}
>>
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 7d63a66..088a1da 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>
>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>>
>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>>   {
>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>   };
>>>
>>> +struct pci_cfg_fixup {
>>> +     struct pci_ecam_ops *ops;
>>> +     char *oem_id;
>>> +     char *oem_table_id;
>>> +     int domain;
>>> +     int bus_num;
>>> +};
>>> +
>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>> +#define PCI_MCFG_BUS_ANY     -1
>>> +
>>> +/* Designate a routine to fix up buggy MCFG */
>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>> +     static const struct pci_cfg_fixup                               \
>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>
>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>> following a GCC documentation suggestion [1]--but removing the first two
>> preprocessor concatenation operators "##" solved the following build error
>> for me.
>>
>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
> I think the problem is gcc is not happy with quoted string when
> processing these tokens
> (""QCOM"", the extra "" are added by gcc). So should we not concat
> string tokens and
> use the fixup definition in v1 of this RFC:
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \
>          { ops, oem_id, rev, dom, bus };

V1 fixup exist the redefinition error when compiling mutiple DECLARE_ACPI_MCFG_FIXUP
with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.

#define EFI_ACPI_HISI_OEM_ID "HISI"
#define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
#define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
include/linux/pci-acpi.h:98:43: error: redefinition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'
  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
  ^
include/linux/pci-acpi.h:98:43: note: previous definition of '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
                                            ^
drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro 'DECLARE_ACPI_MCFG_FIXUP'


V2 fixup can resolve the redefinition error, but need to use macro.
We can see that the name of macro is not replace with it's value in
"__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".

Any good idea is appreciated.

Thanks
Dongdong

>
> Regards,
> Duc Dang.
>
>
>>    ^
>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ?DECLARE_ACPI_MCFG_FIXUP?
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>   ^
>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>> ng token
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                                      ^
>> include/linux/pci-acpi.h:90:25: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                           ^
>> arch/arm64/kernel/pci.c:225:44: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before string constant
>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>                                              ^
>> include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>                   ^
>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>> make: *** [arch/arm64/kernel] Error 2
>>
>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>
>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>> +                             aligned((sizeof(void *))))) =           \
>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>> +
>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>>                                            struct acpi_pci_root_ops *ops,
>>>
>>
>> Thanks,
>> Cov
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>
> .
>

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
> Hi Duc
>
> 在 2016/6/14 4:57, Duc Dang 写道:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>
>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>> index d3c3e85..49612b3 100644
>>>> --- a/drivers/acpi/pci_mcfg.c
>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>> @@ -22,6 +22,10 @@
>>>>   #include <linux/kernel.h>
>>>>   #include <linux/pci.h>
>>>>   #include <linux/pci-acpi.h>
>>>> +#include <linux/pci-ecam.h>
>>>> +
>>>> +/* Root pointer to the mapped MCFG table */
>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>
>>>>   /* Structure to hold entries from the MCFG table */
>>>>   struct mcfg_entry {
>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>   /* List to save mcfg entries */
>>>>   static LIST_HEAD(pci_mcfg_list);
>>>>
>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>> +
>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>> +{
>>>> +     int bus_num = root->secondary.start;
>>>> +     int domain = root->segment;
>>>> +     struct pci_cfg_fixup *f;
>>>> +
>>>> +     if (!mcfg_table)
>>>> +             return &pci_generic_ecam_ops;
>>>> +
>>>> +     /*
>>>> +      * Match against platform specific quirks and return corresponding
>>>> +      * CAM ops.
>>>> +      *
>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>> and
>>>> +      * OEM revision from MCFG table standard header.
>>>> +      */
>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> +             if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>> +                 (!strncmp(f->oem_table_id,
>>>> mcfg_table->header.oem_table_id,
>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
>>>> +                     return f->ops;
>>>> +     }
>>>> +     /* No quirks, use ECAM */
>>>> +     return &pci_generic_ecam_ops;
>>>> +}
>>>
>>>
>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>> index 7d63a66..088a1da 100644
>>>> --- a/include/linux/pci-acpi.h
>>>> +++ b/include/linux/pci-acpi.h
>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>
>>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>> *bus_res);
>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>> *root);
>>>>
>>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>> *pdev)
>>>>   {
>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>   };
>>>>
>>>> +struct pci_cfg_fixup {
>>>> +     struct pci_ecam_ops *ops;
>>>> +     char *oem_id;
>>>> +     char *oem_table_id;
>>>> +     int domain;
>>>> +     int bus_num;
>>>> +};
>>>> +
>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>> +
>>>> +/* Designate a routine to fix up buggy MCFG */
>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>> +     static const struct pci_cfg_fixup                               \
>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first two
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *))))) =           \
>>          { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the redefinition error when compiling mutiple
> DECLARE_ACPI_MCFG_FIXUP
> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>
> #define EFI_ACPI_HISI_OEM_ID "HISI"
> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
> include/linux/pci-acpi.h:98:43: error: redefinition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>  ^
> include/linux/pci-acpi.h:98:43: note: previous definition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>
>
> V2 fixup can resolve the redefinition error, but need to use macro.
> We can see that the name of macro is not replace with it's value in
> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>
> Any good idea is appreciated.
Hmmm.

I was testing # op and using min_t to get the min-len when doing
strncmp similar to Chris' suggestion (using min_t avoids type
warnings)

/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
        static const struct pci_cfg_fixup
__mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, #oem_id, #oem_table_id, rev, dom, bus };

My fixup definition:
DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
                                               PCI_MCFG_DOMAIN_ANY,
PCI_MCFG_BUS_ANY);
My match condition is:
               if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
                   (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
                   (!strncmp(f->oem_id, mcfg->header.oem_id,
                             min_t(size_t, strlen(f->oem_id),
                                   ACPI_OEM_ID_SIZE))) &&
                   (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
                             min_t(size_t, strlen(f->oem_table_id),
                                   ACPI_OEM_TABLE_ID_SIZE))) &&
                   (f->oem_revision == mcfg->header.oem_revision)) {
                       return f->ops;
               }

But this still does not work for your case as having HISI-D02 as
oem_table_id will cause error.

>
> Thanks
> Dongdong
>
>>
>> Regards,
>> Duc Dang.
>>
>>
>>>    ^
>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>   ^
>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>> does not give a valid preprocessing token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>> ng token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                                      ^
>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                           ^
>>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before string constant
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>> make: *** [arch/arm64/kernel] Error 2
>>>
>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>
>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>> +                             aligned((sizeof(void *))))) =           \
>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>> +
>>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>> *info);
>>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>> *root,
>>>>                                            struct acpi_pci_root_ops
>>>> *ops,
>>>>
>>>
>>> Thanks,
>>> Cov
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>
>>
>> .
>>
>
Regards
Duc Dang.

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
> Hi Duc
>
> 在 2016/6/14 4:57, Duc Dang 写道:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>
>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>> index d3c3e85..49612b3 100644
>>>> --- a/drivers/acpi/pci_mcfg.c
>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>> @@ -22,6 +22,10 @@
>>>>   #include <linux/kernel.h>
>>>>   #include <linux/pci.h>
>>>>   #include <linux/pci-acpi.h>
>>>> +#include <linux/pci-ecam.h>
>>>> +
>>>> +/* Root pointer to the mapped MCFG table */
>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>
>>>>   /* Structure to hold entries from the MCFG table */
>>>>   struct mcfg_entry {
>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>   /* List to save mcfg entries */
>>>>   static LIST_HEAD(pci_mcfg_list);
>>>>
>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>> +
>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>> +{
>>>> +     int bus_num = root->secondary.start;
>>>> +     int domain = root->segment;
>>>> +     struct pci_cfg_fixup *f;
>>>> +
>>>> +     if (!mcfg_table)
>>>> +             return &pci_generic_ecam_ops;
>>>> +
>>>> +     /*
>>>> +      * Match against platform specific quirks and return corresponding
>>>> +      * CAM ops.
>>>> +      *
>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>> and
>>>> +      * OEM revision from MCFG table standard header.
>>>> +      */
>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> +             if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>> +                 (!strncmp(f->oem_table_id,
>>>> mcfg_table->header.oem_table_id,
>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
>>>> +                     return f->ops;
>>>> +     }
>>>> +     /* No quirks, use ECAM */
>>>> +     return &pci_generic_ecam_ops;
>>>> +}
>>>
>>>
>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>> index 7d63a66..088a1da 100644
>>>> --- a/include/linux/pci-acpi.h
>>>> +++ b/include/linux/pci-acpi.h
>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>
>>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>> *bus_res);
>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>> *root);
>>>>
>>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>> *pdev)
>>>>   {
>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>   };
>>>>
>>>> +struct pci_cfg_fixup {
>>>> +     struct pci_ecam_ops *ops;
>>>> +     char *oem_id;
>>>> +     char *oem_table_id;
>>>> +     int domain;
>>>> +     int bus_num;
>>>> +};
>>>> +
>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>> +
>>>> +/* Designate a routine to fix up buggy MCFG */
>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>> +     static const struct pci_cfg_fixup                               \
>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first two
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *))))) =           \
>>          { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the redefinition error when compiling mutiple
> DECLARE_ACPI_MCFG_FIXUP
> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>
> #define EFI_ACPI_HISI_OEM_ID "HISI"
> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
> include/linux/pci-acpi.h:98:43: error: redefinition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>  ^
> include/linux/pci-acpi.h:98:43: note: previous definition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>
>
> V2 fixup can resolve the redefinition error, but need to use macro.
> We can see that the name of macro is not replace with it's value in
> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>
> Any good idea is appreciated.
Hmmm.

I was testing # op and using min_t to get the min-len when doing
strncmp similar to Chris' suggestion (using min_t avoids type
warnings)

/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
        static const struct pci_cfg_fixup
__mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, #oem_id, #oem_table_id, rev, dom, bus };

My fixup definition:
DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
                                               PCI_MCFG_DOMAIN_ANY,
PCI_MCFG_BUS_ANY);
My match condition is:
               if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
                   (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
                   (!strncmp(f->oem_id, mcfg->header.oem_id,
                             min_t(size_t, strlen(f->oem_id),
                                   ACPI_OEM_ID_SIZE))) &&
                   (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
                             min_t(size_t, strlen(f->oem_table_id),
                                   ACPI_OEM_TABLE_ID_SIZE))) &&
                   (f->oem_revision == mcfg->header.oem_revision)) {
                       return f->ops;
               }

But this still does not work for your case as having HISI-D02 as
oem_table_id will cause error.

>
> Thanks
> Dongdong
>
>>
>> Regards,
>> Duc Dang.
>>
>>
>>>    ^
>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>   ^
>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>> does not give a valid preprocessing token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>> ng token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                                      ^
>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                           ^
>>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before string constant
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>> make: *** [arch/arm64/kernel] Error 2
>>>
>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>
>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>> +                             aligned((sizeof(void *))))) =           \
>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>> +
>>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>> *info);
>>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>> *root,
>>>>                                            struct acpi_pci_root_ops
>>>> *ops,
>>>>
>>>
>>> Thanks,
>>> Cov
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>
>>
>> .
>>
>
Regards
Duc Dang.

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wr=
ote:
> Hi Duc
>
> =E5=9C=A8 2016/6/14 4:57, Duc Dang =E5=86=99=E9=81=93:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>
>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>> index d3c3e85..49612b3 100644
>>>> --- a/drivers/acpi/pci_mcfg.c
>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>> @@ -22,6 +22,10 @@
>>>>   #include <linux/kernel.h>
>>>>   #include <linux/pci.h>
>>>>   #include <linux/pci-acpi.h>
>>>> +#include <linux/pci-ecam.h>
>>>> +
>>>> +/* Root pointer to the mapped MCFG table */
>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>
>>>>   /* Structure to hold entries from the MCFG table */
>>>>   struct mcfg_entry {
>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>   /* List to save mcfg entries */
>>>>   static LIST_HEAD(pci_mcfg_list);
>>>>
>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>> +
>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>> +{
>>>> +     int bus_num =3D root->secondary.start;
>>>> +     int domain =3D root->segment;
>>>> +     struct pci_cfg_fixup *f;
>>>> +
>>>> +     if (!mcfg_table)
>>>> +             return &pci_generic_ecam_ops;
>>>> +
>>>> +     /*
>>>> +      * Match against platform specific quirks and return correspondi=
ng
>>>> +      * CAM ops.
>>>> +      *
>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>> and
>>>> +      * OEM revision from MCFG table standard header.
>>>> +      */
>>>> +     for (f =3D __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> +             if ((f->domain =3D=3D domain || f->domain =3D=3D
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> +                 (f->bus_num =3D=3D bus_num || f->bus_num =3D=3D
>>>> PCI_MCFG_BUS_ANY) &&
>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>> +                 (!strncmp(f->oem_table_id,
>>>> mcfg_table->header.oem_table_id,
>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substring=
s
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
>>>> +                     return f->ops;
>>>> +     }
>>>> +     /* No quirks, use ECAM */
>>>> +     return &pci_generic_ecam_ops;
>>>> +}
>>>
>>>
>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>> index 7d63a66..088a1da 100644
>>>> --- a/include/linux/pci-acpi.h
>>>> +++ b/include/linux/pci-acpi.h
>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>
>>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>> *bus_res);
>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>> *root);
>>>>
>>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_de=
v
>>>> *pdev)
>>>>   {
>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>   };
>>>>
>>>> +struct pci_cfg_fixup {
>>>> +     struct pci_ecam_ops *ops;
>>>> +     char *oem_id;
>>>> +     char *oem_table_id;
>>>> +     int domain;
>>>> +     int bus_num;
>>>> +};
>>>> +
>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>> +
>>>> +/* Designate a routine to fix up buggy MCFG */
>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) =
\
>>>> +     static const struct pci_cfg_fixup                               =
\
>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   =
\
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first tw=
o
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             =
\
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>           __used __attribute__((__section__(".acpi_fixup_mcfg"),        =
 \
>>                                  aligned((sizeof(void *))))) =3D        =
   \
>>          { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the redefinition error when compiling mutiple
> DECLARE_ACPI_MCFG_FIXUP
> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>
> #define EFI_ACPI_HISI_OEM_ID "HISI"
> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
> include/linux/pci-acpi.h:98:43: error: redefinition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bu=
s\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>  ^
> include/linux/pci-acpi.h:98:43: note: previous definition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bu=
s\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>
>
> V2 fixup can resolve the redefinition error, but need to use macro.
> We can see that the name of macro is not replace with it's value in
> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_=
DOMAIN_ANYPCI_MCFG_BUS_ANY".
>
> Any good idea is appreciated.
Hmmm.

I was testing # op and using min_t to get the min-len when doing
strncmp similar to Chris' suggestion (using min_t avoids type
warnings)

/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
        static const struct pci_cfg_fixup
__mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =3D           \
        { ops, #oem_id, #oem_table_id, rev, dom, bus };

My fixup definition:
DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
                                               PCI_MCFG_DOMAIN_ANY,
PCI_MCFG_BUS_ANY);
My match condition is:
               if ((f->domain =3D=3D domain || f->domain =3D=3D PCI_MCFG_DO=
MAIN_ANY) &&
                   (f->bus_num =3D=3D bus_num || f->bus_num =3D=3D PCI_MCFG=
_BUS_ANY) &&
                   (!strncmp(f->oem_id, mcfg->header.oem_id,
                             min_t(size_t, strlen(f->oem_id),
                                   ACPI_OEM_ID_SIZE))) &&
                   (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
                             min_t(size_t, strlen(f->oem_table_id),
                                   ACPI_OEM_TABLE_ID_SIZE))) &&
                   (f->oem_revision =3D=3D mcfg->header.oem_revision)) {
                       return f->ops;
               }

But this still does not work for your case as having HISI-D02 as
oem_table_id will cause error.

>
> Thanks
> Dongdong
>
>>
>> Regards,
>> Duc Dang.
>>
>>
>>>    ^
>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>> =E2=80=98DECLARE_ACPI_MCFG_FIXUP=E2=80=99
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>   ^
>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>> does not give a valid preprocessing token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> =E2=80=98DECLARE_ACPI_MCFG_FIXUP=E2=80=99
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>> ng token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                                      ^
>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>> =E2=80=98DECLARE_ACPI_MCFG_FIXUP=E2=80=99
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                           ^
>>> arch/arm64/kernel/pci.c:225:44: error: expected =E2=80=98=3D=E2=80=99, =
=E2=80=98,=E2=80=99, =E2=80=98;=E2=80=99, =E2=80=98asm=E2=80=99 or
>>> =E2=80=98__attribute__=E2=80=99 before string constant
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> =E2=80=98DECLARE_ACPI_MCFG_FIXUP=E2=80=99
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>> make: *** [arch/arm64/kernel] Error 2
>>>
>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>
>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         =
\
>>>> +                             aligned((sizeof(void *))))) =3D         =
  \
>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>> +
>>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>> *info);
>>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>> *root,
>>>>                                            struct acpi_pci_root_ops
>>>> *ops,
>>>>
>>>
>>> Thanks,
>>> Cov
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>
>>
>> .
>>
>
Regards
Duc Dang.

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

在 2016/6/14 17:00, Duc Dang 写道:
> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
>> Hi Duc
>>
>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>> <cov@codeaurora.org> wrote:
>>>>
>>>> Hi Dongdong,
>>>>
>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>
>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>> index d3c3e85..49612b3 100644
>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>> @@ -22,6 +22,10 @@
>>>>>    #include <linux/kernel.h>
>>>>>    #include <linux/pci.h>
>>>>>    #include <linux/pci-acpi.h>
>>>>> +#include <linux/pci-ecam.h>
>>>>> +
>>>>> +/* Root pointer to the mapped MCFG table */
>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>
>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>    struct mcfg_entry {
>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>    /* List to save mcfg entries */
>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>
>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>> +
>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>> +{
>>>>> +     int bus_num = root->secondary.start;
>>>>> +     int domain = root->segment;
>>>>> +     struct pci_cfg_fixup *f;
>>>>> +
>>>>> +     if (!mcfg_table)
>>>>> +             return &pci_generic_ecam_ops;
>>>>> +
>>>>> +     /*
>>>>> +      * Match against platform specific quirks and return corresponding
>>>>> +      * CAM ops.
>>>>> +      *
>>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>>> and
>>>>> +      * OEM revision from MCFG table standard header.
>>>>> +      */
>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> +             if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>> +                 (!strncmp(f->oem_table_id,
>>>>> mcfg_table->header.oem_table_id,
>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>
>>>>
>>>> This would just be a small convenience, but if the character count used
>>>> here were
>>>>
>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>
>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>>> and
>>>> wouldn't need to be padded out to the full length.
>>>>
>>>>> +                     return f->ops;
>>>>> +     }
>>>>> +     /* No quirks, use ECAM */
>>>>> +     return &pci_generic_ecam_ops;
>>>>> +}
>>>>
>>>>
>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>> index 7d63a66..088a1da 100644
>>>>> --- a/include/linux/pci-acpi.h
>>>>> +++ b/include/linux/pci-acpi.h
>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>>
>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>> *bus_res);
>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>> *root);
>>>>>
>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>>> *pdev)
>>>>>    {
>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>    };
>>>>>
>>>>> +struct pci_cfg_fixup {
>>>>> +     struct pci_ecam_ops *ops;
>>>>> +     char *oem_id;
>>>>> +     char *oem_table_id;
>>>>> +     int domain;
>>>>> +     int bus_num;
>>>>> +};
>>>>> +
>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>> +
>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>>> +     static const struct pci_cfg_fixup                               \
>>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>
>>>>
>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>> following a GCC documentation suggestion [1]--but removing the first two
>>>> preprocessor concatenation operators "##" solved the following build
>>>> error
>>>> for me.
>>>>
>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>> ""QCOM"" does not give a valid preprocessing token
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>
>>>
>>> I think the problem is gcc is not happy with quoted string when
>>> processing these tokens
>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>> string tokens and
>>> use the fixup definition in v1 of this RFC:
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>            __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                   aligned((sizeof(void *))))) =           \
>>>           { ops, oem_id, rev, dom, bus };
>>
>>
>> V1 fixup exist the redefinition error when compiling mutiple
>> DECLARE_ACPI_MCFG_FIXUP
>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>
>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>> include/linux/pci-acpi.h:98:43: error: redefinition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>   ^
>> include/linux/pci-acpi.h:98:43: note: previous definition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>
>>
>> V2 fixup can resolve the redefinition error, but need to use macro.
>> We can see that the name of macro is not replace with it's value in
>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>
>> Any good idea is appreciated.
> Hmmm.
>
> I was testing # op and using min_t to get the min-len when doing
> strncmp similar to Chris' suggestion (using min_t avoids type
> warnings)
>
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
>          static const struct pci_cfg_fixup
> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \

>          { ops, #oem_id, #oem_table_id, rev, dom, bus };


This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
‘#’ is not need.

>
> My fixup definition:
> DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
>                                                 PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
> My match condition is:
>                 if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>                     (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>                     (!strncmp(f->oem_id, mcfg->header.oem_id,
>                               min_t(size_t, strlen(f->oem_id),
>                                     ACPI_OEM_ID_SIZE))) &&
>                     (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
>                               min_t(size_t, strlen(f->oem_table_id),
>                                     ACPI_OEM_TABLE_ID_SIZE))) &&
>                     (f->oem_revision == mcfg->header.oem_revision)) {
>                         return f->ops;
>                 }
>
> But this still does not work for your case as having HISI-D02 as
> oem_table_id will cause error.

In my case, I have tested  and it worked ok.
Could you show the detail error information that you met?

Thanks
Dongdong
>
>>
>> Thanks
>> Dongdong
>>
>>>
>>> Regards,
>>> Duc Dang.
>>>
>>>
>>>>     ^
>>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>    ^
>>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>>> does not give a valid preprocessing token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>>> ng token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                                       ^
>>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                            ^
>>>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>>> ‘__attribute__’ before string constant
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>>> make: *** [arch/arm64/kernel] Error 2
>>>>
>>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>>
>>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>> +                             aligned((sizeof(void *))))) =           \
>>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>>> +
>>>>>    extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>>> *info);
>>>>>    extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>>> *root,
>>>>>                                             struct acpi_pci_root_ops
>>>>> *ops,
>>>>>
>>>>
>>>> Thanks,
>>>> Cov
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>> a Linux Foundation Collaborative Project
>>>
>>>
>>> .
>>>
>>
> Regards
> Duc Dang.
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

在 2016/6/14 17:00, Duc Dang 写道:
> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
>> Hi Duc
>>
>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>> <cov@codeaurora.org> wrote:
>>>>
>>>> Hi Dongdong,
>>>>
>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>
>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>> index d3c3e85..49612b3 100644
>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>> @@ -22,6 +22,10 @@
>>>>>    #include <linux/kernel.h>
>>>>>    #include <linux/pci.h>
>>>>>    #include <linux/pci-acpi.h>
>>>>> +#include <linux/pci-ecam.h>
>>>>> +
>>>>> +/* Root pointer to the mapped MCFG table */
>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>
>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>    struct mcfg_entry {
>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>    /* List to save mcfg entries */
>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>
>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>> +
>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>> +{
>>>>> +     int bus_num = root->secondary.start;
>>>>> +     int domain = root->segment;
>>>>> +     struct pci_cfg_fixup *f;
>>>>> +
>>>>> +     if (!mcfg_table)
>>>>> +             return &pci_generic_ecam_ops;
>>>>> +
>>>>> +     /*
>>>>> +      * Match against platform specific quirks and return corresponding
>>>>> +      * CAM ops.
>>>>> +      *
>>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>>> and
>>>>> +      * OEM revision from MCFG table standard header.
>>>>> +      */
>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> +             if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>> +                 (!strncmp(f->oem_table_id,
>>>>> mcfg_table->header.oem_table_id,
>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>
>>>>
>>>> This would just be a small convenience, but if the character count used
>>>> here were
>>>>
>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>
>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>>> and
>>>> wouldn't need to be padded out to the full length.
>>>>
>>>>> +                     return f->ops;
>>>>> +     }
>>>>> +     /* No quirks, use ECAM */
>>>>> +     return &pci_generic_ecam_ops;
>>>>> +}
>>>>
>>>>
>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>> index 7d63a66..088a1da 100644
>>>>> --- a/include/linux/pci-acpi.h
>>>>> +++ b/include/linux/pci-acpi.h
>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>>
>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>> *bus_res);
>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>> *root);
>>>>>
>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>>> *pdev)
>>>>>    {
>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>    };
>>>>>
>>>>> +struct pci_cfg_fixup {
>>>>> +     struct pci_ecam_ops *ops;
>>>>> +     char *oem_id;
>>>>> +     char *oem_table_id;
>>>>> +     int domain;
>>>>> +     int bus_num;
>>>>> +};
>>>>> +
>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>> +
>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>>> +     static const struct pci_cfg_fixup                               \
>>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>
>>>>
>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>> following a GCC documentation suggestion [1]--but removing the first two
>>>> preprocessor concatenation operators "##" solved the following build
>>>> error
>>>> for me.
>>>>
>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>> ""QCOM"" does not give a valid preprocessing token
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>
>>>
>>> I think the problem is gcc is not happy with quoted string when
>>> processing these tokens
>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>> string tokens and
>>> use the fixup definition in v1 of this RFC:
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>            __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                   aligned((sizeof(void *))))) =           \
>>>           { ops, oem_id, rev, dom, bus };
>>
>>
>> V1 fixup exist the redefinition error when compiling mutiple
>> DECLARE_ACPI_MCFG_FIXUP
>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>
>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>> include/linux/pci-acpi.h:98:43: error: redefinition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>   ^
>> include/linux/pci-acpi.h:98:43: note: previous definition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>
>>
>> V2 fixup can resolve the redefinition error, but need to use macro.
>> We can see that the name of macro is not replace with it's value in
>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>
>> Any good idea is appreciated.
> Hmmm.
>
> I was testing # op and using min_t to get the min-len when doing
> strncmp similar to Chris' suggestion (using min_t avoids type
> warnings)
>
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
>          static const struct pci_cfg_fixup
> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \

>          { ops, #oem_id, #oem_table_id, rev, dom, bus };


This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
‘#’ is not need.

>
> My fixup definition:
> DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
>                                                 PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
> My match condition is:
>                 if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>                     (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>                     (!strncmp(f->oem_id, mcfg->header.oem_id,
>                               min_t(size_t, strlen(f->oem_id),
>                                     ACPI_OEM_ID_SIZE))) &&
>                     (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
>                               min_t(size_t, strlen(f->oem_table_id),
>                                     ACPI_OEM_TABLE_ID_SIZE))) &&
>                     (f->oem_revision == mcfg->header.oem_revision)) {
>                         return f->ops;
>                 }
>
> But this still does not work for your case as having HISI-D02 as
> oem_table_id will cause error.

In my case, I have tested  and it worked ok.
Could you show the detail error information that you met?

Thanks
Dongdong
>
>>
>> Thanks
>> Dongdong
>>
>>>
>>> Regards,
>>> Duc Dang.
>>>
>>>
>>>>     ^
>>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>    ^
>>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>>> does not give a valid preprocessing token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>>> ng token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                                       ^
>>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                            ^
>>>> arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>>> ‘__attribute__’ before string constant
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ‘DECLARE_ACPI_MCFG_FIXUP’
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>>> make: *** [arch/arm64/kernel] Error 2
>>>>
>>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>>
>>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>> +                             aligned((sizeof(void *))))) =           \
>>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>>> +
>>>>>    extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>>> *info);
>>>>>    extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>>> *root,
>>>>>                                             struct acpi_pci_root_ops
>>>>> *ops,
>>>>>
>>>>
>>>> Thanks,
>>>> Cov
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>> a Linux Foundation Collaborative Project
>>>
>>>
>>> .
>>>
>>
> Regards
> Duc Dang.
>
> .
>

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Dongdong Liu]

Hi Duc

? 2016/6/14 17:00, Duc Dang ??:
> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
>> Hi Duc
>>
>> ? 2016/6/14 4:57, Duc Dang ??:
>>>
>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>> <cov@codeaurora.org> wrote:
>>>>
>>>> Hi Dongdong,
>>>>
>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>
>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>> index d3c3e85..49612b3 100644
>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>> @@ -22,6 +22,10 @@
>>>>>    #include <linux/kernel.h>
>>>>>    #include <linux/pci.h>
>>>>>    #include <linux/pci-acpi.h>
>>>>> +#include <linux/pci-ecam.h>
>>>>> +
>>>>> +/* Root pointer to the mapped MCFG table */
>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>
>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>    struct mcfg_entry {
>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>    /* List to save mcfg entries */
>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>
>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>> +
>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>> +{
>>>>> +     int bus_num = root->secondary.start;
>>>>> +     int domain = root->segment;
>>>>> +     struct pci_cfg_fixup *f;
>>>>> +
>>>>> +     if (!mcfg_table)
>>>>> +             return &pci_generic_ecam_ops;
>>>>> +
>>>>> +     /*
>>>>> +      * Match against platform specific quirks and return corresponding
>>>>> +      * CAM ops.
>>>>> +      *
>>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>>> and
>>>>> +      * OEM revision from MCFG table standard header.
>>>>> +      */
>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> +             if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>> +                 (!strncmp(f->oem_table_id,
>>>>> mcfg_table->header.oem_table_id,
>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>
>>>>
>>>> This would just be a small convenience, but if the character count used
>>>> here were
>>>>
>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>
>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>>> and
>>>> wouldn't need to be padded out to the full length.
>>>>
>>>>> +                     return f->ops;
>>>>> +     }
>>>>> +     /* No quirks, use ECAM */
>>>>> +     return &pci_generic_ecam_ops;
>>>>> +}
>>>>
>>>>
>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>> index 7d63a66..088a1da 100644
>>>>> --- a/include/linux/pci-acpi.h
>>>>> +++ b/include/linux/pci-acpi.h
>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>>
>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>> *bus_res);
>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>> *root);
>>>>>
>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>>> *pdev)
>>>>>    {
>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>    };
>>>>>
>>>>> +struct pci_cfg_fixup {
>>>>> +     struct pci_ecam_ops *ops;
>>>>> +     char *oem_id;
>>>>> +     char *oem_table_id;
>>>>> +     int domain;
>>>>> +     int bus_num;
>>>>> +};
>>>>> +
>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>> +
>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>>> +     static const struct pci_cfg_fixup                               \
>>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>
>>>>
>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>> following a GCC documentation suggestion [1]--but removing the first two
>>>> preprocessor concatenation operators "##" solved the following build
>>>> error
>>>> for me.
>>>>
>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>> ""QCOM"" does not give a valid preprocessing token
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>
>>>
>>> I think the problem is gcc is not happy with quoted string when
>>> processing these tokens
>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>> string tokens and
>>> use the fixup definition in v1 of this RFC:
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>            __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                   aligned((sizeof(void *))))) =           \
>>>           { ops, oem_id, rev, dom, bus };
>>
>>
>> V1 fixup exist the redefinition error when compiling mutiple
>> DECLARE_ACPI_MCFG_FIXUP
>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>
>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>> PCI_MCFG_BUS_ANY);
>>
>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>> include/linux/pci-acpi.h:98:43: error: redefinition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>   ^
>> include/linux/pci-acpi.h:98:43: note: previous definition of
>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>           static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>>                                             ^
>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>> 'DECLARE_ACPI_MCFG_FIXUP'
>>
>>
>> V2 fixup can resolve the redefinition error, but need to use macro.
>> We can see that the name of macro is not replace with it's value in
>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>
>> Any good idea is appreciated.
> Hmmm.
>
> I was testing # op and using min_t to get the min-len when doing
> strncmp similar to Chris' suggestion (using min_t avoids type
> warnings)
>
> /* Designate a routine to fix up buggy MCFG */
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
>          static const struct pci_cfg_fixup
> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                  aligned((sizeof(void *))))) =           \

>          { ops, #oem_id, #oem_table_id, rev, dom, bus };


This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
?#? is not need.

>
> My fixup definition:
> DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
>                                                 PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
> My match condition is:
>                 if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>                     (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>                     (!strncmp(f->oem_id, mcfg->header.oem_id,
>                               min_t(size_t, strlen(f->oem_id),
>                                     ACPI_OEM_ID_SIZE))) &&
>                     (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
>                               min_t(size_t, strlen(f->oem_table_id),
>                                     ACPI_OEM_TABLE_ID_SIZE))) &&
>                     (f->oem_revision == mcfg->header.oem_revision)) {
>                         return f->ops;
>                 }
>
> But this still does not work for your case as having HISI-D02 as
> oem_table_id will cause error.

In my case, I have tested  and it worked ok.
Could you show the detail error information that you met?

Thanks
Dongdong
>
>>
>> Thanks
>> Dongdong
>>
>>>
>>> Regards,
>>> Duc Dang.
>>>
>>>
>>>>     ^
>>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>    ^
>>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>>> does not give a valid preprocessing token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>>> ng token
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                                       ^
>>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                            ^
>>>> arch/arm64/kernel/pci.c:225:44: error: expected ?=?, ?,?, ?;?, ?asm? or
>>>> ?__attribute__? before string constant
>>>>    DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>>                                               ^
>>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>                    ^
>>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>>> make: *** [arch/arm64/kernel] Error 2
>>>>
>>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>>
>>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>> +                             aligned((sizeof(void *))))) =           \
>>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>>> +
>>>>>    extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>>> *info);
>>>>>    extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>>> *root,
>>>>>                                             struct acpi_pci_root_ops
>>>>> *ops,
>>>>>
>>>>
>>>> Thanks,
>>>> Cov
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>> a Linux Foundation Collaborative Project
>>>
>>>
>>> .
>>>
>>
> Regards
> Duc Dang.
>
> .
>

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Tomasz Nowicki]

On 14.06.2016 11:45, Dongdong Liu wrote:
> Hi Duc
>
> 在 2016/6/14 17:00, Duc Dang 写道:
>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>> <liudongdong3@huawei.com> wrote:
>>> Hi Duc
>>>
>>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>>
>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>> <cov@codeaurora.org> wrote:
>>>>>
>>>>> Hi Dongdong,
>>>>>
>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>
>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>> index d3c3e85..49612b3 100644
>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>> @@ -22,6 +22,10 @@
>>>>>>    #include <linux/kernel.h>
>>>>>>    #include <linux/pci.h>
>>>>>>    #include <linux/pci-acpi.h>
>>>>>> +#include <linux/pci-ecam.h>
>>>>>> +
>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>
>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>    struct mcfg_entry {
>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>    /* List to save mcfg entries */
>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>
>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>> +
>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>> +{
>>>>>> +     int bus_num = root->secondary.start;
>>>>>> +     int domain = root->segment;
>>>>>> +     struct pci_cfg_fixup *f;
>>>>>> +
>>>>>> +     if (!mcfg_table)
>>>>>> +             return &pci_generic_ecam_ops;
>>>>>> +
>>>>>> +     /*
>>>>>> +      * Match against platform specific quirks and return
>>>>>> corresponding
>>>>>> +      * CAM ops.
>>>>>> +      *
>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>> OEM ID
>>>>>> and
>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>> +      */
>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>> f++) {
>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>> mcfg_table->header.oem_table_id,
>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>
>>>>>
>>>>> This would just be a small convenience, but if the character count
>>>>> used
>>>>> here were
>>>>>
>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>
>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>> substrings
>>>>> and
>>>>> wouldn't need to be padded out to the full length.
>>>>>
>>>>>> +                     return f->ops;
>>>>>> +     }
>>>>>> +     /* No quirks, use ECAM */
>>>>>> +     return &pci_generic_ecam_ops;
>>>>>> +}
>>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>> index 7d63a66..088a1da 100644
>>>>>> --- a/include/linux/pci-acpi.h
>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>> handle);
>>>>>>
>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>> *bus_res);
>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>> *root);
>>>>>>
>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>> pci_dev
>>>>>> *pdev)
>>>>>>    {
>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>    };
>>>>>>
>>>>>> +struct pci_cfg_fixup {
>>>>>> +     struct pci_ecam_ops *ops;
>>>>>> +     char *oem_id;
>>>>>> +     char *oem_table_id;
>>>>>> +     int domain;
>>>>>> +     int bus_num;
>>>>>> +};
>>>>>> +
>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>> +
>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>> bus) \
>>>>>> +     static const struct
>>>>>> pci_cfg_fixup                               \
>>>>>> +
>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>
>>>>>
>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>> first two
>>>>> preprocessor concatenation operators "##" solved the following build
>>>>> error
>>>>> for me.
>>>>>
>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>
>>>>
>>>> I think the problem is gcc is not happy with quoted string when
>>>> processing these tokens
>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>> string tokens and
>>>> use the fixup definition in v1 of this RFC:
>>>> /* Designate a routine to fix up buggy MCFG */
>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>> bus)             \
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>            __used
>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>                                   aligned((sizeof(void *)))))
>>>> =           \
>>>>           { ops, oem_id, rev, dom, bus };
>>>
>>>
>>> V1 fixup exist the redefinition error when compiling mutiple
>>> DECLARE_ACPI_MCFG_FIXUP
>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>
>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>   ^
>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>
>>>
>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>> We can see that the name of macro is not replace with it's value in
>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>
>>>
>>> Any good idea is appreciated.
>> Hmmm.
>>
>> I was testing # op and using min_t to get the min-len when doing
>> strncmp similar to Chris' suggestion (using min_t avoids type
>> warnings)
>>
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>> bus) \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>           __used
>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *)))))
>> =           \
>
>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
>
> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
> ‘#’ is not need.

Both solutions are OK.

1. This works when we use macros as OEM ID and OEM table ID:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
	static const struct pci_cfg_fixup				\
		__mcfg_fixup_##oem_id##oem_table_id##dom##bus		\
	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
				aligned((sizeof(void *))))) =		\
	{ ops, oem_id, oem_table_id, rev, dom, bus };

#define OEM_ID "XXXXXX"
#define OEM_TABLE_ID "YYYYYYYY"

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

2. This works w/o macro which means we need to define OEM ID and OEM as 
string w/o quotation marks:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
static const struct pci_cfg_fixup \
__mcfg_fixup_##oem_id##oem_table_id##dom##bus \
__used __attribute__((__section__(".acpi_fixup_mcfg"), \
aligned((sizeof(void *))))) = \
{ ops, #oem_id, #oem_table_id, rev, dom, bus };

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

Personally I think that (2) is better, no need for macro definitions.
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Tomasz Nowicki]

On 14.06.2016 11:45, Dongdong Liu wrote:
> Hi Duc
>
> 在 2016/6/14 17:00, Duc Dang 写道:
>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>> <liudongdong3@huawei.com> wrote:
>>> Hi Duc
>>>
>>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>>
>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>> <cov@codeaurora.org> wrote:
>>>>>
>>>>> Hi Dongdong,
>>>>>
>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>
>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>> index d3c3e85..49612b3 100644
>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>> @@ -22,6 +22,10 @@
>>>>>>    #include <linux/kernel.h>
>>>>>>    #include <linux/pci.h>
>>>>>>    #include <linux/pci-acpi.h>
>>>>>> +#include <linux/pci-ecam.h>
>>>>>> +
>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>
>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>    struct mcfg_entry {
>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>    /* List to save mcfg entries */
>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>
>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>> +
>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>> +{
>>>>>> +     int bus_num = root->secondary.start;
>>>>>> +     int domain = root->segment;
>>>>>> +     struct pci_cfg_fixup *f;
>>>>>> +
>>>>>> +     if (!mcfg_table)
>>>>>> +             return &pci_generic_ecam_ops;
>>>>>> +
>>>>>> +     /*
>>>>>> +      * Match against platform specific quirks and return
>>>>>> corresponding
>>>>>> +      * CAM ops.
>>>>>> +      *
>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>> OEM ID
>>>>>> and
>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>> +      */
>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>> f++) {
>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>> mcfg_table->header.oem_table_id,
>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>
>>>>>
>>>>> This would just be a small convenience, but if the character count
>>>>> used
>>>>> here were
>>>>>
>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>
>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>> substrings
>>>>> and
>>>>> wouldn't need to be padded out to the full length.
>>>>>
>>>>>> +                     return f->ops;
>>>>>> +     }
>>>>>> +     /* No quirks, use ECAM */
>>>>>> +     return &pci_generic_ecam_ops;
>>>>>> +}
>>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>> index 7d63a66..088a1da 100644
>>>>>> --- a/include/linux/pci-acpi.h
>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>> handle);
>>>>>>
>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>> *bus_res);
>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>> *root);
>>>>>>
>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>> pci_dev
>>>>>> *pdev)
>>>>>>    {
>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>    };
>>>>>>
>>>>>> +struct pci_cfg_fixup {
>>>>>> +     struct pci_ecam_ops *ops;
>>>>>> +     char *oem_id;
>>>>>> +     char *oem_table_id;
>>>>>> +     int domain;
>>>>>> +     int bus_num;
>>>>>> +};
>>>>>> +
>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>> +
>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>> bus) \
>>>>>> +     static const struct
>>>>>> pci_cfg_fixup                               \
>>>>>> +
>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>
>>>>>
>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>> first two
>>>>> preprocessor concatenation operators "##" solved the following build
>>>>> error
>>>>> for me.
>>>>>
>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>
>>>>
>>>> I think the problem is gcc is not happy with quoted string when
>>>> processing these tokens
>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>> string tokens and
>>>> use the fixup definition in v1 of this RFC:
>>>> /* Designate a routine to fix up buggy MCFG */
>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>> bus)             \
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>            __used
>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>                                   aligned((sizeof(void *)))))
>>>> =           \
>>>>           { ops, oem_id, rev, dom, bus };
>>>
>>>
>>> V1 fixup exist the redefinition error when compiling mutiple
>>> DECLARE_ACPI_MCFG_FIXUP
>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>
>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>   ^
>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>
>>>
>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>> We can see that the name of macro is not replace with it's value in
>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>
>>>
>>> Any good idea is appreciated.
>> Hmmm.
>>
>> I was testing # op and using min_t to get the min-len when doing
>> strncmp similar to Chris' suggestion (using min_t avoids type
>> warnings)
>>
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>> bus) \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>           __used
>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *)))))
>> =           \
>
>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
>
> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
> ‘#’ is not need.

Both solutions are OK.

1. This works when we use macros as OEM ID and OEM table ID:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
	static const struct pci_cfg_fixup				\
		__mcfg_fixup_##oem_id##oem_table_id##dom##bus		\
	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
				aligned((sizeof(void *))))) =		\
	{ ops, oem_id, oem_table_id, rev, dom, bus };

#define OEM_ID "XXXXXX"
#define OEM_TABLE_ID "YYYYYYYY"

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

2. This works w/o macro which means we need to define OEM ID and OEM as 
string w/o quotation marks:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
static const struct pci_cfg_fixup \
__mcfg_fixup_##oem_id##oem_table_id##dom##bus \
__used __attribute__((__section__(".acpi_fixup_mcfg"), \
aligned((sizeof(void *))))) = \
{ ops, #oem_id, #oem_table_id, rev, dom, bus };

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

Personally I think that (2) is better, no need for macro definitions.
Tomasz

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Tomasz Nowicki]

On 14.06.2016 11:45, Dongdong Liu wrote:
> Hi Duc
>
> ? 2016/6/14 17:00, Duc Dang ??:
>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>> <liudongdong3@huawei.com> wrote:
>>> Hi Duc
>>>
>>> ? 2016/6/14 4:57, Duc Dang ??:
>>>>
>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>> <cov@codeaurora.org> wrote:
>>>>>
>>>>> Hi Dongdong,
>>>>>
>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>
>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>> index d3c3e85..49612b3 100644
>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>> @@ -22,6 +22,10 @@
>>>>>>    #include <linux/kernel.h>
>>>>>>    #include <linux/pci.h>
>>>>>>    #include <linux/pci-acpi.h>
>>>>>> +#include <linux/pci-ecam.h>
>>>>>> +
>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>
>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>    struct mcfg_entry {
>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>    /* List to save mcfg entries */
>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>
>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>> +
>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>> +{
>>>>>> +     int bus_num = root->secondary.start;
>>>>>> +     int domain = root->segment;
>>>>>> +     struct pci_cfg_fixup *f;
>>>>>> +
>>>>>> +     if (!mcfg_table)
>>>>>> +             return &pci_generic_ecam_ops;
>>>>>> +
>>>>>> +     /*
>>>>>> +      * Match against platform specific quirks and return
>>>>>> corresponding
>>>>>> +      * CAM ops.
>>>>>> +      *
>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>> OEM ID
>>>>>> and
>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>> +      */
>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>> f++) {
>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>> mcfg_table->header.oem_table_id,
>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>
>>>>>
>>>>> This would just be a small convenience, but if the character count
>>>>> used
>>>>> here were
>>>>>
>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>
>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>> substrings
>>>>> and
>>>>> wouldn't need to be padded out to the full length.
>>>>>
>>>>>> +                     return f->ops;
>>>>>> +     }
>>>>>> +     /* No quirks, use ECAM */
>>>>>> +     return &pci_generic_ecam_ops;
>>>>>> +}
>>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>> index 7d63a66..088a1da 100644
>>>>>> --- a/include/linux/pci-acpi.h
>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>> handle);
>>>>>>
>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>> *bus_res);
>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>> *root);
>>>>>>
>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>> pci_dev
>>>>>> *pdev)
>>>>>>    {
>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>    };
>>>>>>
>>>>>> +struct pci_cfg_fixup {
>>>>>> +     struct pci_ecam_ops *ops;
>>>>>> +     char *oem_id;
>>>>>> +     char *oem_table_id;
>>>>>> +     int domain;
>>>>>> +     int bus_num;
>>>>>> +};
>>>>>> +
>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>> +
>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>> bus) \
>>>>>> +     static const struct
>>>>>> pci_cfg_fixup                               \
>>>>>> +
>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>
>>>>>
>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>> first two
>>>>> preprocessor concatenation operators "##" solved the following build
>>>>> error
>>>>> for me.
>>>>>
>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>
>>>>
>>>> I think the problem is gcc is not happy with quoted string when
>>>> processing these tokens
>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>> string tokens and
>>>> use the fixup definition in v1 of this RFC:
>>>> /* Designate a routine to fix up buggy MCFG */
>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>> bus)             \
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>            __used
>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>                                   aligned((sizeof(void *)))))
>>>> =           \
>>>>           { ops, oem_id, rev, dom, bus };
>>>
>>>
>>> V1 fixup exist the redefinition error when compiling mutiple
>>> DECLARE_ACPI_MCFG_FIXUP
>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>
>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>> PCI_MCFG_BUS_ANY);
>>>
>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>   ^
>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>           static const struct pci_cfg_fixup
>>> __mcfg_fixup_##system##dom##bus\
>>>                                             ^
>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>
>>>
>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>> We can see that the name of macro is not replace with it's value in
>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>
>>>
>>> Any good idea is appreciated.
>> Hmmm.
>>
>> I was testing # op and using min_t to get the min-len when doing
>> strncmp similar to Chris' suggestion (using min_t avoids type
>> warnings)
>>
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>> bus) \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>           __used
>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *)))))
>> =           \
>
>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
>
> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
> ?#? is not need.

Both solutions are OK.

1. This works when we use macros as OEM ID and OEM table ID:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
	static const struct pci_cfg_fixup				\
		__mcfg_fixup_##oem_id##oem_table_id##dom##bus		\
	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
				aligned((sizeof(void *))))) =		\
	{ ops, oem_id, oem_table_id, rev, dom, bus };

#define OEM_ID "XXXXXX"
#define OEM_TABLE_ID "YYYYYYYY"

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

2. This works w/o macro which means we need to define OEM ID and OEM as 
string w/o quotation marks:

#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
static const struct pci_cfg_fixup \
__mcfg_fixup_##oem_id##oem_table_id##dom##bus \
__used __attribute__((__section__(".acpi_fixup_mcfg"), \
aligned((sizeof(void *))))) = \
{ ops, #oem_id, #oem_table_id, rev, dom, bus };

DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1, 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

Personally I think that (2) is better, no need for macro definitions.
Tomasz

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki <tn@semihalf.com> wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> 在 2016/6/14 17:00, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>> <liudongdong3@huawei.com> wrote:
>>>>
>>>> Hi Duc
>>>>
>>>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>>> <cov@codeaurora.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Dongdong,
>>>>>>
>>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index d3c3e85..49612b3 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -22,6 +22,10 @@
>>>>>>>    #include <linux/kernel.h>
>>>>>>>    #include <linux/pci.h>
>>>>>>>    #include <linux/pci-acpi.h>
>>>>>>> +#include <linux/pci-ecam.h>
>>>>>>> +
>>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>>
>>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>>    struct mcfg_entry {
>>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>>    /* List to save mcfg entries */
>>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>>
>>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>>> +
>>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>>> +{
>>>>>>> +     int bus_num = root->secondary.start;
>>>>>>> +     int domain = root->segment;
>>>>>>> +     struct pci_cfg_fixup *f;
>>>>>>> +
>>>>>>> +     if (!mcfg_table)
>>>>>>> +             return &pci_generic_ecam_ops;
>>>>>>> +
>>>>>>> +     /*
>>>>>>> +      * Match against platform specific quirks and return
>>>>>>> corresponding
>>>>>>> +      * CAM ops.
>>>>>>> +      *
>>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>>> OEM ID
>>>>>>> and
>>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>>> +      */
>>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>>> f++) {
>>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>>> mcfg_table->header.oem_table_id,
>>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>>
>>>>>>
>>>>>>
>>>>>> This would just be a small convenience, but if the character count
>>>>>> used
>>>>>> here were
>>>>>>
>>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>>
>>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>>> substrings
>>>>>> and
>>>>>> wouldn't need to be padded out to the full length.
>>>>>>
>>>>>>> +                     return f->ops;
>>>>>>> +     }
>>>>>>> +     /* No quirks, use ECAM */
>>>>>>> +     return &pci_generic_ecam_ops;
>>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>>> index 7d63a66..088a1da 100644
>>>>>>> --- a/include/linux/pci-acpi.h
>>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>>> handle);
>>>>>>>
>>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>>> *bus_res);
>>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>>> *root);
>>>>>>>
>>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>>> pci_dev
>>>>>>> *pdev)
>>>>>>>    {
>>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>>    };
>>>>>>>
>>>>>>> +struct pci_cfg_fixup {
>>>>>>> +     struct pci_ecam_ops *ops;
>>>>>>> +     char *oem_id;
>>>>>>> +     char *oem_table_id;
>>>>>>> +     int domain;
>>>>>>> +     int bus_num;
>>>>>>> +};
>>>>>>> +
>>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>>> +
>>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>>> bus) \
>>>>>>> +     static const struct
>>>>>>> pci_cfg_fixup                               \
>>>>>>> +
>>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>>> first two
>>>>>> preprocessor concatenation operators "##" solved the following build
>>>>>> error
>>>>>> for me.
>>>>>>
>>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>>
>>>>>
>>>>>
>>>>> I think the problem is gcc is not happy with quoted string when
>>>>> processing these tokens
>>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>>> string tokens and
>>>>> use the fixup definition in v1 of this RFC:
>>>>> /* Designate a routine to fix up buggy MCFG */
>>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>>> bus)             \
>>>>>           static const struct pci_cfg_fixup
>>>>> __mcfg_fixup_##system##dom##bus\
>>>>>            __used
>>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>>                                   aligned((sizeof(void *)))))
>>>>> =           \
>>>>>           { ops, oem_id, rev, dom, bus };
>>>>
>>>>
>>>>
>>>> V1 fixup exist the redefinition error when compiling mutiple
>>>> DECLARE_ACPI_MCFG_FIXUP
>>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>>
>>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>   ^
>>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>
>>>>
>>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>>> We can see that the name of macro is not replace with it's value in
>>>>
>>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>>
>>>>
>>>> Any good idea is appreciated.
>>>
>>> Hmmm.
>>>
>>> I was testing # op and using min_t to get the min-len when doing
>>> strncmp similar to Chris' suggestion (using min_t avoids type
>>> warnings)
>>>
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>>> bus) \
>>>          static const struct pci_cfg_fixup
>>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>>           __used
>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                  aligned((sizeof(void *)))))
>>> =           \
>>
>>
>>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>>
>>
>>
>> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
>> ‘#’ is not need.
>
>
> Both solutions are OK.
>
> 1. This works when we use macros as OEM ID and OEM table ID:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
>         static const struct pci_cfg_fixup                               \
>                 __mcfg_fixup_##oem_id##oem_table_id##dom##bus           \
>          __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                 aligned((sizeof(void *))))) =           \
>         { ops, oem_id, oem_table_id, rev, dom, bus };
>
> #define OEM_ID "XXXXXX"
> #define OEM_TABLE_ID "YYYYYYYY"
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>
> 2. This works w/o macro which means we need to define OEM ID and OEM as
> string w/o quotation marks:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
> static const struct pci_cfg_fixup \
> __mcfg_fixup_##oem_id##oem_table_id##dom##bus \
> __used __attribute__((__section__(".acpi_fixup_mcfg"), \
> aligned((sizeof(void *))))) = \
> { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In case of oem_id and oem_table_id have special characters ("HISI-D02"
as an example), #2 will have problem unless we use macro definitions
for them.

>
> Personally I think that (2) is better, no need for macro definitions.
> Tomasz
Regards,
Duc Dang
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki <tn@semihalf.com> wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> 在 2016/6/14 17:00, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>> <liudongdong3@huawei.com> wrote:
>>>>
>>>> Hi Duc
>>>>
>>>> 在 2016/6/14 4:57, Duc Dang 写道:
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>>> <cov@codeaurora.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Dongdong,
>>>>>>
>>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index d3c3e85..49612b3 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -22,6 +22,10 @@
>>>>>>>    #include <linux/kernel.h>
>>>>>>>    #include <linux/pci.h>
>>>>>>>    #include <linux/pci-acpi.h>
>>>>>>> +#include <linux/pci-ecam.h>
>>>>>>> +
>>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>>
>>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>>    struct mcfg_entry {
>>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>>    /* List to save mcfg entries */
>>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>>
>>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>>> +
>>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>>> +{
>>>>>>> +     int bus_num = root->secondary.start;
>>>>>>> +     int domain = root->segment;
>>>>>>> +     struct pci_cfg_fixup *f;
>>>>>>> +
>>>>>>> +     if (!mcfg_table)
>>>>>>> +             return &pci_generic_ecam_ops;
>>>>>>> +
>>>>>>> +     /*
>>>>>>> +      * Match against platform specific quirks and return
>>>>>>> corresponding
>>>>>>> +      * CAM ops.
>>>>>>> +      *
>>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>>> OEM ID
>>>>>>> and
>>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>>> +      */
>>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>>> f++) {
>>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>>> mcfg_table->header.oem_table_id,
>>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>>
>>>>>>
>>>>>>
>>>>>> This would just be a small convenience, but if the character count
>>>>>> used
>>>>>> here were
>>>>>>
>>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>>
>>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>>> substrings
>>>>>> and
>>>>>> wouldn't need to be padded out to the full length.
>>>>>>
>>>>>>> +                     return f->ops;
>>>>>>> +     }
>>>>>>> +     /* No quirks, use ECAM */
>>>>>>> +     return &pci_generic_ecam_ops;
>>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>>> index 7d63a66..088a1da 100644
>>>>>>> --- a/include/linux/pci-acpi.h
>>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>>> handle);
>>>>>>>
>>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>>> *bus_res);
>>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>>> *root);
>>>>>>>
>>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>>> pci_dev
>>>>>>> *pdev)
>>>>>>>    {
>>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>>    };
>>>>>>>
>>>>>>> +struct pci_cfg_fixup {
>>>>>>> +     struct pci_ecam_ops *ops;
>>>>>>> +     char *oem_id;
>>>>>>> +     char *oem_table_id;
>>>>>>> +     int domain;
>>>>>>> +     int bus_num;
>>>>>>> +};
>>>>>>> +
>>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>>> +
>>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>>> bus) \
>>>>>>> +     static const struct
>>>>>>> pci_cfg_fixup                               \
>>>>>>> +
>>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>>> first two
>>>>>> preprocessor concatenation operators "##" solved the following build
>>>>>> error
>>>>>> for me.
>>>>>>
>>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>>
>>>>>
>>>>>
>>>>> I think the problem is gcc is not happy with quoted string when
>>>>> processing these tokens
>>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>>> string tokens and
>>>>> use the fixup definition in v1 of this RFC:
>>>>> /* Designate a routine to fix up buggy MCFG */
>>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>>> bus)             \
>>>>>           static const struct pci_cfg_fixup
>>>>> __mcfg_fixup_##system##dom##bus\
>>>>>            __used
>>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>>                                   aligned((sizeof(void *)))))
>>>>> =           \
>>>>>           { ops, oem_id, rev, dom, bus };
>>>>
>>>>
>>>>
>>>> V1 fixup exist the redefinition error when compiling mutiple
>>>> DECLARE_ACPI_MCFG_FIXUP
>>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>>
>>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>   ^
>>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>
>>>>
>>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>>> We can see that the name of macro is not replace with it's value in
>>>>
>>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>>
>>>>
>>>> Any good idea is appreciated.
>>>
>>> Hmmm.
>>>
>>> I was testing # op and using min_t to get the min-len when doing
>>> strncmp similar to Chris' suggestion (using min_t avoids type
>>> warnings)
>>>
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>>> bus) \
>>>          static const struct pci_cfg_fixup
>>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>>           __used
>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                  aligned((sizeof(void *)))))
>>> =           \
>>
>>
>>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>>
>>
>>
>> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
>> ‘#’ is not need.
>
>
> Both solutions are OK.
>
> 1. This works when we use macros as OEM ID and OEM table ID:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
>         static const struct pci_cfg_fixup                               \
>                 __mcfg_fixup_##oem_id##oem_table_id##dom##bus           \
>          __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                 aligned((sizeof(void *))))) =           \
>         { ops, oem_id, oem_table_id, rev, dom, bus };
>
> #define OEM_ID "XXXXXX"
> #define OEM_TABLE_ID "YYYYYYYY"
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>
> 2. This works w/o macro which means we need to define OEM ID and OEM as
> string w/o quotation marks:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
> static const struct pci_cfg_fixup \
> __mcfg_fixup_##oem_id##oem_table_id##dom##bus \
> __used __attribute__((__section__(".acpi_fixup_mcfg"), \
> aligned((sizeof(void *))))) = \
> { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In case of oem_id and oem_table_id have special characters ("HISI-D02"
as an example), #2 will have problem unless we use macro definitions
for them.

>
> Personally I think that (2) is better, no need for macro definitions.
> Tomasz
Regards,
Duc Dang

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki <tn@semihalf.com> wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> =E5=9C=A8 2016/6/14 17:00, Duc Dang =E5=86=99=E9=81=93:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>> <liudongdong3@huawei.com> wrote:
>>>>
>>>> Hi Duc
>>>>
>>>> =E5=9C=A8 2016/6/14 4:57, Duc Dang =E5=86=99=E9=81=93:
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>>> <cov@codeaurora.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Dongdong,
>>>>>>
>>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index d3c3e85..49612b3 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -22,6 +22,10 @@
>>>>>>>    #include <linux/kernel.h>
>>>>>>>    #include <linux/pci.h>
>>>>>>>    #include <linux/pci-acpi.h>
>>>>>>> +#include <linux/pci-ecam.h>
>>>>>>> +
>>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>>
>>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>>    struct mcfg_entry {
>>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>>    /* List to save mcfg entries */
>>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>>
>>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>>> +
>>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>>> +{
>>>>>>> +     int bus_num =3D root->secondary.start;
>>>>>>> +     int domain =3D root->segment;
>>>>>>> +     struct pci_cfg_fixup *f;
>>>>>>> +
>>>>>>> +     if (!mcfg_table)
>>>>>>> +             return &pci_generic_ecam_ops;
>>>>>>> +
>>>>>>> +     /*
>>>>>>> +      * Match against platform specific quirks and return
>>>>>>> corresponding
>>>>>>> +      * CAM ops.
>>>>>>> +      *
>>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>>> OEM ID
>>>>>>> and
>>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>>> +      */
>>>>>>> +     for (f =3D __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixu=
ps;
>>>>>>> f++) {
>>>>>>> +             if ((f->domain =3D=3D domain || f->domain =3D=3D
>>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>>> +                 (f->bus_num =3D=3D bus_num || f->bus_num =3D=3D
>>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>>> mcfg_table->header.oem_table_id,
>>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>>
>>>>>>
>>>>>>
>>>>>> This would just be a small convenience, but if the character count
>>>>>> used
>>>>>> here were
>>>>>>
>>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>>
>>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>>> substrings
>>>>>> and
>>>>>> wouldn't need to be padded out to the full length.
>>>>>>
>>>>>>> +                     return f->ops;
>>>>>>> +     }
>>>>>>> +     /* No quirks, use ECAM */
>>>>>>> +     return &pci_generic_ecam_ops;
>>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>>> index 7d63a66..088a1da 100644
>>>>>>> --- a/include/linux/pci-acpi.h
>>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>>> handle);
>>>>>>>
>>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>>> *bus_res);
>>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>>> *root);
>>>>>>>
>>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>>> pci_dev
>>>>>>> *pdev)
>>>>>>>    {
>>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>>    };
>>>>>>>
>>>>>>> +struct pci_cfg_fixup {
>>>>>>> +     struct pci_ecam_ops *ops;
>>>>>>> +     char *oem_id;
>>>>>>> +     char *oem_table_id;
>>>>>>> +     int domain;
>>>>>>> +     int bus_num;
>>>>>>> +};
>>>>>>> +
>>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>>> +
>>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>>> bus) \
>>>>>>> +     static const struct
>>>>>>> pci_cfg_fixup                               \
>>>>>>> +
>>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>>> first two
>>>>>> preprocessor concatenation operators "##" solved the following build
>>>>>> error
>>>>>> for me.
>>>>>>
>>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>>
>>>>>
>>>>>
>>>>> I think the problem is gcc is not happy with quoted string when
>>>>> processing these tokens
>>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>>> string tokens and
>>>>> use the fixup definition in v1 of this RFC:
>>>>> /* Designate a routine to fix up buggy MCFG */
>>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>>> bus)             \
>>>>>           static const struct pci_cfg_fixup
>>>>> __mcfg_fixup_##system##dom##bus\
>>>>>            __used
>>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>>                                   aligned((sizeof(void *)))))
>>>>> =3D           \
>>>>>           { ops, oem_id, rev, dom, bus };
>>>>
>>>>
>>>>
>>>> V1 fixup exist the redefinition error when compiling mutiple
>>>> DECLARE_ACPI_MCFG_FIXUP
>>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>>
>>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>   ^
>>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>
>>>>
>>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>>> We can see that the name of macro is not replace with it's value in
>>>>
>>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MC=
FG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>>
>>>>
>>>> Any good idea is appreciated.
>>>
>>> Hmmm.
>>>
>>> I was testing # op and using min_t to get the min-len when doing
>>> strncmp similar to Chris' suggestion (using min_t avoids type
>>> warnings)
>>>
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>>> bus) \
>>>          static const struct pci_cfg_fixup
>>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>>           __used
>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                  aligned((sizeof(void *)))))
>>> =3D           \
>>
>>
>>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>>
>>
>>
>> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
>> =E2=80=98#=E2=80=99 is not need.
>
>
> Both solutions are OK.
>
> 1. This works when we use macros as OEM ID and OEM table ID:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)=
\
>         static const struct pci_cfg_fixup                               \
>                 __mcfg_fixup_##oem_id##oem_table_id##dom##bus           \
>          __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                 aligned((sizeof(void *))))) =3D          =
 \
>         { ops, oem_id, oem_table_id, rev, dom, bus };
>
> #define OEM_ID "XXXXXX"
> #define OEM_TABLE_ID "YYYYYYYY"
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>
> 2. This works w/o macro which means we need to define OEM ID and OEM as
> string w/o quotation marks:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)=
\
> static const struct pci_cfg_fixup \
> __mcfg_fixup_##oem_id##oem_table_id##dom##bus \
> __used __attribute__((__section__(".acpi_fixup_mcfg"), \
> aligned((sizeof(void *))))) =3D \
> { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In case of oem_id and oem_table_id have special characters ("HISI-D02"
as an example), #2 will have problem unless we use macro definitions
for them.

>
> Personally I think that (2) is better, no need for macro definitions.
> Tomasz
Regards,
Duc Dang

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
> Hi Tomasz, Jon

Hi Gab,

Sorry for the lag in following up.

<snip>

> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)

Actually, it turns out (Cov is correct) that we can just match on OEM
Table ID. The revision should not generally be needed and the vendors
will just need to make sure that they change OEM Table ID in future
silicon. An example from two shipping platforms:

1). AppliedMicro Mustang:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 4A
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000002
[01Ch 0028   4]              Asl Compiler ID : "INTL"
[020h 0032   4]        Asl Compiler Revision : 20140724

2). HP(E[0]) Moonshot:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 48
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000001
[01Ch 0028   4]              Asl Compiler ID : "HP  "
[020h 0032   4]        Asl Compiler Revision : 00000001

I have pinged the semiconductor (Applied) and insisted upon a written
plan (which I have now) for handling the first affect generation(s) and
future chip roadmap stuff, along with how they plan to upstream this
immediately as part of this thread. I have also done similar with each
of the other vendors (this is something ARM or Linaro should be doing).
But I particularly care about X-Gene because I want it to be loved as
shipping silicon in production systems (Moonshot) that are sitting and
waiting in the Fedora Phoenix datacenter in large quantity to come
online if only an upstream kernel would actually boot on them :)

> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.

Correct.

> Can these vendors confirm this?

I've checked all current shipping silicon and prototypes.

> Tomasz do you think this can work for Cavium Thunder?

Will let the vendors followup directly as well.

Jon.

[0] Fortunately that name change doesn't factor when using semiconductor
matching...hopefully none of the non-complaint IP companies in gen1
stuff get bought and change their table names. In the unlikely event
that that does happen, I will preemptively beat them up and ensure that
something crazy doesn't happen with table contents.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
> Hi Tomasz, Jon

Hi Gab,

Sorry for the lag in following up.

<snip>

> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)

Actually, it turns out (Cov is correct) that we can just match on OEM
Table ID. The revision should not generally be needed and the vendors
will just need to make sure that they change OEM Table ID in future
silicon. An example from two shipping platforms:

1). AppliedMicro Mustang:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 4A
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000002
[01Ch 0028   4]              Asl Compiler ID : "INTL"
[020h 0032   4]        Asl Compiler Revision : 20140724

2). HP(E[0]) Moonshot:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 48
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000001
[01Ch 0028   4]              Asl Compiler ID : "HP  "
[020h 0032   4]        Asl Compiler Revision : 00000001

I have pinged the semiconductor (Applied) and insisted upon a written
plan (which I have now) for handling the first affect generation(s) and
future chip roadmap stuff, along with how they plan to upstream this
immediately as part of this thread. I have also done similar with each
of the other vendors (this is something ARM or Linaro should be doing).
But I particularly care about X-Gene because I want it to be loved as
shipping silicon in production systems (Moonshot) that are sitting and
waiting in the Fedora Phoenix datacenter in large quantity to come
online if only an upstream kernel would actually boot on them :)

> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.

Correct.

> Can these vendors confirm this?

I've checked all current shipping silicon and prototypes.

> Tomasz do you think this can work for Cavium Thunder?

Will let the vendors followup directly as well.

Jon.

[0] Fortunately that name change doesn't factor when using semiconductor
matching...hopefully none of the non-complaint IP companies in gen1
stuff get bought and change their table names. In the unlikely event
that that does happen, I will preemptively beat them up and ensure that
something crazy doesn't happen with table contents.

-- 
Computer Architect | Sent from my Fedora powered laptop

[Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
> Hi Tomasz, Jon

Hi Gab,

Sorry for the lag in following up.

<snip>

> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
> 
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)

Actually, it turns out (Cov is correct) that we can just match on OEM
Table ID. The revision should not generally be needed and the vendors
will just need to make sure that they change OEM Table ID in future
silicon. An example from two shipping platforms:

1). AppliedMicro Mustang:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 4A
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000002
[01Ch 0028   4]              Asl Compiler ID : "INTL"
[020h 0032   4]        Asl Compiler Revision : 20140724

2). HP(E[0]) Moonshot:

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 48
[00Ah 0010   6]                       Oem ID : "APM   "
[010h 0016   8]                 Oem Table ID : "XGENE   "
[018h 0024   4]                 Oem Revision : 00000001
[01Ch 0028   4]              Asl Compiler ID : "HP  "
[020h 0032   4]        Asl Compiler Revision : 00000001

I have pinged the semiconductor (Applied) and insisted upon a written
plan (which I have now) for handling the first affect generation(s) and
future chip roadmap stuff, along with how they plan to upstream this
immediately as part of this thread. I have also done similar with each
of the other vendors (this is something ARM or Linaro should be doing).
But I particularly care about X-Gene because I want it to be loved as
shipping silicon in production systems (Moonshot) that are sitting and
waiting in the Fedora Phoenix datacenter in large quantity to come
online if only an upstream kernel would actually boot on them :)

> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW update.

Correct.

> Can these vendors confirm this?

I've checked all current shipping silicon and prototypes.

> Tomasz do you think this can work for Cavium Thunder?

Will let the vendors followup directly as well.

Jon.

[0] Fortunately that name change doesn't factor when using semiconductor
matching...hopefully none of the non-complaint IP companies in gen1
stuff get bought and change their table names. In the unlikely event
that that does happen, I will preemptively beat them up and ensure that
something crazy doesn't happen with table contents.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> <snip>
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 4A
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000002
> [01Ch 0028   4]              Asl Compiler ID : "INTL"
> [020h 0032   4]        Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 48
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000001
> [01Ch 0028   4]              Asl Compiler ID : "HP  "
> [020h 0032   4]        Asl Compiler Revision : 00000001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> <snip>
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 4A
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000002
> [01Ch 0028   4]              Asl Compiler ID : "INTL"
> [020h 0032   4]        Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 48
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000001
> [01Ch 0028   4]              Asl Compiler ID : "HP  "
> [020h 0032   4]        Asl Compiler Revision : 00000001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> <snip>
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 4A
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000002
> [01Ch 0028   4]              Asl Compiler ID : "INTL"
> [020h 0032   4]        Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 48
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000001
> [01Ch 0028   4]              Asl Compiler ID : "HP  "
> [020h 0032   4]        Asl Compiler Revision : 00000001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

:) We should be good with a match on XGENE (but be careful with substring matching) as long as future platforms change that to eg XGENE3 (which is a publicly announced future chip). What you want to avoid is a shorter match later triggering on a future generation.

There are a lot of folks eagerly awaiting Moonshot running an upstream kernel in F25, both for 64 and 32-bit (VMs running 32-bit can replace older builders). I can picture a wonderful world in which this whole ARM server ecosystem works properly with folks doing what they should have three years ago and development happening on upstream kernels with ACPI. Then things become incredibly dull just like x86 - do the dev against upstream, pull into an enterprise distro after it is tested out in a Fedora cycle...and no random nonsense patches. Next thing we know there will be media reports covering silicon that won't end with a rant about how they couldn't get the right firmware and hacked up Ubuntu kernel booting.

Best, and goodnight :)

Jon.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Jun 16, 2016, at 03:46, Duc Dang <dhdang@apm.com> wrote:
> 
>> On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
>>> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>>> Hi Tomasz, Jon
>> 
>> Hi Gab,
>> 
>> Sorry for the lag in following up.
>> 
>> <snip>
>> 
>>> As you can see here Liudongdong has replaced oem_revision with
>>> oem_table_id.
>>> 
>>> Now it seems that there are some platforms that have already shipped
>>> using a matching based on the oem_revision (right Jon?)
>> 
>> Actually, it turns out (Cov is correct) that we can just match on OEM
>> Table ID. The revision should not generally be needed and the vendors
>> will just need to make sure that they change OEM Table ID in future
>> silicon. An example from two shipping platforms:
>> 
>> 1). AppliedMicro Mustang:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 4A
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000002
>> [01Ch 0028   4]              Asl Compiler ID : "INTL"
>> [020h 0032   4]        Asl Compiler Revision : 20140724
>> 
>> 2). HP(E[0]) Moonshot:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 48
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000001
>> [01Ch 0028   4]              Asl Compiler ID : "HP  "
>> [020h 0032   4]        Asl Compiler Revision : 00000001
>> 
>> I have pinged the semiconductor (Applied) and insisted upon a written
>> plan (which I have now) for handling the first affect generation(s) and
>> future chip roadmap stuff, along with how they plan to upstream this
>> immediately as part of this thread. I have also done similar with each
>> of the other vendors (this is something ARM or Linaro should be doing).
>> But I particularly care about X-Gene because I want it to be loved as
>> shipping silicon in production systems (Moonshot) that are sitting and
>> waiting in the Fedora Phoenix datacenter in large quantity to come
>> online if only an upstream kernel would actually boot on them :)
> 
> Thanks for the MCFG information on Moonshot system, Jon.
> 
> I will make sure the posted quirk for X-Gene takes care for HPE
> Moonshot system as well.
> 
> Regards,
> Duc Dang.
> 
>> 
>>> However I guess that if in FW they have defined oem_table_id properly
>>> they should be able to use this mechanism without needing to a FW update.
>> 
>> Correct.
>> 
>>> Can these vendors confirm this?
>> 
>> I've checked all current shipping silicon and prototypes.
>> 
>>> Tomasz do you think this can work for Cavium Thunder?
>> 
>> Will let the vendors followup directly as well.
>> 
>> Jon.
>> 
>> [0] Fortunately that name change doesn't factor when using semiconductor
>> matching...hopefully none of the non-complaint IP companies in gen1
>> stuff get bought and change their table names. In the unlikely event
>> that that does happen, I will preemptively beat them up and ensure that
>> something crazy doesn't happen with table contents.
>> 
>> --
>> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

:) We should be good with a match on XGENE (but be careful with substring matching) as long as future platforms change that to eg XGENE3 (which is a publicly announced future chip). What you want to avoid is a shorter match later triggering on a future generation.

There are a lot of folks eagerly awaiting Moonshot running an upstream kernel in F25, both for 64 and 32-bit (VMs running 32-bit can replace older builders). I can picture a wonderful world in which this whole ARM server ecosystem works properly with folks doing what they should have three years ago and development happening on upstream kernels with ACPI. Then things become incredibly dull just like x86 - do the dev against upstream, pull into an enterprise distro after it is tested out in a Fedora cycle...and no random nonsense patches. Next thing we know there will be media reports covering silicon that won't end with a rant about how they couldn't get the right firmware and hacked up Ubuntu kernel booting.

Best, and goodnight :)

Jon.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Jun 16, 2016, at 03:46, Duc Dang <dhdang@apm.com> wrote:
> 
>> On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
>>> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>>> Hi Tomasz, Jon
>> 
>> Hi Gab,
>> 
>> Sorry for the lag in following up.
>> 
>> <snip>
>> 
>>> As you can see here Liudongdong has replaced oem_revision with
>>> oem_table_id.
>>> 
>>> Now it seems that there are some platforms that have already shipped
>>> using a matching based on the oem_revision (right Jon?)
>> 
>> Actually, it turns out (Cov is correct) that we can just match on OEM
>> Table ID. The revision should not generally be needed and the vendors
>> will just need to make sure that they change OEM Table ID in future
>> silicon. An example from two shipping platforms:
>> 
>> 1). AppliedMicro Mustang:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 4A
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000002
>> [01Ch 0028   4]              Asl Compiler ID : "INTL"
>> [020h 0032   4]        Asl Compiler Revision : 20140724
>> 
>> 2). HP(E[0]) Moonshot:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 48
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000001
>> [01Ch 0028   4]              Asl Compiler ID : "HP  "
>> [020h 0032   4]        Asl Compiler Revision : 00000001
>> 
>> I have pinged the semiconductor (Applied) and insisted upon a written
>> plan (which I have now) for handling the first affect generation(s) and
>> future chip roadmap stuff, along with how they plan to upstream this
>> immediately as part of this thread. I have also done similar with each
>> of the other vendors (this is something ARM or Linaro should be doing).
>> But I particularly care about X-Gene because I want it to be loved as
>> shipping silicon in production systems (Moonshot) that are sitting and
>> waiting in the Fedora Phoenix datacenter in large quantity to come
>> online if only an upstream kernel would actually boot on them :)
> 
> Thanks for the MCFG information on Moonshot system, Jon.
> 
> I will make sure the posted quirk for X-Gene takes care for HPE
> Moonshot system as well.
> 
> Regards,
> Duc Dang.
> 
>> 
>>> However I guess that if in FW they have defined oem_table_id properly
>>> they should be able to use this mechanism without needing to a FW update.
>> 
>> Correct.
>> 
>>> Can these vendors confirm this?
>> 
>> I've checked all current shipping silicon and prototypes.
>> 
>>> Tomasz do you think this can work for Cavium Thunder?
>> 
>> Will let the vendors followup directly as well.
>> 
>> Jon.
>> 
>> [0] Fortunately that name change doesn't factor when using semiconductor
>> matching...hopefully none of the non-complaint IP companies in gen1
>> stuff get bought and change their table names. In the unlikely event
>> that that does happen, I will preemptively beat them up and ensure that
>> something crazy doesn't happen with table contents.
>> 
>> --
>> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

:) We should be good with a match on XGENE (but be careful with substring ma=
tching) as long as future platforms change that to eg XGENE3 (which is a pub=
licly announced future chip). What you want to avoid is a shorter match late=
r triggering on a future generation.

There are a lot of folks eagerly awaiting Moonshot running an upstream kerne=
l in F25, both for 64 and 32-bit (VMs running 32-bit can replace older build=
ers). I can picture a wonderful world in which this whole ARM server ecosyst=
em works properly with folks doing what they should have three years ago and=
 development happening on upstream kernels with ACPI. Then things become inc=
redibly dull just like x86 - do the dev against upstream, pull into an enter=
prise distro after it is tested out in a Fedora cycle...and no random nonsen=
se patches. Next thing we know there will be media reports covering silicon t=
hat won't end with a rant about how they couldn't get the right firmware and=
 hacked up Ubuntu kernel booting.

Best, and goodnight :)

Jon.

--=20
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Jun 16, 2016, at 03:46, Duc Dang <dhdang@apm.com> wrote:
>=20
>> On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
>>> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>>> Hi Tomasz, Jon
>>=20
>> Hi Gab,
>>=20
>> Sorry for the lag in following up.
>>=20
>> <snip>
>>=20
>>> As you can see here Liudongdong has replaced oem_revision with
>>> oem_table_id.
>>>=20
>>> Now it seems that there are some platforms that have already shipped
>>> using a matching based on the oem_revision (right Jon?)
>>=20
>> Actually, it turns out (Cov is correct) that we can just match on OEM
>> Table ID. The revision should not generally be needed and the vendors
>> will just need to make sure that they change OEM Table ID in future
>> silicon. An example from two shipping platforms:
>>=20
>> 1). AppliedMicro Mustang:
>>=20
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 4A
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000002
>> [01Ch 0028   4]              Asl Compiler ID : "INTL"
>> [020h 0032   4]        Asl Compiler Revision : 20140724
>>=20
>> 2). HP(E[0]) Moonshot:
>>=20
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 48
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000001
>> [01Ch 0028   4]              Asl Compiler ID : "HP  "
>> [020h 0032   4]        Asl Compiler Revision : 00000001
>>=20
>> I have pinged the semiconductor (Applied) and insisted upon a written
>> plan (which I have now) for handling the first affect generation(s) and
>> future chip roadmap stuff, along with how they plan to upstream this
>> immediately as part of this thread. I have also done similar with each
>> of the other vendors (this is something ARM or Linaro should be doing).
>> But I particularly care about X-Gene because I want it to be loved as
>> shipping silicon in production systems (Moonshot) that are sitting and
>> waiting in the Fedora Phoenix datacenter in large quantity to come
>> online if only an upstream kernel would actually boot on them :)
>=20
> Thanks for the MCFG information on Moonshot system, Jon.
>=20
> I will make sure the posted quirk for X-Gene takes care for HPE
> Moonshot system as well.
>=20
> Regards,
> Duc Dang.
>=20
>>=20
>>> However I guess that if in FW they have defined oem_table_id properly
>>> they should be able to use this mechanism without needing to a FW update=
.
>>=20
>> Correct.
>>=20
>>> Can these vendors confirm this?
>>=20
>> I've checked all current shipping silicon and prototypes.
>>=20
>>> Tomasz do you think this can work for Cavium Thunder?
>>=20
>> Will let the vendors followup directly as well.
>>=20
>> Jon.
>>=20
>> [0] Fortunately that name change doesn't factor when using semiconductor
>> matching...hopefully none of the non-complaint IP companies in gen1
>> stuff get bought and change their table names. In the unlikely event
>> that that does happen, I will preemptively beat them up and ensure that
>> something crazy doesn't happen with table contents.
>>=20
>> --
>> Computer Architect | Sent from my Fedora powered laptop

[Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jon Masters]

:) We should be good with a match on XGENE (but be careful with substring matching) as long as future platforms change that to eg XGENE3 (which is a publicly announced future chip). What you want to avoid is a shorter match later triggering on a future generation.

There are a lot of folks eagerly awaiting Moonshot running an upstream kernel in F25, both for 64 and 32-bit (VMs running 32-bit can replace older builders). I can picture a wonderful world in which this whole ARM server ecosystem works properly with folks doing what they should have three years ago and development happening on upstream kernels with ACPI. Then things become incredibly dull just like x86 - do the dev against upstream, pull into an enterprise distro after it is tested out in a Fedora cycle...and no random nonsense patches. Next thing we know there will be media reports covering silicon that won't end with a rant about how they couldn't get the right firmware and hacked up Ubuntu kernel booting.

Best, and goodnight :)

Jon.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Jun 16, 2016, at 03:46, Duc Dang <dhdang@apm.com> wrote:
> 
>> On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
>>> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>>> Hi Tomasz, Jon
>> 
>> Hi Gab,
>> 
>> Sorry for the lag in following up.
>> 
>> <snip>
>> 
>>> As you can see here Liudongdong has replaced oem_revision with
>>> oem_table_id.
>>> 
>>> Now it seems that there are some platforms that have already shipped
>>> using a matching based on the oem_revision (right Jon?)
>> 
>> Actually, it turns out (Cov is correct) that we can just match on OEM
>> Table ID. The revision should not generally be needed and the vendors
>> will just need to make sure that they change OEM Table ID in future
>> silicon. An example from two shipping platforms:
>> 
>> 1). AppliedMicro Mustang:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 4A
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000002
>> [01Ch 0028   4]              Asl Compiler ID : "INTL"
>> [020h 0032   4]        Asl Compiler Revision : 20140724
>> 
>> 2). HP(E[0]) Moonshot:
>> 
>> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
>> Configuration table]
>> [004h 0004   4]                 Table Length : 0000003C
>> [008h 0008   1]                     Revision : 01
>> [009h 0009   1]                     Checksum : 48
>> [00Ah 0010   6]                       Oem ID : "APM   "
>> [010h 0016   8]                 Oem Table ID : "XGENE   "
>> [018h 0024   4]                 Oem Revision : 00000001
>> [01Ch 0028   4]              Asl Compiler ID : "HP  "
>> [020h 0032   4]        Asl Compiler Revision : 00000001
>> 
>> I have pinged the semiconductor (Applied) and insisted upon a written
>> plan (which I have now) for handling the first affect generation(s) and
>> future chip roadmap stuff, along with how they plan to upstream this
>> immediately as part of this thread. I have also done similar with each
>> of the other vendors (this is something ARM or Linaro should be doing).
>> But I particularly care about X-Gene because I want it to be loved as
>> shipping silicon in production systems (Moonshot) that are sitting and
>> waiting in the Fedora Phoenix datacenter in large quantity to come
>> online if only an upstream kernel would actually boot on them :)
> 
> Thanks for the MCFG information on Moonshot system, Jon.
> 
> I will make sure the posted quirk for X-Gene takes care for HPE
> Moonshot system as well.
> 
> Regards,
> Duc Dang.
> 
>> 
>>> However I guess that if in FW they have defined oem_table_id properly
>>> they should be able to use this mechanism without needing to a FW update.
>> 
>> Correct.
>> 
>>> Can these vendors confirm this?
>> 
>> I've checked all current shipping silicon and prototypes.
>> 
>>> Tomasz do you think this can work for Cavium Thunder?
>> 
>> Will let the vendors followup directly as well.
>> 
>> Jon.
>> 
>> [0] Fortunately that name change doesn't factor when using semiconductor
>> matching...hopefully none of the non-complaint IP companies in gen1
>> stuff get bought and change their table names. In the unlikely event
>> that that does happen, I will preemptively beat them up and ensure that
>> something crazy doesn't happen with table contents.
>> 
>> --
>> Computer Architect | Sent from my Fedora powered laptop

[Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> <snip>
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 4A
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000002
> [01Ch 0028   4]              Asl Compiler ID : "INTL"
> [020h 0032   4]        Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 48
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000001
> [01Ch 0028   4]              Asl Compiler ID : "HP  "
> [020h 0032   4]        Asl Compiler Revision : 00000001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki <tn@semihalf.com> wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> ? 2016/6/14 17:00, Duc Dang ??:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>> <liudongdong3@huawei.com> wrote:
>>>>
>>>> Hi Duc
>>>>
>>>> ? 2016/6/14 4:57, Duc Dang ??:
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>>>> <cov@codeaurora.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Dongdong,
>>>>>>
>>>>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index d3c3e85..49612b3 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -22,6 +22,10 @@
>>>>>>>    #include <linux/kernel.h>
>>>>>>>    #include <linux/pci.h>
>>>>>>>    #include <linux/pci-acpi.h>
>>>>>>> +#include <linux/pci-ecam.h>
>>>>>>> +
>>>>>>> +/* Root pointer to the mapped MCFG table */
>>>>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>>>>
>>>>>>>    /* Structure to hold entries from the MCFG table */
>>>>>>>    struct mcfg_entry {
>>>>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>>>>    /* List to save mcfg entries */
>>>>>>>    static LIST_HEAD(pci_mcfg_list);
>>>>>>>
>>>>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>>>>> +
>>>>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>>>>> +{
>>>>>>> +     int bus_num = root->secondary.start;
>>>>>>> +     int domain = root->segment;
>>>>>>> +     struct pci_cfg_fixup *f;
>>>>>>> +
>>>>>>> +     if (!mcfg_table)
>>>>>>> +             return &pci_generic_ecam_ops;
>>>>>>> +
>>>>>>> +     /*
>>>>>>> +      * Match against platform specific quirks and return
>>>>>>> corresponding
>>>>>>> +      * CAM ops.
>>>>>>> +      *
>>>>>>> +      * First match against PCI topology <domain:bus> then use
>>>>>>> OEM ID
>>>>>>> and
>>>>>>> +      * OEM revision from MCFG table standard header.
>>>>>>> +      */
>>>>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>>>> f++) {
>>>>>>> +             if ((f->domain == domain || f->domain ==
>>>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>>>>> PCI_MCFG_BUS_ANY) &&
>>>>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>>>>> +                 (!strncmp(f->oem_table_id,
>>>>>>> mcfg_table->header.oem_table_id,
>>>>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>>>>
>>>>>>
>>>>>>
>>>>>> This would just be a small convenience, but if the character count
>>>>>> used
>>>>>> here were
>>>>>>
>>>>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>>>>
>>>>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>>>>>> substrings
>>>>>> and
>>>>>> wouldn't need to be padded out to the full length.
>>>>>>
>>>>>>> +                     return f->ops;
>>>>>>> +     }
>>>>>>> +     /* No quirks, use ECAM */
>>>>>>> +     return &pci_generic_ecam_ops;
>>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>>>>> index 7d63a66..088a1da 100644
>>>>>>> --- a/include/linux/pci-acpi.h
>>>>>>> +++ b/include/linux/pci-acpi.h
>>>>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>>>>    extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>>>>>> handle);
>>>>>>>
>>>>>>>    extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>>>>> *bus_res);
>>>>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>>>>> *root);
>>>>>>>
>>>>>>>    static inline acpi_handle acpi_find_root_bridge_handle(struct
>>>>>>> pci_dev
>>>>>>> *pdev)
>>>>>>>    {
>>>>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>>>>         int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>>>>    };
>>>>>>>
>>>>>>> +struct pci_cfg_fixup {
>>>>>>> +     struct pci_ecam_ops *ops;
>>>>>>> +     char *oem_id;
>>>>>>> +     char *oem_table_id;
>>>>>>> +     int domain;
>>>>>>> +     int bus_num;
>>>>>>> +};
>>>>>>> +
>>>>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>>>>> +
>>>>>>> +/* Designate a routine to fix up buggy MCFG */
>>>>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>>>>>> bus) \
>>>>>>> +     static const struct
>>>>>>> pci_cfg_fixup                               \
>>>>>>> +
>>>>>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>>>>> following a GCC documentation suggestion [1]--but removing the
>>>>>> first two
>>>>>> preprocessor concatenation operators "##" solved the following build
>>>>>> error
>>>>>> for me.
>>>>>>
>>>>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>>>>> ""QCOM"" does not give a valid preprocessing token
>>>>>>     __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>>>
>>>>>
>>>>>
>>>>> I think the problem is gcc is not happy with quoted string when
>>>>> processing these tokens
>>>>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>>>>> string tokens and
>>>>> use the fixup definition in v1 of this RFC:
>>>>> /* Designate a routine to fix up buggy MCFG */
>>>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom,
>>>>> bus)             \
>>>>>           static const struct pci_cfg_fixup
>>>>> __mcfg_fixup_##system##dom##bus\
>>>>>            __used
>>>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>>>                                   aligned((sizeof(void *)))))
>>>>> =           \
>>>>>           { ops, oem_id, rev, dom, bus };
>>>>
>>>>
>>>>
>>>> V1 fixup exist the redefinition error when compiling mutiple
>>>> DECLARE_ACPI_MCFG_FIXUP
>>>> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>>>>
>>>> #define EFI_ACPI_HISI_OEM_ID "HISI"
>>>> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
>>>> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>         EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
>>>> PCI_MCFG_BUS_ANY);
>>>>
>>>> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
>>>> include/linux/pci-acpi.h:98:43: error: redefinition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>   DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>>>>   ^
>>>> include/linux/pci-acpi.h:98:43: note: previous definition of
>>>> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>>>>           static const struct pci_cfg_fixup
>>>> __mcfg_fixup_##system##dom##bus\
>>>>                                             ^
>>>> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
>>>> 'DECLARE_ACPI_MCFG_FIXUP'
>>>>
>>>>
>>>> V2 fixup can resolve the redefinition error, but need to use macro.
>>>> We can see that the name of macro is not replace with it's value in
>>>>
>>>> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>>>>
>>>>
>>>> Any good idea is appreciated.
>>>
>>> Hmmm.
>>>
>>> I was testing # op and using min_t to get the min-len when doing
>>> strncmp similar to Chris' suggestion (using min_t avoids type
>>> warnings)
>>>
>>> /* Designate a routine to fix up buggy MCFG */
>>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom,
>>> bus) \
>>>          static const struct pci_cfg_fixup
>>> __mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
>>>           __used
>>> __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>                                  aligned((sizeof(void *)))))
>>> =           \
>>
>>
>>>          { ops, #oem_id, #oem_table_id, rev, dom, bus };
>>
>>
>>
>> This should change to { ops, oem_id, oem_table_id, rev, dom, bus };
>> ?#? is not need.
>
>
> Both solutions are OK.
>
> 1. This works when we use macros as OEM ID and OEM table ID:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
>         static const struct pci_cfg_fixup                               \
>                 __mcfg_fixup_##oem_id##oem_table_id##dom##bus           \
>          __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>                                 aligned((sizeof(void *))))) =           \
>         { ops, oem_id, oem_table_id, rev, dom, bus };
>
> #define OEM_ID "XXXXXX"
> #define OEM_TABLE_ID "YYYYYYYY"
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, OEM_ID, OEM_TABLE_ID, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>
> 2. This works w/o macro which means we need to define OEM ID and OEM as
> string w/o quotation marks:
>
> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus)\
> static const struct pci_cfg_fixup \
> __mcfg_fixup_##oem_id##oem_table_id##dom##bus \
> __used __attribute__((__section__(".acpi_fixup_mcfg"), \
> aligned((sizeof(void *))))) = \
> { ops, #oem_id, #oem_table_id, rev, dom, bus };
>
> DECLARE_ACPI_MCFG_FIXUP(&quirk_ops, XXXXXX, YYYYYYYY, 1,
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);

In case of oem_id and oem_table_id have special characters ("HISI-D02"
as an example), #2 will have problem unless we use macro definitions
for them.

>
> Personally I think that (2) is better, no need for macro definitions.
> Tomasz
Regards,
Duc Dang

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu <liudongdong3@huawei.com> wrote:
> Hi Duc
>
> ? 2016/6/14 4:57, Duc Dang ??:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>>
>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>> index d3c3e85..49612b3 100644
>>>> --- a/drivers/acpi/pci_mcfg.c
>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>> @@ -22,6 +22,10 @@
>>>>   #include <linux/kernel.h>
>>>>   #include <linux/pci.h>
>>>>   #include <linux/pci-acpi.h>
>>>> +#include <linux/pci-ecam.h>
>>>> +
>>>> +/* Root pointer to the mapped MCFG table */
>>>> +static struct acpi_table_mcfg *mcfg_table;
>>>>
>>>>   /* Structure to hold entries from the MCFG table */
>>>>   struct mcfg_entry {
>>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>>   /* List to save mcfg entries */
>>>>   static LIST_HEAD(pci_mcfg_list);
>>>>
>>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>>> +
>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>> +{
>>>> +     int bus_num = root->secondary.start;
>>>> +     int domain = root->segment;
>>>> +     struct pci_cfg_fixup *f;
>>>> +
>>>> +     if (!mcfg_table)
>>>> +             return &pci_generic_ecam_ops;
>>>> +
>>>> +     /*
>>>> +      * Match against platform specific quirks and return corresponding
>>>> +      * CAM ops.
>>>> +      *
>>>> +      * First match against PCI topology <domain:bus> then use OEM ID
>>>> and
>>>> +      * OEM revision from MCFG table standard header.
>>>> +      */
>>>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> +             if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> +                 (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>> +                           ACPI_OEM_ID_SIZE)) &&
>>>> +                 (!strncmp(f->oem_table_id,
>>>> mcfg_table->header.oem_table_id,
>>>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
>>>> +                     return f->ops;
>>>> +     }
>>>> +     /* No quirks, use ECAM */
>>>> +     return &pci_generic_ecam_ops;
>>>> +}
>>>
>>>
>>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>>> index 7d63a66..088a1da 100644
>>>> --- a/include/linux/pci-acpi.h
>>>> +++ b/include/linux/pci-acpi.h
>>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>>   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>>>
>>>>   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>>> *bus_res);
>>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>>> *root);
>>>>
>>>>   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
>>>> *pdev)
>>>>   {
>>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>>>        int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>>   };
>>>>
>>>> +struct pci_cfg_fixup {
>>>> +     struct pci_ecam_ops *ops;
>>>> +     char *oem_id;
>>>> +     char *oem_table_id;
>>>> +     int domain;
>>>> +     int bus_num;
>>>> +};
>>>> +
>>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>>> +#define PCI_MCFG_BUS_ANY     -1
>>>> +
>>>> +/* Designate a routine to fix up buggy MCFG */
>>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>>>> +     static const struct pci_cfg_fixup                               \
>>>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first two
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
>>          static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>           __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>                                  aligned((sizeof(void *))))) =           \
>>          { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the redefinition error when compiling mutiple
> DECLARE_ACPI_MCFG_FIXUP
> with the same PCI_MCFG_DOMAIN_ANY and PCI_MCFG_BUS_ANY.
>
> #define EFI_ACPI_HISI_OEM_ID "HISI"
> #define EFI_ACPI_HISI_D02_OEM_TABLE_ID "HISI-D02"
> #define EFI_ACPI_HISI_D03_OEM_TABLE_ID "HISI-D03"
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D02_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>        EFI_ACPI_HISI_D03_OEM_TABLE_ID, PCI_MCFG_DOMAIN_ANY,
> PCI_MCFG_BUS_ANY);
>
> In file included from drivers/pci/host/pcie-hisi-acpi.c:15:0:
> include/linux/pci-acpi.h:98:43: error: redefinition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY'
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:215:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>  DECLARE_ACPI_MCFG_FIXUP(&hisi_pcie_ecam_ops, EFI_ACPI_HISI_OEM_ID,
>  ^
> include/linux/pci-acpi.h:98:43: note: previous definition of
> '__mcfg_fixup_systemPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY' was here
>          static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
>                                            ^
> drivers/pci/host/pcie-hisi-acpi.c:212:1: note: in expansion of macro
> 'DECLARE_ACPI_MCFG_FIXUP'
>
>
> V2 fixup can resolve the redefinition error, but need to use macro.
> We can see that the name of macro is not replace with it's value in
> "__mcfg_fixup_EFI_ACPI_HISI_OEM_IDEFI_ACPI_HISI_D03_OEM_TABLE_IDPCI_MCFG_DOMAIN_ANYPCI_MCFG_BUS_ANY".
>
> Any good idea is appreciated.
Hmmm.

I was testing # op and using min_t to get the min-len when doing
strncmp similar to Chris' suggestion (using min_t avoids type
warnings)

/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, rev, dom, bus) \
        static const struct pci_cfg_fixup
__mcfg_fixup##oem_id##oem_table_id##rev##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, #oem_id, #oem_table_id, rev, dom, bus };

My fixup definition:
DECLARE_ACPI_MCFG_FIXUP(&xgene_pcie_ecam_ops, APM, XGENE, 2,
                                               PCI_MCFG_DOMAIN_ANY,
PCI_MCFG_BUS_ANY);
My match condition is:
               if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
                   (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
                   (!strncmp(f->oem_id, mcfg->header.oem_id,
                             min_t(size_t, strlen(f->oem_id),
                                   ACPI_OEM_ID_SIZE))) &&
                   (!strncmp(f->oem_table_id, mcfg->header.oem_table_id,
                             min_t(size_t, strlen(f->oem_table_id),
                                   ACPI_OEM_TABLE_ID_SIZE))) &&
                   (f->oem_revision == mcfg->header.oem_revision)) {
                       return f->ops;
               }

But this still does not work for your case as having HISI-D02 as
oem_table_id will cause error.

>
> Thanks
> Dongdong
>
>>
>> Regards,
>> Duc Dang.
>>
>>
>>>    ^
>>> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro
>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>   ^
>>> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432""
>>> does not give a valid preprocessing token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and
>>> "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
>>> ng token
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                                      ^
>>> include/linux/pci-acpi.h:90:25: note: in definition of macro
>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                           ^
>>> arch/arm64/kernel/pci.c:225:44: error: expected ?=?, ?,?, ?;?, ?asm? or
>>> ?__attribute__? before string constant
>>>   DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432",
>>> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>>>                                              ^
>>> include/linux/pci-acpi.h:90:17: note: in definition of macro
>>> ?DECLARE_ACPI_MCFG_FIXUP?
>>>    __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>                   ^
>>> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
>>> make: *** [arch/arm64/kernel] Error 2
>>>
>>> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>>>
>>>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>>>> +                             aligned((sizeof(void *))))) =           \
>>>> +     { ops, oem_id, oem_table_id, dom, bus };
>>>> +
>>>>   extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info
>>>> *info);
>>>>   extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root
>>>> *root,
>>>>                                            struct acpi_pci_root_ops
>>>> *ops,
>>>>
>>>
>>> Thanks,
>>> Cov
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>
>>
>> .
>>
>
Regards
Duc Dang.

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo <jhugo@codeaurora.org> wrote:
> On 6/13/2016 9:12 AM, okaya at codeaurora.org wrote:
>>
>> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>>>
>>> Hi Sinan
>>>
>>>> -----Original Message-----
>>>> From: Sinan Kaya [mailto:okaya at codeaurora.org]
>>>> Sent: 13 June 2016 15:03
>>>> To: Gabriele Paoloni; liudongdong (C); helgaas at kernel.org;
>>>> arnd at arndb.de; will.deacon at arm.com; catalin.marinas at arm.com;
>>>> rafael at kernel.org; hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com;
>>>> jchandra at broadcom.com; tn at semihalf.com
>>>> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com;
>>>> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
>>>> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
>>>> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>>> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
>>>> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org;
>>>> dhdang at apm.com; jeremy.linton at arm.com; cov at codeaurora.org; Chenxin
>>>> (Charles); Linuxarm
>>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
>>>> accessors against platfrom specific ECAM quirks
>>>>
>>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
>>>> > As you can see here Liudongdong has replaced oem_revision with
>>>> > oem_table_id.
>>>> >
>>>> > Now it seems that there are some platforms that have already shipped
>>>> > using a matching based on the oem_revision (right Jon?)
>>>> >
>>>> > However I guess that if in FW they have defined oem_table_id properly
>>>> > they should be able to use this mechanism without needing to a FW
>>>> update.
>>>> >
>>>> > Can these vendors confirm this?
>>>> >
>>>> > Tomasz do you think this can work for Cavium Thunder?
>>>> >
>>>> > Thanks
>>>> >
>>>> > Gab
>>>>
>>>> Why not have all three of them?
>>>>
>>>> The initial approach was OEM id and revision id.
>>>>
>>>> Jeff Hugo indicated that addition (not removing any other fields) of
>>>> table id
>>>> would make more sense.
>>>
>>>
>>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>>> PCI config space accessors against platfrom specific ECAM quirks."
>>>
>>> I quote:
>>>
>>>  "Using the OEM revision
>>>  field does not seem to be appropriate since these are different
>>>  platforms and the revision field appears to be for the purpose of
>>>  tracking differences within a single platform.  Therefore, Cov is
>>>  proposing using the OEM table id as a mechanism to distinguish
>>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>>  same OEM."
>>>
>>> So it looks to me that he pointed out that using the OEM revision field
>>> is wrong...and this is why I have asked if replacing it with the table
>>> id can work for other vendors....
>>>
>>> Thanks
>>>
>>> Gab
>>>
>>
>> I had an internal discussion with jeff and cov before posting on the
>> maillist.
>>
>> I think there is missing info in the email.
>>
>> Usage of oem id + table id + revision is ok.
>>
>> Usage of oem id + revision is not ok as one oem can build multiple chips
>> with the same oem id and revision id but different table id. Otherwise,
>> we can run out of revisions very quickly.
>
>
> Agreed.
>
> I'm sorry for the confusion.  My intent was to point out that revision alone
> appeared insufficient to address all the identified problems, but I believe
> there is still a case for using revision. Table id is useful for
> differentiating between platforms/chips.  Revision is useful for
> differentiation between different versions of a single platform/chip
> assuming the silicon is respun or some other fix is applied.  Both solve
> different scenarios, and I'm not aware of a reason why they could not be
> used together to solve all currently identified cases.

Using OEM ID + Table ID + Revision will work for X-Gene platforms as well.

Regards,
Duc Dang.
>
>>
>>>
>>>>
>>>> --
>>>> Sinan Kaya
>>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
>>>> Inc.
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>>> Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Jeffrey Hugo
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

[RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
<cov@codeaurora.org> wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include <linux/kernel.h>
>>  #include <linux/pci.h>
>>  #include <linux/pci-acpi.h>
>> +#include <linux/pci-ecam.h>
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> +     int bus_num = root->secondary.start;
>> +     int domain = root->segment;
>> +     struct pci_cfg_fixup *f;
>> +
>> +     if (!mcfg_table)
>> +             return &pci_generic_ecam_ops;
>> +
>> +     /*
>> +      * Match against platform specific quirks and return corresponding
>> +      * CAM ops.
>> +      *
>> +      * First match against PCI topology <domain:bus> then use OEM ID and
>> +      * OEM revision from MCFG table standard header.
>> +      */
>> +     for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> +             if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>> +                 (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>> +                 (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +                           ACPI_OEM_ID_SIZE)) &&
>> +                 (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>> +                           ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used here were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
> wouldn't need to be padded out to the full length.
>
>> +                     return f->ops;
>> +     }
>> +     /* No quirks, use ECAM */
>> +     return &pci_generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>       int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> +     struct pci_ecam_ops *ops;
>> +     char *oem_id;
>> +     char *oem_table_id;
>> +     int domain;
>> +     int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY     -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> +     static const struct pci_cfg_fixup                               \
>> +     __mcfg_fixup_##oem_id##oem_table_id##dom##bus                   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build error
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus)             \
        static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
         __used __attribute__((__section__(".acpi_fixup_mcfg"),         \
                                aligned((sizeof(void *))))) =           \
        { ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro ?DECLARE_ACPI_MCFG_FIXUP?
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and "PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
> ng token
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                                     ^
> include/linux/pci-acpi.h:90:25: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                          ^
> arch/arm64/kernel/pci.c:225:44: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before string constant
>  DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>                                             ^
> include/linux/pci-acpi.h:90:17: note: in definition of macro ?DECLARE_ACPI_MCFG_FIXUP?
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>                  ^
> make[1]: *** [arch/arm64/kernel/pci.o] Error 1
> make: *** [arch/arm64/kernel] Error 2
>
> 1. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
>
>> +     __used  __attribute__((__section__(".acpi_fixup_mcfg"),         \
>> +                             aligned((sizeof(void *))))) =           \
>> +     { ops, oem_id, oem_table_id, dom, bus };
>> +
>>  extern int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info);
>>  extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>                                           struct acpi_pci_root_ops *ops,
>>
>
> Thanks,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project