Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1293002 > unrolled thread

[PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

Back to article view | Back to linux.kernel

Contents

  [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 12/23] pci, acpi: Move ACPI host bridge device companion assignment to core code. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 01/23] x86, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
      Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Arnd Bergmann <arnd@arndb.de> - 2015-12-18 13:50 +0100
        Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge  init Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 11:30 +0100
    [PATCH V2 19/23] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
      RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-21 12:50 +0100
        Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Arnd Bergmann <arnd@arndb.de> - 2015-12-21 15:20 +0100
          Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Arnd Bergmann <arnd@arndb.de> - 2015-12-21 23:50 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 00:30 +0100
          Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 00:20 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 09:50 +0100
            RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 10:40 +0100
              Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 17:40 +0100
                Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 17:50 +0100
                  RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 19:00 +0100
        Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 11:30 +0100
          RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 15:50 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Hanjun Guo <hanjun.guo@linaro.org> - 2015-12-23 10:40 +0100
    [PATCH V2 09/23] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 18/23] x86, acpi, pci: Use equivalent function introduced in previous patch. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 14/23] pci, acpi: Provide generic way to assign bus domain number. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 05/23] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 11/23] arm64, pci: Remove useless boot time IRQ assignment when booting with DT. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 13/23] x86, ia64, pci: Remove ACPI companion device from platform specific data. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 10/23] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 16/23] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
      Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-17 11:30 +0100
        Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-17 11:50 +0100
      Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-21 19:20 +0100
        Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 09:40 +0100
    [PATCH V2 15/23] x86, ia64, pci: Convert arches to use PCI_DOMAINS_GENERIC. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 08/23] arm64, acpi: Use empty PCI config space accessors from mcfg.c file. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 03/23] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 07/23] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 17/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Sinan Kaya <okaya@codeaurora.org> - 2015-12-17 22:30 +0100
      Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-18 13:30 +0100
        Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI okaya@codeaurora.org - 2015-12-18 20:00 +0100
          Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 11:40 +0100
          Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-12-21 13:10 +0100
            Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 13:50 +0100
              Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Arnd Bergmann <arnd@arndb.de> - 2015-12-21 15:20 +0100
                Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Okaya@codeaurora.org - 2015-12-21 16:30 +0100
                  Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Arnd Bergmann <arnd@arndb.de> - 2015-12-21 23:50 +0100

Page 1 of 3  [1] 2 3  Next page →

#1293002 — [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From the functionality point of view this series might be split into the
following logic parts:
1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
   PCI config regions and used when necessary.
2. Move non-arch specific bits to the core code.
3. Use MMCONFIG code and implement generic ACPI based PCI host
   controller driver.
4. Enable above driver on ARM64

Patches has been built on top of 4.4-rc4 and can be found here:
git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v2)

NOTE, this patch set depends on Matthew's patches:
http://www.spinics.net/lists/linux-pci/msg45950.html
https://github.com/Vality/linux/tree/pci-fixes

This has been tested on Cavium ThunderX 1 socket server and QEMU.
Any help in reviewing and testing is very appreciated.

v1 -> v2
- moved non-arch specific piece of code to dirver/acpi/ directory
- fixed IO resource handling
- introduced PCI config accessors quirks matching
- moved ACPI_COMPANION_SET to generic code

Liu Jiang (1):
  ACPI, PCI: Refine the way to handle translation_offset for ACPI
    resources

Tomasz Nowicki (22):
  x86, pci: Reorder logic of pci_mmconfig_insert() function
  x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
    out of arch/x86/ directory
  pci, acpi, mcfg: Provide generic implementation of MCFG code
    initialization.
  x86, pci: mmconfig_{32,64}.c code refactoring - remove code
    duplication.
  x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
    driver.
  XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
  pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
  arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
  pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
    added or not.
  x86, pci: Cleanup platform specific MCFG data using previously added
    ECAM hot_added flag.
  arm64, pci: Remove useless boot time IRQ assignment when booting with
    DT.
  pci, acpi: Move ACPI host bridge device companion assignment to core
    code.
  x86, ia64, pci: Remove ACPI companion device from platform specific
    data.
  pci, acpi: Provide generic way to assign bus domain number.
  x86, ia64, pci: Convert arches to use PCI_DOMAINS_GENERIC.
  x86, ia64: Include acpi_pci_{add|remove}_bus to the default
    pcibios_{add|remove}_bus implementation.
  acpi, mcfg: Implement two calls that might be used to inject/remove
    MCFG region.
  x86, acpi, pci: Use equivalent function introduced in previous patch.
  acpi, mcfg: Add default PCI config accessors implementation and
    initial support for related quirks.
  pci, acpi: Support for ACPI based PCI hostbridge init
  pci, acpi: Match PCI config space accessors against platfrom specific
    quirks.
  arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
    ARM64.

 arch/arm64/Kconfig                |  10 ++
 arch/arm64/kernel/pci.c           |  35 ------
 arch/ia64/Kconfig                 |   3 +
 arch/ia64/include/asm/pci.h       |   3 -
 arch/ia64/pci/pci.c               |  53 +++-----
 arch/x86/Kconfig                  |   7 ++
 arch/x86/include/asm/pci.h        |  10 --
 arch/x86/include/asm/pci_x86.h    |  28 +----
 arch/x86/pci/acpi.c               |  43 ++-----
 arch/x86/pci/common.c             |  10 --
 arch/x86/pci/irq.c                |  10 --
 arch/x86/pci/mmconfig-shared.c    | 250 ++++++--------------------------------
 arch/x86/pci/mmconfig_32.c        |  11 +-
 arch/x86/pci/mmconfig_64.c        |  67 +---------
 arch/x86/pci/numachip.c           |   1 +
 drivers/acpi/Makefile             |   1 +
 drivers/acpi/mcfg.c               | 203 +++++++++++++++++++++++++++++++
 drivers/acpi/pci_root.c           |   5 +-
 drivers/acpi/resource.c           |  12 +-
 drivers/pci/Kconfig               |  10 ++
 drivers/pci/Makefile              |   5 +
 drivers/pci/ecam.c                | 234 +++++++++++++++++++++++++++++++++++
 drivers/pci/host/Kconfig          |   6 +
 drivers/pci/host/Makefile         |   1 +
 drivers/pci/host/pci-host-acpi.c  | 138 +++++++++++++++++++++
 drivers/pci/pci.c                 |  29 ++++-
 drivers/pci/probe.c               |   5 +
 drivers/xen/pci.c                 |   7 +-
 include/asm-generic/vmlinux.lds.h |   7 ++
 include/linux/acpi.h              |   2 +
 include/linux/ecam.h              |  61 ++++++++++
 include/linux/pci-acpi.h          |  17 +++
 32 files changed, 817 insertions(+), 467 deletions(-)
 create mode 100644 drivers/acpi/mcfg.c
 create mode 100644 drivers/pci/ecam.c
 create mode 100644 drivers/pci/host/pci-host-acpi.c
 create mode 100644 include/linux/ecam.h

