* pci/resource:
  unicore32/PCI: Remove pci=firmware command line parameter handling
  ARM/PCI: Remove arch-specific pcibios_enable_device()
  ARM64/PCI: Remove arch-specific pcibios_enable_device()
  MIPS/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups
  ARM/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups
  PCI: generic: Claim bus resources on PCI_PROBE_ONLY set-ups
  PCI: Add generic pci_bus_claim_resources()
  alx: Use pci_(request|release)_mem_regions
  ethernet/intel: Use pci_(request|release)_mem_regions
  GenWQE: Use pci_(request|release)_mem_regions
  lpfc: Use pci_(request|release)_mem_regions
  NVMe: Use pci_(request|release)_mem_regions
  PCI: Add helpers to request/release memory and I/O regions
  PCI: Extending pci=resource_alignment to specify device/vendor IDs
  sparc/PCI: Implement pci_resource_to_user() with pcibios_resource_to_bus()
  powerpc/pci: Implement pci_resource_to_user() with pcibios_resource_to_bus()
  microblaze/PCI: Implement pci_resource_to_user() with pcibios_resource_to_bus()
  PCI: Unify pci_resource_to_user() declarations
  microblaze/PCI: Remove useless __pci_mmap_set_pgprot()
  powerpc/pci: Remove __pci_mmap_set_pgprot()
  PCI: Ignore write combining when mapping I/O port space

Merge branches 'pci/aspm', 'pci/dpc', 'pci/hotplug', 'pci/misc', 'pci/msi', 'pci/pm' and 'pci/virtualization' into next

* pci/aspm:
  PCI/ASPM: Remove redundant check of pcie_set_clkpm

* pci/dpc:
  PCI: Remove DPC tristate module option
  PCI: Bind DPC to Root Ports as well as Downstream Ports
  PCI: Fix whitespace in struct dpc_dev
  PCI: Convert Downstream Port Containment driver to use devm_* functions

* pci/hotplug:
  PCI: Allow additional bus numbers for hotplug bridges

* pci/misc:
  PCI: Include <asm/dma.h> for isa_dma_bridge_buggy
  PCI: Make bus_attr_resource_alignment static
  MAINTAINERS: Add file patterns for PCI device tree bindings
  PCI: Fix comment typo

* pci/msi:
  PCI/MSI: irqchip: Fix PCI_MSI dependencies

* pci/pm:
  PCI: pciehp: Ignore interrupts during D3cold
  PCI: Document connection between pci_power_t and hardware PM capability
  PCI: Add runtime PM support for PCIe ports
  ACPI / hotplug / PCI: Runtime resume bridge before rescan
  PCI: Power on bridges before scanning new devices
  PCI: Put PCIe ports into D3 during suspend
  PCI: Don't clear d3cold_allowed for PCIe ports
  PCI / PM: Enforce type casting for pci_power_t

* pci/virtualization:
  PCI: Add ACS quirk for Solarflare SFC9220
  PCI: Add DMA alias quirk for Adaptec 3805
  PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset
  PCI: Add function 1 DMA alias quirk for Marvell 88SE9182

* pci/arm64-acpi:
  ARM64: PCI: Support ACPI-based PCI host controller
  ARM64: PCI: Implement AML accessors for PCI_Config region
  ARM64: PCI: ACPI support for legacy IRQs parsing and consolidation with DT code
  ARM64: PCI: Add acpi_pci_bus_find_domain_nr()
  PCI: Factor DT-specific pci_bus_find_domain_nr() code out
  PCI: Refactor pci_bus_assign_domain_nr() for CONFIG_PCI_DOMAINS_GENERIC
  PCI/ACPI: Add generic MCFG table handling
  PCI/ACPI: Support I/O resources when parsing host bridge resources
  PCI: Add pci_unmap_iospace() to unmap I/O resources
  PCI: Add parent device field to ECAM struct pci_config_window
  PCI: Move ecam.h to linux/include/pci-ecam.h

The Solarflare SFC9220 apparently lacks an ACS capability, but does not
perform peer-to-peer between functions.  Add a quirk so we know about this
isolation.

[bhelgaas: changelog]
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

A user may hot add a switch requiring more than one bus to enumerate.  This
previously required a system reboot if BIOS did not sufficiently pad the
bus resource, which they frequently don't do.

Add a kernel parameter so a user can specify the minimum number of bus
numbers to reserve for a hotplug bridge's subordinate buses so rebooting
won't be necessary.

