Use devm_request_pci_bus_resources() to request host bridge window
resources instead of doing it by hand in the driver.

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

The switch is the only statement in the resource_list_for_each_entry()
loop, so remove unnecessary "continue" statements in the switch.  Remove
unnecessary "goto" statements and label.  Simplify checking for the
required non-prefetchable memory aperture.

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

Use devm_request_pci_bus_resources() to request host bridge window
resources instead of doing it by hand in the driver.

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

The switch is the only statement in the resource_list_for_each_entry()
loop, so remove unnecessary "continue" statements in the switch.  Simplify
checking for the required non-prefetchable memory aperture.  Inline
altera_pcie_release_of_pci_ranges(), which is only called once.

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

Use devm_request_pci_bus_resources() to request host bridge window
resources instead of doing it by hand in the driver.

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

Use dev_printk() when possible to make messages more useful.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Request host bridge window resources so they appear in ioport_resource and
iomem_resource and are reflected in /proc/ioports and /proc/iomem.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

of_pci_get_host_bridge_resources() allocates a list of resources for host
bridge windows.  If we fail after allocating that list, free it before we
return error.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Request host bridge window resources so they appear in ioport_resource and
iomem_resource and are reflected in /proc/ioports and /proc/iomem.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

of_pci_get_host_bridge_resources() allocates a list of resources for host
bridge windows.  If we fail after allocating that list, free it before we
return error.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Request host bridge window resources so they appear in ioport_resource and
iomem_resource and are reflected in /proc/ioports and /proc/iomem.

For example, the following entries did not previously appear in /proc/iomem:

  e180000000-e1ffffffff : /soc/pcie@1f2b0000
    e180000000-e182ffffff : PCI Bus 0000:01
      e180000000-e181ffffff : 0000:01:00.0
      e182000000-e1820fffff : 0000:01:00.0
      e182100000-e1821fffff : 0000:01:00.0
  f000000000-ffffffffff : /soc/pcie@1f2b0000
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

of_pci_get_host_bridge_resources() allocates a list of resources for host
bridge windows.  If we fail after allocating that list, free it before we
return error.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Request host bridge window resources so they appear in ioport_resource and
iomem_resource and are reflected in /proc/ioports and /proc/iomem.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The switch is the only statement in the resource_list_for_each_entry()
loop, so remove unnecessary "continue" statements in the switch.

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

Request host bridge window resources so they appear in ioport_resource and
iomem_resource and are reflected in /proc/ioports and /proc/iomem.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

of_pci_get_host_bridge_resources() allocates a list of resources for host
bridge windows.  If we fail after allocating that list, free it before we
return error.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Several host bridge drivers iterate through the list of bridge windows to
request resources.  Several others don't request the window resources at
all.

Add a devm_request_pci_bus_resources() interface to make it easier for
drivers to request all the window resources.  Export to GPL modules (from
Arnd Bergmann <arnd@arndb.de>).
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

b84106b4 ("PCI: Disable IO/MEM decoding for devices with non-compliant
BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
still try to size them, resulting in warnings like this on Broadwell-EP:

  pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]

Move the non-compliant BAR check from __pci_read_base() up to
pci_read_bases() so it applies to the expansion ROM BAR as well as
to BARs 0-5.

Note that direct callers of __pci_read_base(), like sriov_init(), will now
bypass this check.  We haven't had reports of devices with broken SR-IOV
BARs yet.

[bhelgaas: changelog]
Fixes: b84106b4 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: Andi Kleen <ak@linux.intel.com>

Resource flags are exposed to userspace via the sysfs "resource" file.
lspci reads the sysfs file to determine resource properties.

Add a "BAR Equivalent Indicator" flag so lspci can distinguish between
[virtual] and [enhanced] resources.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

No functional changes in this patch.

PCI I/O space mapping code does not depend on OF; therefore it can be moved
to PCI core code.  This way we will be able to use it, e.g., in ACPI PCI
code.
Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Liviu Dudau <Liviu.Dudau@arm.com>