-- 
1.9.1

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

[toc] | [next] | [standalone]

#1293003 — [PATCH V2 12/23] pci, acpi: Move ACPI host bridge device companion assignment to core code.

Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
bridge initialization. They both use sysdata pill to pass down parent
device reference and both relay on NULL parent in pci_create_root_bus()
to validate sysdata content.

It looks hacky and prevent us from getting some frimware specific
info for PCI host controller e.g. bus domain number.
However, it seems we can overcome that blocker by passing down parent
device via pci_create_root_bus parameter (as the ACPI device type)
and using ACPI_COMPANION_SET in core code for ACPI boot method.
ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 drivers/acpi/pci_root.c | 5 ++++-
 drivers/pci/probe.c     | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..a65c8c2 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 
 	pci_acpi_root_add_resources(info);
 	pci_add_resource(&info->resources, &root->secondary);
-	bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
+
+	/* Root bridge device needs to be sure of parent ACPI type */
+	ACPI_COMPANION_SET(&device->dev, device);
+	bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
 				  sysdata, &info->resources);
 	if (!bus)
 		goto out_release_info;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 553a029..cad836f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	bridge->dev.parent = parent;
 	bridge->dev.release = pci_release_host_bridge_dev;
 	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
+	ACPI_COMPANION_SET(&bridge->dev,
+			   parent ? to_acpi_device_node(parent->fwnode) : NULL);
 	error = pcibios_root_bridge_prepare(bridge);
 	if (error) {
 		kfree(bridge);
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1293004 — [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources

From: Liu Jiang <jiang.liu@linux.intel.com>

Some architectures, such as IA64 and ARM64, have no instructions to
directly access PCI IO ports, so they map PCI IO ports into PCI MMIO
address space. Typically PCI host bridges on those architectures take
the responsibility to map (translate) PCI IO port transactions into
Memory-Mapped IO transactions. ACPI specification provides support
of such a usage case by using resource translation_offset.

But current ACPI resource parsing interface isn't neutral enough,
it still has some special logic for IA64. So refine the ACPI resource
parsing interface and IA64 code to neutrally handle translation_offset
by:
1) ACPI resource parsing interface doesn't do any translation, it just
   save the translation_offset to be used by arch code.
2) Arch code will do the mapping(translation) based on arch specific
   information. Typically it does:
2.a) Translate per PCI domain IO port address space into system global
   IO port address space.
2.b) Setup MMIO address mapping for IO ports.
void handle_io_resource(struct resource_entry *io_entry)
{
	struct resource *mmio_res;

	mmio_res = kzalloc(sizeof(*mmio_res), GFP_KERNEL);
	mmio_res->flags = IORESOURCE_MEM;
	mmio_res->start = io_entry->offset + io_entry->res->start;
	mmio_res->end = io_entry->offset + io_entry->res->end;
	insert_resource(&iomem_resource, mmio_res)

	base = map_to_system_ioport_address(entry);
	io_entry->offset = base;
	io_entry->res->start += base;
	io_entry->res->end += base;
}

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/ia64/pci/pci.c     | 26 ++++++++++++++++----------
 drivers/acpi/resource.c | 12 +++++-------
 2 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index c1e8ed5..d496976 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -154,7 +154,7 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 	struct resource_entry *iospace;
 	struct resource *resource, *res = entry->res;
 	char *name;
-	unsigned long base, min, max, base_port;
+	unsigned long base_mmio, base_port;
 	unsigned int sparse = 0, space_nr, len;
 
 	len = strlen(info->common.name) + 32;
@@ -172,12 +172,10 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 		goto free_resource;
 
 	name = (char *)(iospace + 1);
-	min = res->start - entry->offset;
-	max = res->end - entry->offset;
-	base = __pa(io_space[space_nr].mmio_base);
+	base_mmio = __pa(io_space[space_nr].mmio_base);
 	base_port = IO_SPACE_BASE(space_nr);
 	snprintf(name, len, "%s I/O Ports %08lx-%08lx", info->common.name,
-		 base_port + min, base_port + max);
+		 base_port + res->start, base_port + res->end);
 
 	/*
 	 * The SDM guarantees the legacy 0-64K space is sparse, but if the
@@ -190,19 +188,27 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 	resource = iospace->res;
 	resource->name  = name;
 	resource->flags = IORESOURCE_MEM;
-	resource->start = base + (sparse ? IO_SPACE_SPARSE_ENCODING(min) : min);
-	resource->end   = base + (sparse ? IO_SPACE_SPARSE_ENCODING(max) : max);
+	resource->start = base_mmio;
+	resource->end = base_mmio;
+	if (sparse) {
+		resource->start += IO_SPACE_SPARSE_ENCODING(res->start);
+		resource->end += IO_SPACE_SPARSE_ENCODING(res->end);
+	} else {
+		resource->start += res->start;
+		resource->end += res->end;
+	}
 	if (insert_resource(&iomem_resource, resource)) {
 		dev_err(dev,
 			"can't allocate host bridge io space resource  %pR\n",
 			resource);
 		goto free_resource;
 	}
+	resource_list_add_tail(iospace, &info->io_resources);
 
+	/* Adjust base of original IO port resource descriptor */
 	entry->offset = base_port;