The default is 1, which is equivalent to previous behavior.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Change the Downstream Port Containment config type from tristate to bool.

The driver doesn't automatically load based on any rules, so it needs to be
built-in in order to bind to devices it needs to drive.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCIe port type values are not flags, so OR'ing them is not correct.
Previously the result was equivalent to PCIe Downstream Ports, so we were
missing binding to DPC-capable Root Ports.

Change the type to 'any' so we can bind to both port types.  While this
will cause the code to check Upstream Ports, the driver won't claim them
since they are not DPC-capable.
Reported-by: Alexander Antonov <alexanderx.v.antonov@intel.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Mika Westerberg <mika.westerberg@linux.intel.com>

Add a DMA alias quirk for the Adaptec 3805, just like the 3405 quirk added
in commit d3d2ab43 ("PCI: Add DMA alias quirk for Adaptec 3405").

Link: https://www.redhat.com/archives/vfio-users/2016-July/msg00046.htmlSigned-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

At least on arm, <asm/dma.h> does not get included when building
drivers/pci/pci.o.  This causes the following build warning which can be
fixed by including <asm/dma.h>:

  drivers/pci/pci.c:37:5: warning: symbol 'isa_dma_bridge_buggy' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Remove support for the "pci=firmware" command line parameter, which was
way to keep the kernel from changing any PCI BAR assignments.  This was
copied from ARM, but is not actually needed on unicore32.