Use functions provided by drivers/pci/ecam.h for mapping the config space
in drivers/pci/host/pci-host-common.c, and update its users to use 'struct
pci_config_window' and 'struct pci_ecam_ops'.

The changes are mostly to use 'struct pci_config_window' in place of
'struct gen_pci'.  Some of the fields of gen_pci were only used temporarily
and can be eliminated by using local variables or function arguments, these
are not carried over to struct pci_config_window.

pci-thunder-ecam.c and pci-thunder-pem.c are the only users of the
pci_host_common_probe function and the gen_pci structure; these have been
updated to use the new API as well.

The patch does not introduce any functional changes other than a very minor
one: with the new code, on 64-bit platforms, we do just a single ioremap
for the whole config space.
Signed-off-by: NJayachandran C <jchandra@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic
functions for accessing memory-mapped PCI config space.

The API is defined in drivers/pci/ecam.h and is written to replace the API
in drivers/pci/host/pci-host-common.h.  The file defines a new 'struct
pci_config_window' to hold the information related to a PCI config area and
its mapping.  This structure is expected to be used as sysdata for
controllers that have ECAM based mapping.

Helper functions are provided to setup the mapping, free the mapping and to
implement the map_bus method in 'struct pci_ops'
Signed-off-by: NJayachandran C <jchandra@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This renames pcibios_find_pci_bus() to pci_find_bus_by_node() to
avoid conflicts with those PCI subsystem weak function names, which
have prefix "pcibios". No logical changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

This renames pcibios_{add,remove}_pci_devices() to avoid conflicts
with names of the weak functions in PCI subsystem, which have the
prefix "pcibios". No logical changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-By: NAlistair Popple <alistair@popple.id.au>
Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

I'm trying to pass-through Broadcom BCM5720 NIC (Dell device 1f5b) on a
Dell R720 server.  Everything works fine when the target VM has only one
CPU, but SMP guests reboot when the NIC driver accesses PCI config space
with hv_pcifront_read_config()/hv_pcifront_write_config().  The reboot
appears to be induced by the hypervisor and no crash is observed.  Windows
event logs are not helpful at all ('Virtual machine ... has quit
unexpectedly').  The particular access point is always different and
putting debug between them (printk/mdelay/...) moves the issue further
away.  The server model affects the issue as well: on Dell R420 I'm able to
pass-through BCM5720 NIC to SMP guests without issues.

While I'm obviously failing to reveal the essence of the issue I was able
to come up with a (possible) solution: if explicit barriers are added to
hv_pcifront_read_config()/hv_pcifront_write_config() the issue goes away.
The essential minimum is rmb() at the end on _hv_pcifront_read_config() and
wmb() at the end of _hv_pcifront_write_config() but I'm not confident it
will be sufficient for all hardware.  I suggest the following barriers:

1) wmb()/mb() between choosing the function and writing to its space.
2) mb() before releasing the spinlock in both _hv_pcifront_read_config()/
   _hv_pcifront_write_config() to ensure that consecutive reads/writes to
  the space won't get re-ordered as drivers may count on that.

Config space access is not supposed to be performance-critical so these
explicit barriers should not cause any slowdown.

[bhelgaas: use Linux "barriers" terminology]
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJake Oshins <jakeo@microsoft.com>

We cache the PCI_EXP_SLTCAP_HPC bit in pci_dev->is_hotplug_bridge on device
probe, so there's no need to read it again on allocation of port service
devices.

No functional change intended.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add driver for the PCI Express Downstream Port Containment extended
capability.  DPC is an optional capability to contain uncorrectable errors
below a port.

For more information on DPC, please see PCI Express Base Specification
Revision 4, section 7.31, or view the PCI-SIG DPC ECN here:

  https://pcisig.com/sites/default/files/specification_documents/ECN_DPC_2012-02-09_finalized.pdf