-	res->start = min + base_port;
-	res->end = max + base_port;
-	resource_list_add_tail(iospace, &info->io_resources);
+	res->start += base_port;
+	res->end += base_port;
 
 	return 0;
 
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index cdc5c25..6578f68 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -190,8 +190,7 @@ static bool acpi_decode_space(struct resource_win *win,
 {
 	u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
 	bool wp = addr->info.mem.write_protect;
-	u64 len = attr->address_length;
-	u64 start, end, offset = 0;
+	u64 len = attr->address_length, offset = 0;
 	struct resource *res = &win->res;
 
 	/*
@@ -215,14 +214,13 @@ static bool acpi_decode_space(struct resource_win *win,
 	else if (attr->translation_offset)
 		pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
 			 attr->translation_offset);
-	start = attr->minimum + offset;
-	end = attr->maximum + offset;
 
 	win->offset = offset;
-	res->start = start;
-	res->end = end;
+	res->start = attr->minimum;
+	res->end = attr->maximum;
 	if (sizeof(resource_size_t) < sizeof(u64) &&
-	    (offset != win->offset || start != res->start || end != res->end)) {
+	    (offset != win->offset || attr->minimum != res->start ||
+	     attr->maximum != res->end)) {
 		pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
 			attr->minimum, attr->maximum);
 		return false;
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1293005 — [PATCH V2 01/23] x86, pci: Reorder logic of pci_mmconfig_insert() function

This patch is the first step for MMCONFIG refactoring process.

Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.

To get rid of that constraint, we reorder actions as follow:
1. sanity check for mmconfig region presence, if we already have such
region it doesn't make snese to alloc new mmconfig list entry
2. mmconfig entry allocation, no need to lock
3. insertion to iomem_resource has its own lock, no need to wrap it into mutex
4. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring) and needs another mmconfig
lookup to avoid race condition.

Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
 arch/x86/pci/mmconfig-shared.c | 101 +++++++++++++++++++++++------------------
 1 file changed, 58 insertions(+), 43 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..c8bb9b0 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -720,6 +720,38 @@ static int __init pci_mmcfg_late_insert_resources(void)
  */
 late_initcall(pci_mmcfg_late_insert_resources);
 
+static int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+	struct pci_mmcfg_region *cfg_conflict;
+	int err = 0;
+
+	mutex_lock(&pci_mmcfg_lock);
+	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+	if (cfg_conflict) {
+		if (cfg_conflict->end_bus < cfg->end_bus)
+			pr_info(FW_INFO "MMCONFIG for "
+				"domain %04x [bus %02x-%02x] "
+				"only partially covers this bridge\n",
+				cfg_conflict->segment, cfg_conflict->start_bus,
+				cfg_conflict->end_bus);
+		err = -EEXIST;
+		goto out;
+	}
+
+	if (pci_mmcfg_arch_map(cfg)) {
+		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
+		err = -ENOMEM;
+		goto out;
+	} else {
+		list_add_sorted(cfg);
+		pr_info("MMCONFIG at %pR (base %#lx)\n",
+			&cfg->res, (unsigned long)cfg->address);
+	}
+out:
+	mutex_unlock(&pci_mmcfg_lock);
+	return err;
+}
+
 /* Add MMCFG information for host bridges */
 int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			phys_addr_t addr)
@@ -734,63 +766,46 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 	if (start > end)
 		return -EINVAL;
 
-	mutex_lock(&pci_mmcfg_lock);
+	rcu_read_lock();
 	cfg = pci_mmconfig_lookup(seg, start);
-	if (cfg) {
-		if (cfg->end_bus < end)
-			dev_info(dev, FW_INFO
-				 "MMCONFIG for "
-				 "domain %04x [bus %02x-%02x] "
-				 "only partially covers this bridge\n",
-				  cfg->segment, cfg->start_bus, cfg->end_bus);
-		mutex_unlock(&pci_mmcfg_lock);
+	rcu_read_unlock();
+	if (cfg)
 		return -EEXIST;
-	}
 
-	if (!addr) {
-		mutex_unlock(&pci_mmcfg_lock);
+	if (!addr)
 		return -EINVAL;
-	}
 
-	rc = -EBUSY;
 	cfg = pci_mmconfig_alloc(seg, start, end, addr);
-	if (cfg == NULL) {
+	if (!cfg) {
 		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
-		rc = -ENOMEM;
-	} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+		return -ENOMEM;
+	}
+
+	rc = -EBUSY;
+	if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
 		dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
 			 &cfg->res);
-	} else {
-		/* Insert resource if it's not in boot stage */
-		if (pci_mmcfg_running_state)
-			tmp = insert_resource_conflict(&iomem_resource,
-						       &cfg->res);
-
-		if (tmp) {
-			dev_warn(dev,
-				 "MMCONFIG %pR conflicts with "
-				 "%s %pR\n",
-				 &cfg->res, tmp->name, tmp);
-		} else if (pci_mmcfg_arch_map(cfg)) {
-			dev_warn(dev, "fail to map MMCONFIG %pR.\n",
-				 &cfg->res);
-		} else {
-			list_add_sorted(cfg);
-			dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
-				 &cfg->res, (unsigned long)addr);
-			cfg = NULL;
-			rc = 0;
-		}
+		goto error;
 	}
 