The corresponding ARM support was removed by 903589ca ("ARM: 8554/1:
kernel: pci: remove pci=firmware command line parameter handling").
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from
firmware.  Previously we did not insert those resources into the resource
tree, so we had to skip pci_enable_resources() because it fails if
resources are not in the resource tree.

Now that we *do* insert resources even when PCI_PROBE_ONLY is set, we no
longer need the ARM-specific pcibios_enable_device().  Remove it so we
use the generic version.

[bhelgaas: changelog]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Russell King <linux@arm.linux.org.uk>

On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from
firmware.  Previously we did not insert those resources into the resource
tree, so we had to skip pci_enable_resources() because it fails if
resources are not in the resource tree.

Now that we *do* insert resources even when PCI_PROBE_ONLY is set, we no
longer need the ARM64-specific pcibios_enable_device().  Remove it so we
use the generic version.

[bhelgaas: changelog]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
but when PCI_PROBE_ONLY is set, we treat those resources as immutable and
don't call pci_bus_assign_resources(), so the resources aren't put in the
resource tree.

When the resources aren't in the tree, they don't show up in /proc/iomem,
we can't detect conflicts, and we need special cases elsewhere for
PCI_PROBE_ONLY or resources without a parent pointer.

Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.

If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix
the conflicts.  Previously we didn't notice the conflicts, but now we will,
which may expose new failures.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
but when PCI_PROBE_ONLY is set, we treat those resources as immutable and
don't call pci_bus_assign_resources(), so the resources aren't put in the
resource tree.

When the resources aren't in the tree, they don't show up in /proc/iomem,
we can't detect conflicts, and we need special cases elsewhere for
PCI_PROBE_ONLY or resources without a parent pointer.

Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.

If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix
the conflicts.  Previously we didn't notice the conflicts, but now we will,
which may expose new failures.

[bhelgaas: changelog, add resource comment, remove size/assign comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Russell King <linux@armlinux.org.uk>

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
but when PCI_PROBE_ONLY is set, we treat those resources as immutable and
don't call pci_bus_assign_resources(), so the resources aren't put in the
resource tree.

When the resources aren't in the tree, they don't show up in /proc/iomem,
we can't detect conflicts, and we need special cases elsewhere for
PCI_PROBE_ONLY or resources without a parent pointer.

Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.

If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix
the conflicts.  Previously we didn't notice the conflicts, but now we will,
which may expose new failures.

[bhelgaas: changelog, summarize comment]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: David Daney <david.daney@cavium.com>

All PCI resources (bridge windows and BARs) should be inserted in the
iomem_resource and ioport_resource trees so we know what space is occupied
and what is available for other devices.  There's nothing arch-specific
about this, but it is currently done by arch-specific code.

Add a generic pci_bus_claim_resources() interface so we can migrate away
from the arch-specific code.

[bhelgaas: changelog]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Yinghai Lu <yinghai@kernel.org>

Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
at hand, use it in the ethernet drivers.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Jay Cliburn <jcliburn@gmail.com>
CC: Chris Snook <chris.snook@gmail.com>
CC: David S. Miller <davem@davemloft.net>

Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
at hand, use it in the Intel ethernet drivers.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: David S. Miller <davem@davemloft.net>

Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
at hand, use it in the genwqe driver.

[bhelgaas: fix build issues]
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Frank Haverkamp <haver@linux.vnet.ibm.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
at hand, use it in the lpfc driver.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Dick Kennedy <dick.kennedy@broadcom.com>
CC: James Smart <james.smart@avagotech.com>
CC: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
CC: Martin K. Petersen <martin.petersen@oracle.com>

Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
at hand, use it in the NVMe driver.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Keith Busch <keith.busch@intel.com>
CC: Jens Axboe <axboe@fb.com>

Add helpers to request and release a device's memory or I/O regions.

With these helpers in place, one does not need to select a device's memory
or I/O regions with pci_select_bars() prior to requesting or releasing
them.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>

Some uio-based PCI drivers, e.g., uio_cif do not work if the assigned PCI
memory resources are not page aligned.

By using the kernel option "pci=resource_alignment" it is possible to force
single PCI boards to use page alignment for their memory resources.
However, this is fairly cumbersome if several of these boards are in use
as the specification of the cards has to be done via PCI bus/slot/function
number which might change, e.g., by adding another board.

Extend the kernel option "pci=resource_alignment" to allow specification of
relevant devices via PCI device/vendor (and subdevice/subvendor) IDs.  The
specification of the devices via device/vendor is indicated by a leading
string "pci:" as argument to "pci=resource_alignment".  The format of the
specification is pci:<vendor>:<device>[:<subvendor>:<subdevice>]
Signed-off-by: Mathias Koehrer <mathias.koehrer@etas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Remove unnecessary spaces before tabs.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Keith Busch <keith.busch@intel.com>

Use the device resource management (devm) interfaces so we don't need to
explicitly release resources on failure paths or when the driver is
removed.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Keith Busch <keith.busch@intel.com>

If a hotplug port is suspended to D3cold, its slot status register cannot
be read.  If that hotplug port happens to share its IRQ with other devices,
whenever an interrupt occurs for one of these devices, pciehp logs a
"no response from device" message and tries to read the PCI_EXP_SLTSTA
register, even though we know that will fail.

Ignore interrupts while we're in D3cold.

[bhelgaas: changelog]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The dev.pme_support field, pci_pm_init(), pci_pme_capable(), and
pci_raw_set_power_state() depend on the fact that the pci_power_t values
(PCI_D0, PCI_D1, etc.) match the definition of the Capabilities PME_Support
and the Control/Status PowerState fields in the Power Management capability
(see PCI Bus Power Management spec r1.2, sec 3.2.3).

Add a note to this effect at the pci_power_t typedef.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files.  On sparc, these are PCI bus addresses, i.e., raw BAR values.

Previously pci_resource_to_user() computed the user address by
subtracting either pbm->io_space.start or pbm->mem_space.start from the
resource start.

We've already told the PCI core about those offsets here:

  pci_scan_one_pbm()
    pci_add_resource_offset(&resources, &pbm->io_space, pbm->io_space.start);
    pci_add_resource_offset(&resources, &pbm->mem_space, pbm->mem_space.start);
    pci_add_resource_offset(&resources, &pbm->mem64_space, pbm->mem_space.start);

so pcibios_resource_to_bus() knows how to do that translation.

No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>

"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files.  For I/O port resources on powerpc, these are PCI bus addresses,
i.e., raw BAR values.

Previously pci_resource_to_user() computed the user address by subtracting
"hose->io_base_virt - _IO_BASE" from the resource start:

  pci_resource_to_user()
    if (IO)
      offset = (unsigned long)hose->io_base_virt - _IO_BASE;
    *start = rsrc->start - offset;

We've already told the PCI core about that "hose->io_base_virt - _IO_BASE"
offset:

  pcibios_setup_phb_resources()
    res = &hose->io_resource;
    offset = pcibios_io_space_offset();
    /* i.e., "offset = hose->io_base_virt - _IO_BASE" */
    pci_add_resource_offset(resources, res, offset);

so pcibios_resource_to_bus() knows how to do that translation.

No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>

"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files.  For I/O port resources on microblaze, these are PCI bus addresses,
i.e., raw BAR values.

Previously pci_resource_to_user() computed the user address by subtracting
"hose->io_base_virt - _IO_BASE" from the resource start:

  pci_resource_to_user()
    if (IO)
      offset = (unsigned long)hose->io_base_virt - _IO_BASE;
    *start = rsrc->start - offset;

We've already told the PCI core about that "hose->io_base_virt - _IO_BASE"
offset:

  pcibios_setup_phb_resources()
    res = &hose->io_resource;
    pci_add_resource_offset(resources, res, hose->io_base_virt - _IO_BASE);

so pcibios_resource_to_bus() knows how to do that translation.

No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>

Replace the pci_resource_to_user() declarations in each arch that defines
HAVE_ARCH_PCI_RESOURCE_TO_USER with a single one in linux/pci.h.

Change the MIPS static inline implementation to a non-inline version so the
static inline doesn't conflict with the new non-static linux/pci.h
declaration.

No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The microblaze __pci_mmap_set_pgprot() was apparently copied from powerpc,
where it computes either an uncacheable pgprot_t or a write-combining one.
But on microblaze, we always use the regular uncacheable pgprot_t.

Remove the useless code in __pci_mmap_set_pgprot() and inline it at the
only call site.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>

The powerpc-specific __pci_mmap_set_pgprot() does two things:

  1) Disables write combining for I/O port space mappings

     This only affects procfs mappings.  The pci_mmap_resource() sysfs path
     only requests write combining for resources with IORESOURCE_PREFETCH
     set, which doesn't include I/O resources.

     The only way to request write combining for I/O port space mappings
     was via the PCIIOC_WRITE_COMBINE ioctl and the proc_bus_pci_mmap()
     path, and we recently changed that path to ignore write combining for
     I/O, so this code in powerpc is no longer needed.

  2) Automatically enables write combining for mappings of prefetchable
     resources, even if not requested by the user

     Both procfs (via PCIIOC_MMAP_IS_MEM and PCIIOC_WRITE_COMBINE ioctls)
     and sysfs (via "resourceN_wc" files, which are created for resources
     with IORESOURCE_PREFETCH) provide ways for the user to map PCI memory
     space with write combining.

     Users that desire write combining should use one of those ways instead
     of relying on powerpc-specific behavior.