When a DPC event is triggered, the hardware disables downstream links, so
the DPC driver schedules removal for all devices below this port.  This may
happen concurrently with a PCIe hotplug driver if enabled.  When all
downstream devices are removed and the link state transitions to disabled,
the DPC driver clears the DPC status and interrupt bits so the link may
retrain for a newly connected device.

[bhelgaas: clear (not set) DPC_CTL bits on remove, whitespace cleanup]
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Lukas Wunner <lukas@wunner.de>

Add the Downstream Port Containment (PCIE_PORT_SERVICE_DPC) portdrv service
type, available if the device has the DPC extended capability.

[bhelgaas: split to separate patch, changelog]
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The names of port service devices previously used one nibble to encode the
port type and another nibble to encode the service type.  We're about to
add a fifth service type, so change device names to use one *byte* to
encode the service type.

For example, a hotplug port service on a downstream bridge was previously
called "pcie24" and is now called "pcie204".  The "2" encodes the device
type (PCI_EXP_TYPE_DOWNSTREAM - 4), and the "4" (now "04") encodes the
service (PCIE_PORT_SERVICE_HP).

Based on Lukas Wunner's patch:
https://github.com/l1k/linux/commit/b688d6e4873ab082e5916b1a993bc1d38c6f4178

[bhelgaas: split to separate patch, expand changelog]
Based-on-patch-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Currently dw_pcie_setup_rc() configures memory base and memory limit in the
type1 configuration header for the root complex.  In doing so it uses the
CPU address (pp->mem_base) rather than the bus address (pp->mem_bus_addr).
This is wrong and it is useless since the configuration is overwritten
later on when pci_bus_assign_resources() is called.

Remove this configuration from dw_pcie_setup_rc().
Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NPratyush Anand <pratyush.anand@gmail.com>

Kernel hang is observed when pci-hyperv module is release with device
drivers still attached.  E.g., when I do 'rmmod pci_hyperv' with BCM5720
device pass-through-ed (tg3 module) I see the following:

 NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [rmmod:2104]
 ...
 Call Trace:
  [<ffffffffa0641487>] tg3_read_mem+0x87/0x100 [tg3]
  [<ffffffffa063f000>] ? 0xffffffffa063f000
  [<ffffffffa0644375>] tg3_poll_fw+0x85/0x150 [tg3]
  [<ffffffffa0649877>] tg3_chip_reset+0x357/0x8c0 [tg3]
  [<ffffffffa064ca8b>] tg3_halt+0x3b/0x190 [tg3]
  [<ffffffffa0657611>] tg3_stop+0x171/0x230 [tg3]
  ...
  [<ffffffffa064c550>] tg3_remove_one+0x90/0x140 [tg3]
  [<ffffffff813bee59>] pci_device_remove+0x39/0xc0
  [<ffffffff814a3201>] __device_release_driver+0xa1/0x160
  [<ffffffff814a32e3>] device_release_driver+0x23/0x30
  [<ffffffff813b794a>] pci_stop_bus_device+0x8a/0xa0
  [<ffffffff813b7ab6>] pci_stop_root_bus+0x36/0x60
  [<ffffffffa02c3f38>] hv_pci_remove+0x238/0x260 [pci_hyperv]

The problem seems to be that we report local resources release before
stopping the bus and removing devices from it and device drivers may try to
perform some operations with these resources on shutdown.  Move resources
release report after we do pci_stop_root_bus().
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJake Oshins <jakeo@microsoft.com>

I.MX6+ has a dedicated bit for resetting PCIe core, which should be used
instead of a regular reset sequence since using the latter will hang the
SoC.

This commit is based on c34068d48273e24d392d9a49a38be807954420ed from
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.gitTested-by: NGary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>

Use enumerated type instead of a boolean flag to specify the variant of
the PCIe IP block (6Q, 6SX, etc).  This patch has zero functional impact,
however it makes the code easier to extend for the case of more than 2
possible variants of an IP block (of which there are).

[bhelgaas: rewrap comment, remove extra blank line]
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>