-	if (cfg) {
-		if (cfg->res.parent)
-			release_resource(&cfg->res);
-		kfree(cfg);
+	/* Insert resource if it's not in boot stage */
+	if (pci_mmcfg_running_state)
+		tmp = insert_resource_conflict(&iomem_resource, &cfg->res);
+
+	if (tmp) {
+		dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+			 &cfg->res, tmp->name, tmp);
+		goto error;
 	}
 
-	mutex_unlock(&pci_mmcfg_lock);
+	rc = pci_mmconfig_inject(cfg);
+	if (!rc)
+		return 0;
 
+error:
+	if (cfg->res.parent)
+		release_resource(&cfg->res);
+	kfree(cfg);
 	return rc;
 }
 
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1293006 — [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init

Because of two patch series:
1. Jiang Liu's common interface to support PCI host bridge init
2. MMCONFIG refactoring (part of this patch set)
now we can think about generic ACPI based PCI host bridge driver
out of arch/ directory.

This driver use information from MCFG table (PCI config space regions)
and _CRS method (IO/irq resources) to initialize PCI hostbridge.

TBD: We are still not sure whether we should reassign resources
after PCI bus enumeration or trust firmware to do all that work for
us properly.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
 drivers/pci/host/Kconfig         |   6 ++
 drivers/pci/host/Makefile        |   1 +
 drivers/pci/host/pci-host-acpi.c | 138 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+)
 create mode 100644 drivers/pci/host/pci-host-acpi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba9..0e5e339 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -60,6 +60,12 @@ config PCI_HOST_GENERIC
 	  Say Y here if you want to support a simple generic PCI host
 	  controller, such as the one emulated by kvmtool.
 
+config PCI_HOST_GENERIC_ACPI
+	bool "Generic ACPI PCI host controller"
+	depends on ACPI && ARCH_PCI_HOST_GENERIC_ACPI
+	help
+	  Say Y here if you want to support generic ACPI PCI host controller.
+
 config PCIE_SPEAR13XX
 	bool "STMicroelectronics SPEAr PCIe controller"
 	depends on ARCH_SPEAR13XX
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..9117894 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
 obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
 obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