Remove the powerpc-specific __pci_mmap_set_pgprot().

The user-visible effect of this change is that powerpc users mapping
prefetchable PCI memory space via procfs without PCIIOC_WRITE_COMBINE or
via sysfs "resourceN" (not "resourceN_wc") will get regular uncacheable
mappings instead of the write combining mappings they used to get.

The new behavior matches the behavior on all other arches that support
write combining mapping.

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI exposes files like /proc/bus/pci/00/00.0 in procfs.  These files
support operations like this:

  ioctl(fd, PCIIOC_MMAP_IS_IO);           # request I/O port space
  ioctl(fd, PCIIOC_WRITE_COMBINE, 1);     # request write-combining
  mmap(fd, ...)

Write combining is useful on PCI memory space, but I don't think it makes
sense on PCI I/O port space.

We *could* change proc_bus_pci_ioctl() to make it impossible to set
mmap_state == pci_mmap_io and write_combine at the same time, but that
would break the following sequence, which is currently legal:

  mmap(fd, ...)                           # default is I/O, non-combining
  ioctl(fd, PCIIOC_WRITE_COMBINE, 1);     # request write-combining
  ioctl(fd, PCIIOC_MMAP_IS_MEM);          # request memory space
  mmap(fd, ...)                           # get write-combining mapping

Ignore the write-combining flag when mapping I/O port space.

This patch should have no functional effect, based on this analysis of all
implementations of pci_mmap_page_range():

  - ia64 mips parisc sh unicore32 x86 do not support mapping of I/O port
    space at all.

  - arm cris microblaze mn10300 sparc xtensa support mapping of I/O port
    space, but ignore the write_combine argument to pci_mmap_page_range().

  - powerpc supports mapping of I/O port space and uses write_combine, and
    it disables write combining for I/O port space in
    __pci_mmap_set_pgprot().

This patch makes it possible to remove __pci_mmap_set_pgprot() from
powerpc, which simplifies that path.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The PCI_MSI symbol is used inconsistently throughout the tree, with some
drivers using 'select' and others using 'depends on', or using conditional
selects.  This keeps causing problems; the latest one is a result of
ARCH_ALPINE using a 'select' statement to enable its platform-specific MSI
driver without enabling MSI:

  warning: (ARCH_ALPINE) selects ALPINE_MSI which has unmet direct dependencies (PCI && PCI_MSI)
  drivers/irqchip/irq-alpine-msi.c:104:15: error: variable 'alpine_msix_domain_info' has initializer but incomplete type
   static struct msi_domain_info alpine_msix_domain_info = {
		 ^~~~~~~~~~~~~~~
  drivers/irqchip/irq-alpine-msi.c:105:2: error: unknown field 'flags' specified in initializer
    .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
    ^
  drivers/irqchip/irq-alpine-msi.c:105:11: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function)
    .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
	     ^~~~~~~~~~~~~~~~~~~~~~~~