Linux 4.5 introduced a behavioral change in device probing during the
suspend process with commit 013c074f ("PM / sleep: prohibit devices
probing during suspend/hibernation"): It defers device probing during the
entire suspend process, starting from the prepare phase and ending with the
complete phase.  A rule existed before that "we rely on subsystems not to
do any probing once a device is suspended" but it is enforced only now
(Alan Stern, https://lkml.org/lkml/2015/9/15/908).

This resulted in a WARN splat if a PCI device (e.g., Thunderbolt) is
plugged in while the system is asleep: Upon waking up, pciehp_resume()
discovers new devices in the resume phase and immediately tries to bind
them to a driver.  Since probing is now deferred, device_attach() returns
-EPROBE_DEFER, which provoked a WARN in pci_bus_add_device().

Linux 4.6-rc1 aggravates the situation with commit ab1a187b ("PCI:
Check device_attach() return value always"): If device_attach() returns a
negative value, pci_bus_add_device() now removes the sysfs and procfs
entries for the device and pci_bus_add_devices() subsequently locks up with
a BUG.  Even with the BUG fixed we're still in trouble because the device
remains on the deferred probing list even though its sysfs and procfs
entries are gone and its children won't be added.

Fix by not interpreting -EPROBE_DEFER as failure.  The device will be
probed eventually (through device_unblock_probing() in dpm_complete()) and
there is proper locking in place to avoid races (e.g., if devices are
unplugged again und thus deleted from the system before deferred probing
happens, I have tested this).  Also, those functions which dereference
dev->driver (e.g. pci_pm_*()) do contain proper NULL pointer checks.  So it
seems safe to ignore -EPROBE_DEFER.

Fixes: ab1a187b ("PCI: Check device_attach() return value always")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Alan Stern <stern@rowland.harvard.edu>

Previously when pci_bus_add_device() called device_attach() and it returned
a negative value, we emitted a WARN but carried on.

Commit ab1a187b ("PCI: Check device_attach() return value always"),
introduced in Linux 4.6-rc1, changed this to unwind all steps preceding
device_attach() and to not set dev->is_added = 1.

The latter leads to a BUG if pci_bus_add_device() was called from
pci_bus_add_devices().  Fix by not recursing to a child bus if
device_attach() failed for the bridge leading to it.

This can be triggered by plugging in a PCI device (e.g. Thunderbolt) while
the system is asleep.  The system locks up when woken because
device_attach() returns -EPROBE_DEFER.

Fixes: ab1a187b ("PCI: Check device_attach() return value always")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The 32-bit addressing modes in the I/O and Prefetchable Memory registers
are required to be read-only.  Since the underlying access method allows
them to be set, emulate their read-only nature and always set them.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The R-Car PCIe driver requires the use of IRQ domains for its MSI code:

  drivers/pci/host/pcie-rcar.c:635:9: error: implicit declaration of function 'irq_find_mapping' [-Werror=implicit-function-declaration]
  drivers/pci/host/pcie-rcar.c:666:8: error: implicit declaration of function 'irq_create_mapping' [-Werror=implicit-function-declaration]
  ...

Add a Kconfig select to ensure that the feature is always enabled.

This is not consistent with what the other drivers do at the moment, but I
have another patch that changes them to do it like this one, which is more
logical.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

This patch modifies all the callers of vmbus_mmio_allocate()
to call vmbus_mmio_free() instead of release_mem_region().
Signed-off-by: NJake Oshins <jakeo@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current XUSB pad controller bindings are insufficient to describe
PHY devices attached to USB controllers. New bindings have been created
to overcome these restrictions. As a side-effect each root port now is
assigned a set of PHY devices, one for each lane associated with the
root port. This has the benefit of allowing fine-grained control of the
power management for each lane.
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Marvell Armada 7K/8K SoCs integrate a PCIe controller from Synopsys.
Add a new driver that provides the small glue needed to use the existing
Designware driver to make it work on Marvell Armada 7K/8K SoCs.

The MSI support will be enabled at a later point.

[bhelgaas: use dev_dbg(), dw_pcie_wait_for_link()]
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>