+obj-$(CONFIG_PCI_HOST_GENERIC_ACPI) += pci-host-acpi.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
diff --git a/drivers/pci/host/pci-host-acpi.c b/drivers/pci/host/pci-host-acpi.c
new file mode 100644
index 0000000..29175f5
--- /dev/null
+++ b/drivers/pci/host/pci-host-acpi.c
@@ -0,0 +1,138 @@
+/*
+ * ACPI based generic PCI host controller driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (C) 2015 Semihalf
+ * Author: Tomasz Nowicki <tn@semihalf.com>
+ */
+
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+#include <linux/of_address.h>
+#include <linux/pci.h>
+#include <linux/pci-acpi.h>
+
+static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+{
+	if (pci_dev_msi_enabled(dev))
+		return 0;
+
+	return acpi_pci_irq_enable(dev);
+}
+
+int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+	bridge->map_irq = pcibios_map_irq;
+	return 0;
+}
+
+static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
+{
+	pci_mmcfg_teardown_map(ci);
+	kfree(ci);
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+	struct resource_entry *entry, *tmp;
+	int ret;
+
+	ret = acpi_pci_probe_root_resources(ci);
+	if (ret <= 0)
+		return ret;
+
+	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+		struct resource *res = entry->res;
+
+		/*
+		 * TODO: need to move pci_register_io_range() function out
+		 * of drivers/of/address.c for both used by DT and ACPI
+		 */
+		if (res->flags & IORESOURCE_IO) {
+			resource_size_t cpu_addr = res->start + entry->offset;
+			resource_size_t pci_addr = res->start;
+			resource_size_t length = res->end - res->start;
+			unsigned long port;
+			int err;
+
+			err = pci_register_io_range(cpu_addr, length);
+			if (err) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			port = pci_address_to_pio(cpu_addr);
+			if (port == (unsigned long)-1) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			res->start = port;
+			res->end = port + length;
+			entry->offset = port - pci_addr;
+
+			if (pci_remap_iospace(res, cpu_addr) < 0)
+				resource_list_destroy_entry(entry);
+		}
+	}
+
+	return ret;
+}
+
+static struct acpi_pci_root_ops acpi_pci_root_ops = {
+	.init_info = pci_mmcfg_setup_map,
+	.release_info = pci_mcfg_release_info,
+	.prepare_resources = pci_acpi_root_prepare_resources,
+};
+
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+	int node = acpi_get_node(root->device->handle);
+	int domain = root->segment;
+	int busnum = root->secondary.start;
+	struct acpi_pci_root_info *info;
+	struct pci_bus *bus;
+
+	if (domain && !pci_domains_supported) {
+		pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
+	if (!info) {
+		dev_err(&root->device->dev,
+			"pci_bus %04x:%02x: ignored (out of memory)\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(domain, busnum);
+	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
+
+	/* After the PCI-E bus has been walked and all devices discovered,
+	 * configure any settings of the fabric that might be necessary.
+	 */
+	if (bus) {
+		struct pci_bus *child;
+		pci_bus_size_bridges(bus);
+		pci_bus_assign_resources(bus);
+
+		list_for_each_entry(child, &bus->children, node)
+			pcie_bus_configure_settings(child);
+	}
+
+	return bus;
+}
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1294781 — Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init

On Wednesday 16 December 2015 16:16:31 Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host bridge init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host bridge driver
> out of arch/ directory.
> 
> This driver use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
> 
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
> 
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> 

I think this code could better live in drivers/acpi/pci_root.c
along with all the related functions. It's not really a driver
by itself and cannot be a loadable module or built on other
architectures.

You can put all the code inside an #ifdef ARCH_PCI_HOST_GENERIC_ACPI
there.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295887 — Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init

On 18.12.2015 13:40, Arnd Bergmann wrote:
> On Wednesday 16 December 2015 16:16:31 Tomasz Nowicki wrote:
>> Because of two patch series:
>> 1. Jiang Liu's common interface to support PCI host bridge init
>> 2. MMCONFIG refactoring (part of this patch set)
>> now we can think about generic ACPI based PCI host bridge driver
>> out of arch/ directory.
>>
>> This driver use information from MCFG table (PCI config space regions)
>> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>>
>> TBD: We are still not sure whether we should reassign resources
>> after PCI bus enumeration or trust firmware to do all that work for
>> us properly.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Catalin Marinas <catalin.marinas@arm.com>
>> CC: Liviu Dudau <Liviu.Dudau@arm.com>
>> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
>> CC: Will Deacon <will.deacon@arm.com>
>> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>>
>
> I think this code could better live in drivers/acpi/pci_root.c
> along with all the related functions. It's not really a driver
> by itself and cannot be a loadable module or built on other
> architectures.
>
> You can put all the code inside an #ifdef ARCH_PCI_HOST_GENERIC_ACPI
> there.
>

Makes sense to me, thanks.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293007 — [PATCH V2 19/23] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.

We use generic accessors from access.c by default. However, we already
know platforms that need special handling while accessing to PCI config
space. These platforms will need different accessors set matched against
platform ID, domain, bus touple. Therefore we are going to add (in future)
DECLARE_ACPI_MCFG_FIXUP which will register platform specific custom
accessors. For now we let pci_mcfg_get_ops takes domain and bus arguments
and left some space for matching algorithm.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 drivers/acpi/mcfg.c      | 30 ++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h |  8 ++++++++
 2 files changed, 38 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dca4c4e..a9b2231 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -34,6 +34,36 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{
+	struct pci_mmcfg_region *cfg;
+
+	cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
+	if (cfg && cfg->virt)
+		return cfg->virt +
+			(PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
+			offset;
+	return NULL;
+}
+
+/* Default generic PCI config accessors */
+static struct pci_ops default_pci_mcfg_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = pci_generic_config_read,
+	.write = pci_generic_config_write,
+};
+
+struct pci_ops *pci_mcfg_get_ops(int domain, int bus)
+{
+	/*
+	 * TODO: Match against platform specific quirks and return
+	 * corresponding PCI config space accessor set.
+	 */
+
+	return &default_pci_mcfg_ops;
+}
+
 int __init acpi_parse_mcfg(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index c277415..3790197 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -82,10 +82,18 @@ void acpi_pci_remove_bus(struct pci_bus *bus);
 #ifdef	CONFIG_PCI_MMCONFIG
 int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
 void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
+struct pci_ops *pci_mcfg_get_ops(int domain, int bus);
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset);
 #else
 static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
 { return 0; }
 static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
+static inline struct pci_ops *pci_mcfg_get_ops(int domain, int bus)
+{ return NULL; }
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{ return NULL; }
 #endif
 
 #ifdef	CONFIG_ACPI_PCI_SLOT
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1293008 — [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

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 before PCI buses enumeration. Algorithm that overwrite accessors
matches against platform ID (DMI), domain and bus number, hopefully
enough for all cases. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and keep self contained.

example:

static const struct dmi_system_id yyy[] = {
	{
		.ident = "<Platform ident string>",
		.callback = <handler>,
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
			DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
			DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
		},
	},
	{ }
};

static struct pci_ops ecam_pci_ops = {
	.map_bus = pci_mcfg_dev_base,
	.read = xxxx_ecam_config_read,
	.write = xxxx_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(yyy, &ecam_pci_ops, <domain_nr>, <bus_nr>);

Note, that more custom actions can be done via DMI callback hook.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 drivers/acpi/mcfg.c               | 35 +++++++++++++++++++++++++++++++++--
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/ecam.h              | 17 +++++++++++++++++
 3 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index a9b2231..6d0194d 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/dmi.h>
 #include <linux/ecam.h>
 #include <linux/pci.h>
 #include <linux/pci-acpi.h>
@@ -34,6 +35,31 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
+
+static struct pci_ops *pci_mcfg_check_quirks(int domain, int bus_number)
+{
+	struct pci_mcfg_fixup *fixup;
+
+	fixup = __start_acpi_mcfg_fixups;
+	while (fixup < __end_acpi_mcfg_fixups) {
+		if (dmi_check_system(fixup->system) &&
+		    (fixup->domain == domain ||
+		     fixup->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (fixup->bus_number == bus_number ||
+		     fixup->bus_number == PCI_MCFG_BUS_ANY)) {
+			pr_info(PREFIX "Fixup applied: Platform [%s] domain [%d] bus number [%d]\n",
+				fixup->system->ident, fixup->domain,
+				fixup->bus_number);
+			return fixup->ops;
+		}
+		++fixup;
+	}
+
+	return NULL;
+}
+
 void __iomem *
 pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
 {
@@ -56,10 +82,15 @@ static struct pci_ops default_pci_mcfg_ops = {
 
 struct pci_ops *pci_mcfg_get_ops(int domain, int bus)
 {
+	struct pci_ops *pci_mcfg_ops_quirk;
+
 	/*
-	 * TODO: Match against platform specific quirks and return
-	 * corresponding PCI config space accessor set.
+	 * Match against platform specific quirks and return corresponding
+	 * PCI config space accessor set.
 	 */
+	pci_mcfg_ops_quirk = pci_mcfg_check_quirks(domain, bus);
+	if (pci_mcfg_ops_quirk)
+		return pci_mcfg_ops_quirk;
 
 	return &default_pci_mcfg_ops;
 }
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..c93fc97 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -298,6 +298,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/ecam.h b/include/linux/ecam.h
index e0f322e..1319fa8 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -20,6 +20,23 @@ struct pci_mmcfg_region {
 	bool hot_added;
 };
 
+struct pci_mcfg_fixup {
+	const struct dmi_system_id *system;
+	struct pci_ops *ops;
+	int domain;
+	int bus_number;
+};
+
+#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(system, ops, dom, bus)			\
+	static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
+	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ system, ops, dom, bus };
+
 struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
 struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
 						   int end, u64 addr);
-- 
1.9.1

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

[toc] | [prev] | [next] | [standalone]

#1295933 — RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

Hi Tomasz

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 16 December 2015 15:17
> To: bhelgaas@google.com; arnd@arndb.de; will.deacon@arm.com;
> catalin.marinas@arm.com; rjw@rjwysocki.net; hanjun.guo@linaro.org;
> Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; tglx@linutronix.de;
> 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; jchandra@broadcom.com; jcm@redhat.com; Tomasz
> Nowicki
> Subject: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors
> against platfrom specific quirks.
> 
> 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 before PCI buses enumeration. Algorithm that overwrite
> accessors matches against platform ID (DMI), domain and bus number,
> hopefully enough for all cases. All quirks can be defined using:
> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.

I've got a couple of comments/questions about this patch..

1) So according to this mechanism quirks would be supported only by 
   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
   with this but I don't know if this is OK in general as it would 
   narrow down the number of platforms that would be able to define
   the quirks...
   Lorenzo, Arnd what is your opinion here?

2) In the quirk mechanism you proposed, I see that the callback function
   allows to do some preparation work for the host bridge. For example in
   Hisilicon hip05 case we would need to read some values from the ACPI 
   table (see acpi_pci_root_hisi_add() function in 
   https://lkml.org/lkml/2015/12/3/426). 
   I am quite new to ACPI and I wonder if it is OK to add such "Packages"
   to the  PCI host bridge ACPI device...or maybe we need to declare a new
   one...?

Many Thanks

Gab

> 
> example:
> 
> static const struct dmi_system_id yyy[] = {
> 	{
> 		.ident = "<Platform ident string>",
> 		.callback = <handler>,
> 		.matches = {
> 			DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> 			DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> 			DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> 		},
> 	},
> 	{ }
> };
> 
> static struct pci_ops ecam_pci_ops = {
> 	.map_bus = pci_mcfg_dev_base,
> 	.read = xxxx_ecam_config_read,
> 	.write = xxxx_ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(yyy, &ecam_pci_ops, <domain_nr>, <bus_nr>);
> 
> Note, that more custom actions can be done via DMI callback hook.
> 
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
>  drivers/acpi/mcfg.c               | 35
> +++++++++++++++++++++++++++++++++--
>  include/asm-generic/vmlinux.lds.h |  7 +++++++
>  include/linux/ecam.h              | 17 +++++++++++++++++
>  3 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c index
> a9b2231..6d0194d 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -8,6 +8,7 @@
>   */
> 
>  #include <linux/acpi.h>
> +#include <linux/dmi.h>
>  #include <linux/ecam.h>
>  #include <linux/pci.h>
>  #include <linux/pci-acpi.h>
> @@ -34,6 +35,31 @@ int __weak raw_pci_write(unsigned int domain,
> unsigned int bus,
>  	return PCIBIOS_DEVICE_NOT_FOUND;
>  }
> 
> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[]; extern struct
> +pci_mcfg_fixup __end_acpi_mcfg_fixups[];
> +
> +static struct pci_ops *pci_mcfg_check_quirks(int domain, int
> +bus_number) {
> +	struct pci_mcfg_fixup *fixup;
> +
> +	fixup = __start_acpi_mcfg_fixups;
> +	while (fixup < __end_acpi_mcfg_fixups) {
> +		if (dmi_check_system(fixup->system) &&
> +		    (fixup->domain == domain ||
> +		     fixup->domain == PCI_MCFG_DOMAIN_ANY) &&
> +		    (fixup->bus_number == bus_number ||
> +		     fixup->bus_number == PCI_MCFG_BUS_ANY)) {
> +			pr_info(PREFIX "Fixup applied: Platform [%s] domain
> [%d] bus number [%d]\n",
> +				fixup->system->ident, fixup->domain,
> +				fixup->bus_number);
> +			return fixup->ops;
> +		}
> +		++fixup;
> +	}
> +
> +	return NULL;
> +}
> +
>  void __iomem *
>  pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> { @@ -56,10 +82,15 @@ static struct pci_ops default_pci_mcfg_ops = {
> 
>  struct pci_ops *pci_mcfg_get_ops(int domain, int bus)  {
> +	struct pci_ops *pci_mcfg_ops_quirk;
> +
>  	/*
> -	 * TODO: Match against platform specific quirks and return
> -	 * corresponding PCI config space accessor set.
> +	 * Match against platform specific quirks and return
> corresponding
> +	 * PCI config space accessor set.
>  	 */
> +	pci_mcfg_ops_quirk = pci_mcfg_check_quirks(domain, bus);
> +	if (pci_mcfg_ops_quirk)
> +		return pci_mcfg_ops_quirk;
> 
>  	return &default_pci_mcfg_ops;
>  }
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-
> generic/vmlinux.lds.h
> index c4bd0e2..c93fc97 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -298,6 +298,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/ecam.h b/include/linux/ecam.h index
> e0f322e..1319fa8 100644
> --- a/include/linux/ecam.h
> +++ b/include/linux/ecam.h
> @@ -20,6 +20,23 @@ struct pci_mmcfg_region {
>  	bool hot_added;
>  };
> 
> +struct pci_mcfg_fixup {
> +	const struct dmi_system_id *system;
> +	struct pci_ops *ops;
> +	int domain;
> +	int bus_number;
> +};
> +
> +#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(system, ops, dom, bus)
> 	\
> +	static const struct pci_mcfg_fixup
> __mcfg_fixup_##system##dom##bus\
> +	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),
> 	\
> +				aligned((sizeof(void *))))) =		\
> +	{ system, ops, dom, bus };
> +
>  struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
> struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
>  						   int end, u64 addr);
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295997 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On Monday 21 December 2015, Gabriele Paoloni wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of Tomasz Nowicki

> > 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 before PCI buses enumeration. Algorithm that overwrite
> > accessors matches against platform ID (DMI), domain and bus number,
> > hopefully enough for all cases. All quirks can be defined using:
> > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> 
> I've got a couple of comments/questions about this patch..
> 
> 1) So according to this mechanism quirks would be supported only by 
>    vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>    with this but I don't know if this is OK in general as it would 
>    narrow down the number of platforms that would be able to define
>    the quirks...
>    Lorenzo, Arnd what is your opinion here?

I'd rather not see the quirks in mainline at all, and only support
SBSA compliant machines, or require the BIOS to work around the hardware
quirks differently (e.g. by trapping config space access through secure
firmware, or going through an AML method to be defined). I'm certainly
ok with making it depend on SMBIOS if we are going to use something like this.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296267 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On Monday 21 December 2015, David Daney wrote:
> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> 
> > or require the BIOS to work around the hardware
> > quirks differently (e.g. by trapping config space access through secure
> > firmware, or going through an AML method to be defined).
> 
> Some systems don't seem to have this capability.  For example, in ARMv8 
> (A.K.A. arm64), I haven't been able to figure out how to trap these 
> accesses to EL3 for emulation.  The specification is 5700 pages long 
> though, so perhaps I missed that bit.

How about using AML then? This would be similar to what CHRP used with
RTAS calls to do PCI config space access.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296301 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On 12/21/2015 05:42 PM, Arnd Bergmann wrote:
> On Monday 21 December 2015, David Daney wrote:
>> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
>>> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>
>>> or require the BIOS to work around the hardware
>>> quirks differently (e.g. by trapping config space access through secure
>>> firmware, or going through an AML method to be defined).
>>
>> Some systems don't seem to have this capability.  For example, in ARMv8 
>> (A.K.A. arm64), I haven't been able to figure out how to trap these 
>> accesses to EL3 for emulation.  The specification is 5700 pages long 
>> though, so perhaps I missed that bit.

There isn't a way to directly trap to EL3 for emulation (caveat - there
might be some nasty hack with an SMMU that wouldn't be supportable). I
requested the implementation of a generic mechanism for LPC type
emulation (complete with "SMI" traps to EL3 for fixups) about 4 years
ago. That wouldn't have helped with this situation, but this was to be
on the radar afterward. However, on ARM, it is still early days with
respect to transparently trapping and emulating hardware workarounds.

> How about using AML then? This would be similar to what CHRP used with
> RTAS calls to do PCI config space access.

The best way to do it for now (IMO) is via a DMI quirk match and a
special method for the early SoCs that aren't implementing MMCONFIG
correctly. An effort is underway to correct that in third party IP, and
similar directly with the partners for future generations. So this
should not get "much" more out of hand than it sadly is so far. Once we
have a good upstream solution (which is vital) then it will be an error
and a pre-tapeout bug to not be able to boot an upstream kernel with
stock ACPI hostbridge working sans nasty quirks. Therefore, the sooner
this is upstream, the better it will be for everyone involved.

Jon.

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

[toc] | [prev] | [next] | [standalone]

#1296293 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can be presumed that compliant platforms will provide quirks via DMI.

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

> On Dec 21, 2015, at 09:11, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>> -----Original Message-----
>>> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>>> owner@vger.kernel.org] On Behalf Of Tomasz Nowicki
> 
>>> 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 before PCI buses enumeration. Algorithm that overwrite
>>> accessors matches against platform ID (DMI), domain and bus number,
>>> hopefully enough for all cases. All quirks can be defined using:
>>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
>> 
>> I've got a couple of comments/questions about this patch..
>> 
>> 1) So according to this mechanism quirks would be supported only by 
>>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>>   with this but I don't know if this is OK in general as it would 
>>   narrow down the number of platforms that would be able to define
>>   the quirks...
>>   Lorenzo, Arnd what is your opinion here?
> 
> I'd rather not see the quirks in mainline at all, and only support
> SBSA compliant machines, or require the BIOS to work around the hardware
> quirks differently (e.g. by trapping config space access through secure
> firmware, or going through an AML method to be defined). I'm certainly
> ok with making it depend on SMBIOS if we are going to use something like this.
> 
>    Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296616 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On 22.12.2015 00:10, Jon Masters wrote:
> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can be presumed that compliant platforms will provide quirks via DMI.
>