There is little reason to enable PCI support for a platform that uses MSI
but then leave MSI disabled at compile time.

Select PCI_MSI from irqchips that implement MSI, and make PCI host bridges
that use MSI on ARM depend on PCI_MSI_IRQ_DOMAIN.

For all three architectures that support PCI_MSI_IRQ_DOMAIN (ARM, ARM64,
X86), enable it by default whenever MSI is enabled.

[bhelgaas: changelog, omit crypto config change]
Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>

Add back runtime PM support for PCIe ports that was removed by
fe9a743a ("PCI/PM: Drop unused runtime PM support code for PCIe
ports").

We cannot enable it automatically for all ports since there have been
problems previously [1].  In summary suspended PCIe ports were not able
to deal with ACPI-based hotplug reliably.  One reason why this might happen
is the fact that when a PCIe port is powered down, config space access to
the devices behind the port is not possible.  If the BIOS hotplug SMI
handler assumes the port is always in D0 it will not be able to find the
hotplugged devices.  To be on the safe side only enable runtime PM if the
port does not claim to support hotplug.

For PCIe ports not using hotplug, we enable and allow runtime PM
automatically.  Since 'bridge_d3' can be changed any time we check this in
driver ->runtime_idle() and ->runtime_suspend() and only allow runtime
suspend if the flag is still set.  Use autosuspend with default of 100ms
idle time to prevent the port from repeatedly suspending and resuming on
continuous configuration space access of devices behind the port.

The actual power transition to D3 and back is handled in the PCI core.

Idea to automatically unblock (allow) runtime PM for PCIe ports came from
Dave Airlie.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=53811

This includes a fix for lockdep issue reported by Valdis Kletnieks.
Tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If a PCI bridge (or PCIe port) that is runtime suspended gets an ACPI
hotplug event, such as BUS_CHECK we need to make sure it is resumed before
devices below the bridge are re-scanned. Otherwise the devices behind the
port are not accessible and will be treated as hot-unplugged.

To fix this, resume PCI bridges from runtime suspend while rescanning.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

When a PCI device is removed through sysfs interface, the upstream bridge
(PCIe port) can be runtime suspended if it was the last device on that bus.
Now, if the bridge is in D3 we cannot find devices below the bridge
anymore.  For example following fails to find the removed device again:

  # echo 1 > /sys/bus/pci/devices/0000:00:01.0/0000:01:00.0/remove
  # echo 1 > /sys/bus/pci/devices/0000:00:01.0/rescan

Where 0000:00:01.0 is the bridge device.

In order to be able to rescan devices below the bridge add
pm_runtime_get_sync()/pm_runtime_put() calls to pci_scan_bridge().  This
should keep bridges powered on while their children devices are being
scanned.
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently the Linux PCI core does not touch power state of PCI bridges and
PCIe ports when system suspend is entered.  Leaving them in D0 consumes
power unnecessarily and may prevent the CPU from entering deeper C-states.

With recent PCIe hardware we can power down the ports to save power given
that we take into account few restrictions:

  - The PCIe port hardware is recent enough, starting from 2015.

  - Devices connected to PCIe ports are effectively in D3cold once the port
    is transitioned to D3 (the config space is not accessible anymore and
    the link may be powered down).

  - Devices behind the PCIe port need to be allowed to transition to D3cold
    and back.  There is a way both drivers and userspace can forbid this.

  - If the device behind the PCIe port is capable of waking the system it
    needs to be able to do so from D3cold.

This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
flag is set and cleared by the PCI core whenever there is a change in power
management state of any of the devices behind the PCIe port.  When system
later on is suspended we only need to check this flag and if it is true
transition the port to D3 otherwise we leave it in D0.

Also provide override mechanism via command line parameter
"pcie_port_pm=[off|force]" that can be used to disable or enable the
feature regardless of the BIOS manufacturing date.
Tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The PCI core skips bridges and ports when the system is suspended.  The PCI
core checks return value of pci_has_subordinate() in pci_pm_suspend_noirq()
to skip all devices where it is non-zero (which means PCI bridges and PCIe
ports).

Since PCIe ports are never suspended in the first place, there is no need
to set d3cold_allowed for them.
Tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>