Users may request additional alignment of PCI resources, e.g., to align
BARs on page boundaries so they can be shared with guests via VFIO.  This
of course may require reallocation if firmware has already assigned the
BARs with smaller alignments.

If the platform has requested PCI_PROBE_ONLY, we should never change any
PCI BARs, so we can't provide any additional alignment.  Also, if a BAR is
marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
firmware depends on the current BAR value, we can't change the alignment.

In these cases, log a message and ignore the user's alignment requests.

[bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
Signed-off-by: NYongji Xie <xyjxie@linux.vnet.ibm.com>
Signed-off-by: NBjorn 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: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When assign new PCI platform PM operations check for all mandatory fields to
prevent NULL pointer dereference.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.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: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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: NMathias Koehrer <mathias.koehrer@etas.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.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: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The symbol bus_attr_resource_alignment is not exported or declared
elsewhere, so make it static to fix the following warning:

  drivers/pci/pci.c:4900:1: warning: symbol 'bus_attr_resource_alignment' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Extend pci_bus_find_domain_nr() so it can find the domain from either:

  - ACPI, via the new acpi_pci_bus_find_domain_nr() interface, or
  - DT, via of_pci_bus_find_domain_nr()

Note that this is only used for CONFIG_PCI_DOMAINS_GENERIC=y, so it does
not affect x86 or ia64.

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pci_bus_find_domain_nr() retrieves the host bridge domain number in a
DT-specific way.  Rename it to of_pci_bus_find_domain_nr() to reflect that,
so we can add a corresponding function for ACPI.

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Instead of assigning bus->domain_nr inside pci_bus_assign_domain_nr(),
return the domain and let the caller do the assignment.  Rename
pci_bus_assign_domain_nr() to pci_bus_find_domain_nr() to reflect this.

No functional change intended.

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Add pci_unmap_iospace() to undo what pci_remap_iospace() did.

This is needed to support hotplug removal of host bridges that use
pci_remap_iospace().

[bhelgaas: changelog]
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.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>

The original thought was that if a device implemented ACS, then surely
we want to use that... well, it turns out that devices can make an ACS
capability so broken that we still need to fall back to quirks.

Reverse the order of ACS enabling to give quirks first shot at it.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Solve IOMMU support issues with PCIe non-transparent bridges that use
Requester ID look-up tables (RID-LUT), e.g., the PEX8733.

The NTB connects devices in two independent PCI domains.  Devices separated
by the NTB are not able to discover each other.  A PCI packet being
forwared from one domain to another has to have its RID modified so it
appears on correct bus and completions are forwarded back to the original
domain through the NTB.  The RID is translated using a preprogrammed table
(LUT) and the PCI packet propagates upstream away from the NTB.  If the
destination system has IOMMU enabled, the packet will be discarded because
the new RID is unknown to the IOMMU.  Adding a DMA alias for the new RID
allows IOMMU to properly recognize the packet.

Each device behind the NTB has a unique RID assigned in the RID-LUT.  The
current DMA alias implementation supports only a single alias, so it's not
possible to support mutiple devices behind the NTB when IOMMU is enabled.

Enable all possible aliases on a given bus (256) that are stored in a
bitset.  Alias devfn is directly translated to a bit number.  The bitset is
not allocated for devices that have no need for DMA aliases.

More details can be found in the following article:
http://www.plxtech.com/files/pdf/technical/expresslane/RTC_Enabling%20MulitHostSystemDesigns.pdfSigned-off-by: NJacek Lawrynowicz <jacek.lawrynowicz@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Acked-by: NJoerg Roedel <jroedel@suse.de>

One of the quirks that adds DMA aliases logs an informational message in
dmesg.  Move that to pci_add_dma_alias() so all users log the message
consistently.  No functional change intended (except extra message).
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

Add a pci_add_dma_alias() interface to encapsulate the details of adding an
alias.  No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

Fix spelling of "initalization".

[bhelgaas: also fix pci/pci.c]
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some devices take longer than the spec indicates to return from FLR reset,
a notable case of this is Intel integrated graphics (IGD), which can often
take an additional 300ms powering down an attached LCD panel as part of the
FLR.  Allow devices up to 1000ms, testing every 100ms whether the second
dword of config space is read as -1.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pci_create_root_bus() passes a "parent" pointer to
pci_bus_assign_domain_nr().  When CONFIG_PCI_DOMAINS_GENERIC is defined,
pci_bus_assign_domain_nr() dereferences that pointer.  Many callers of
pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
pointer dereference error.

7c674700 ("PCI: Move domain assignment from arm64 to generic code")
moved the "parent" dereference from arm64 to generic code.  Only arm64 used
that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
always supplied a valid "parent" pointer.  Other arches supplied NULL
"parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
used a no-op version of pci_bus_assign_domain_nr().

8c7d1474 ("ARM/PCI: Move to generic PCI domains") defined
CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
pci_common_init(), which supplies a NULL "parent" pointer.
These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
with a NULL pointer dereference like this while probing PCI:

  Unable to handle kernel NULL pointer dereference at virtual address 000000a4
  PC is at pci_bus_assign_domain_nr+0x10/0x84
  LR is at pci_create_root_bus+0x48/0x2e4
  Kernel panic - not syncing: Attempted to kill init!

[bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
Fixes: 8c7d1474 ("ARM/PCI: Move to generic PCI domains")
Fixes: 7c674700 ("PCI: Move domain assignment from arm64 to generic code")
Signed-off-by: NKrzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: stable@vger.kernel.org	# v4.0+

Christoph added a generic include/linux/pci-dma-compat.h, so now there's
one place with most of the PCI DMA interfaces.  Move more PCI DMA-related
things there:

  - The PCI_DMA_* direction constants from linux/pci.h
  - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
    CONFIG_PCI implementations from drivers/pci/pci.c
  - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
    !CONFIG_PCI stubs from linux/pci.h
  - The pci_set_dma_mask() and pci_set_consistent_dma_mask()
    !CONFIG_PCI stubs from linux/pci.h
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

include/asm-generic/pci-bridge.h is now empty, so remove every #include of
it.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com> (arm64)

Use to_pci_dev() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix all whitespace issues (missing or needed whitespace) in all files in
drivers/pci.  Code is compiled with allyesconfig before and after code
changes and objects are recorded and checked with objdiff and they are not
changed after this commit.
Signed-off-by: NBogicevic Sasa <brutallesale@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The pci_platform_pm_ops structure is never modified, so declare it as
const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

An Enhanced Allocation Capability entry with BEI 0 fills in
dev->resource[0] just like a real BAR 0 would, but non-EA experts might not
connect "EA - BEI 0" with BAR 0.

Decode the EA jargon a little bit, e.g., change this:

  pci 0002:01:00.0: EA - BEI  0, Prop 0x00: [mem 0x84300000-0x84303fff]

to this:

  pci 0002:01:00.0: BAR 0: [mem 0x84300000-0x84303fff] (from Enhanced Allocation, properties 0x00)
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Expand bitmask #defines completely.  This puts the shift in the code
instead of in the #define, but it makes it more obvious in the header file
how fields in the register are laid out.

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

SR-IOV BARs can be specified via EA entries.  Extend the EA parser to
extract the SRIOV BAR resources, and modify sriov_init() to use resources
previously obtained via EA.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSean O. Stalley <sean.stalley@intel.com>

Add support for devices using Enhanced Allocation entries instead of BARs.
This allows the kernel to parse the EA Extended Capability structure in PCI
config space and claim the BAR-equivalent resources.

See https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf

[bhelgaas: add spec URL, s/pci_ea_set_flags/pci_ea_flags/, consolidate
declarations, print unknown property in hex to match spec]
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
[david.daney@cavium.com: Add more support/checking for Entry Properties,
allow EA behind bridges, rewrite some error messages.]
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.

Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."

Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes.  The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.

Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.

This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.

Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".

Based on original work by Casey Leedom <leedom@chelsio.com>

[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit bac2a909 (PCI / PM: Avoid resuming PCI devices during
system suspend) introduced a mechanism by which some PCI devices that
were runtime-suspended at the system suspend time might be left in
that state for the duration of the system suspend-resume cycle.
However, it overlooked devices that were marked as capable of waking
up the system just because PME support was detected in their PCI
config space.

Namely, in that case, device_can_wakeup(dev) returns 'true' for the
device and if the device is not configured for system wakeup,
device_may_wakeup(dev) returns 'false' and it will be resumed during
system suspend even though configuring it for system wakeup may not
really make sense at all.

To avoid this problem, simply disable PME for PCI devices that have
not been configured for system wakeup and are runtime-suspended at
the system suspend time for the duration of the suspend-resume cycle.

If the device is in D3cold, its config space is not available and it
shouldn't be written to, but that's only possible if the device
has platform PM support and the platform code is responsible for
checking whether or not the device's configuration is suitable for
system suspend in that case.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

AER errors might be recorded when powering-on devices.  These errors can be
ignored, so firmware usually clears them before the OS enumerates devices.
However, firmware is not involved when devices are added via hotplug, so
the OS may discover power-up errors that should be ignored.  The same may
happen when powering up devices when resuming after suspend.

Clear the AER error status registers during enumeration and resume.

[bhelgaas: changelog, remove repetitive comments]
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

VF BARs are read-only zero, so updating VF BARs will not have any effect.
See the SR-IOV spec r1.1, sec 3.4.1.11.

Don't update VF BARs in pci_restore_bars().

This avoids spurious "BAR %d: error updating" messages that we see when
doing vfio pass-through after 6eb70187 ("vfio-pci: Move idle devices to
D3hot power state").

[bhelgaas: changelog, fix whitespace]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This lets drivers take advantage of PAT when available. It
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache(), see:

  de33c442 ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()")
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: <syrjala@sci.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: airlied@linux.ie
Cc: benh@kernel.crashing.org
Cc: dan.j.williams@intel.com
Cc: konrad.wilk@oracle.com
Cc: linux-fbdev@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: mst@redhat.com
Cc: vinod.koul@intel.com
Cc: xen-devel@lists.xensource.com
Link: http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Firmware typically configures the PCIe fabric with a consistent Max Payload
Size setting based on the devices present at boot.  A hot-added device
typically has the power-on default MPS setting (128 bytes), which may not
match the fabric.

The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
devices.

Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
device's MPS setting matches the upstream bridge.  This makes it more
likely that a hot-added device will work in a system with optimized MPS
configuration.

Note that if we hot-add a device that only supports 128-byte MPS, it still
likely won't work because we don't reconfigure the rest of the fabric.
Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
sets MPS to 128 for everything.

[bhelgaas: changelog, new default, rework for pci_configure_device() path]
Tested-by: NKeith Busch <keith.busch@intel.com>
Tested-by: NJordan Hargrave <jharg93@gmail.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Previously we did not restore ACS state after a PCIe reset.  This meant
that we could not reassign interfaces after a system suspend because the
D0->D3 transition disabled ACS, and we didn't restore it when going back to
D0.

Restore ACS configuration in pci_restore_state().

[bhelgaas: changelog]
Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Allen Kay <allen.m.kay@intel.com>
CC: Chris Wright <chris@sous-sol.org>
CC: Alex Williamson <alex.williamson@redhat.com>

Remove redundant code from __pci_bus_find_cap_start().  No functional
change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The return value of the pci_find_(ext_)capability() is either zero or the
position of a capability.  It is never negative.

This patch consolidates the form of check from (pos <= 0) to (!pos).
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some quirks search for a HyperTransport capability and use a hard-coded TTL
value of 48 to avoid an infinite loop.

Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the
hard-coded TTL values.

[bhelgaas: changelog]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Refine the mechanism introduced by commit f244d8b6 ("ACPIPHP / radeon /
nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the
ignore_hotplug setting of the device to its parent bridge in case hotplug
notifications related to the graphics adapter switching are given for the
bridge rather than for the device itself (they need to be ignored in both
cases).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Reported-and-tested-by: Ntiagdtd-lava <tiagdtd-lava@yahoo.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.17+