Thanks Jon for confirmation.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296656 — RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

Hi Jon, thanks for replying

> -----Original Message-----
> From: Jon Masters [mailto:jcm@redhat.com]
> Sent: 21 December 2015 23:11
> To: Arnd Bergmann
> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
> ddaney@caviumnetworks.com; tglx@linutronix.de; 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; jchandra@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
> it can be presumed that compliant platforms will provide quirks via DMI.

Ok so you completely clarified my question 1). Many Thanks for this

Gab

> 
> --
> Computer Architect | Sent from my 64-bit #ARM Powered phone
> 
> > On Dec 21, 2015, at 09:11, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> >>> -----Original Message-----
> >>> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> >>> owner@vger.kernel.org] On Behalf Of Tomasz Nowicki
> >
> >>> 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 before PCI buses enumeration. Algorithm that
> overwrite
> >>> accessors matches against platform ID (DMI), domain and bus number,
> >>> hopefully enough for all cases. All quirks can be defined using:
> >>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> >>
> >> I've got a couple of comments/questions about this patch..
> >>
> >> 1) So according to this mechanism quirks would be supported only by
> >>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
> >>   with this but I don't know if this is OK in general as it would
> >>   narrow down the number of platforms that would be able to define
> >>   the quirks...
> >>   Lorenzo, Arnd what is your opinion here?
> >
> > I'd rather not see the quirks in mainline at all, and only support
> > SBSA compliant machines, or require the BIOS to work around the
> > hardware quirks differently (e.g. by trapping config space access
> > through secure firmware, or going through an AML method to be
> > defined). I'm certainly ok with making it depend on SMBIOS if we are
> going to use something like this.
> >
> >    Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296886 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> Hi Jon, thanks for replying
> 
>> -----Original Message-----
>> From: Jon Masters [mailto:jcm@redhat.com]
>> Sent: 21 December 2015 23:11
>> To: Arnd Bergmann
>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
>> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
>> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
>> ddaney@caviumnetworks.com; tglx@linutronix.de; 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; jchandra@broadcom.com
>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>> accessors against platfrom specific quirks.
>>
>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>> it can be presumed that compliant platforms will provide quirks via DMI.
> 
> Ok so you completely clarified my question 1). Many Thanks for this

No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
in SBBR (I was lead author of one of the early drafts of that document)
was to make the experience ultimately equivalent across architectures.
We already know how to do quirks and handle platform deviations, and the
major Operating System vendors did not want to reinvent the wheel.

Jon.

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

[toc] | [prev] | [next] | [standalone]

#1296890 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -----Original Message-----
>>> From: Jon Masters [mailto:jcm@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
>>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
>>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
>>> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
>>> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
>>> ddaney@caviumnetworks.com; tglx@linutronix.de; 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; jchandra@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.

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

[toc] | [prev] | [next] | [standalone]

#1296943 — RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

> -----Original Message-----
> From: Jon Masters [mailto:jcm@redhat.com]
> Sent: 22 December 2015 16:45
> To: Gabriele Paoloni; Arnd Bergmann
> Cc: Tomasz Nowicki; bhelgaas@google.com; will.deacon@arm.com;
> catalin.marinas@arm.com; rjw@rjwysocki.net; hanjun.guo@linaro.org;
> Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
> ddaney@caviumnetworks.com; tglx@linutronix.de; 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; jchandra@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> On 12/22/2015 11:36 AM, Jon Masters wrote:
> > On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> >> Hi Jon, thanks for replying
> >>
> >>> -----Original Message-----
> >>> From: Jon Masters [mailto:jcm@redhat.com]
> >>> Sent: 21 December 2015 23:11
> >>> To: Arnd Bergmann
> >>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
> >>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
> >>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
> >>> okaya@codeaurora.org; jiang.liu@linux.intel.com;
> >>> Stefano.Stabellini@eu.citrix.com; robert.richter@caviumnetworks.com;
> >>> mw@semihalf.com; Liviu.Dudau@arm.com; ddaney@caviumnetworks.com;
> >>> tglx@linutronix.de; 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;
> >>> jchandra@broadcom.com
> >>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> >>> accessors against platfrom specific quirks.
> >>>
> >>> Sorry for top-posting. A quick note that SMBIOS3 is required by
> SBBR
> >>> so it can be presumed that compliant platforms will provide quirks
> via DMI.
> >>
> >> Ok so you completely clarified my question 1). Many Thanks for this
> >
> > No problem. One of the (many) reasons I pushed for requiring
> > SMBIOS/DMI in SBBR (I was lead author of one of the early drafts of
> > that document) was to make the experience ultimately equivalent
> across architectures.
> > We already know how to do quirks and handle platform deviations, and
> > the major Operating System vendors did not want to reinvent the wheel.
> 
> Additional: it is clear that more prescription is required to get the
> vendors onto the bandwagon that we have with other architectures (e.g.
> that other one). So there will be a Red Hat "ARM server whitepaper"
> coming in the early new year that will include the kind of "server 101"
> material we want to make sure people know. Things like making sure you
> implement and test PCIe correctly, handle backward compatibility (you
> will build hardware in the future that runs my existing OS release),
> design the hardware to allow for workarounds later, etc. I expect some
> other Operating System vendors to be involved in reviewing that.
> 
> Ultimately my objective is to make this whole thing dull and boring.
> You will get RHEL(SA)/upstream kernels and it will either boot or it
> will not. If it does not boot, vendor X screwed up their hardware. We
> know this story, it's been this way for over a decade already, and that
> is exactly how it is going to be with ARM servers shortly.

Ok got it.

Many Thanks

Gab

> 
> Jon.

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

[toc] | [prev] | [next] | [standalone]

#1296680 — Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

On 21.12.2015 12:47, Gabriele Paoloni wrote:
> 2) In the quirk mechanism you proposed, I see that the callback function
>     allows to do some preparation work for the host bridge. For example in
>     Hisilicon hip05 case we would need to read some values from the ACPI
>     table (see acpi_pci_root_hisi_add() function in
>     https://lkml.org/lkml/2015/12/3/426).
>     I am quite new to ACPI and I wonder if it is OK to add such "Packages"
>     to the  PCI host bridge ACPI device...or maybe we need to declare a new
>     one...?

I may miss sth so please correct me in that case.

https://lkml.org/lkml/2015/12/3/426 shows that you need special handling 
for root->secondary.start bus number only, right? So how about creating 
special MCFG region <rc-base:rc-base+rc-size> only for <segment,bus>. 
Like that:

[0008]                       Base Address : <rc-base>
[0002]               Segment Group Number : <segment>
[0001]                   Start Bus Number : <root->secondary.start>
[0001]                     End Bus Number : <root->secondary.start>
[0004]                           Reserved : 00000000


static const struct dmi_system_id hisi_quirk[] = {
	{
		.ident = "HiSi...",
		.matches = {
			DMI_MATCH(<whatever you need to match your platform>),
		},
	},
	{ }
};

static struct pci_ops hisi_ecam_pci_ops = {
	.map_bus = pci_mcfg_dev_base,
	.read = hisi_pcie_cfg_read,
	.write = hisi_pcie_cfg_write,
};

DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, &hisi_ecam_pci_ops,
			<segment>, <bus>);

With above code you can use your custom PCI config accessor only for 
that region.

Let me know if that is not enough for you.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web