- add managed interface to get PCI host bridge resources from OF (Jan
    Kiszka)

  - add support for unbinding generic PCI host controller (Jan Kiszka)

  - fix memory leaks when unbinding generic PCI host controller (Jan Kiszka)

* pci/resource:
  PCI: Enable PCI_DOMAINS along with generic PCI host controller
  PCI: Add support for unbinding the generic PCI host controller
  PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
  PCI: Use dev_printk() in of_pci_get_host_bridge_resources()
  PCI: Pass struct device to of_pci_get_host_bridge_resources()
  PCI: Rename of_pci_get_host_bridge_resources() device node parameter
  PCI: Fix devm_pci_alloc_host_bridge() memory leak
  PCI: Make pci_get_new_domain_nr() static

  - remove unused pcie_port_acpi_setup() and portdrv_acpi.c (Bjorn Helgaas)

* pci/portdrv:
  PCI/portdrv: Remove unused pcie_port_acpi_setup()

  - add macros for PCIe Link Control 2 register (Frederick Lawler)

  - replace IB/hfi1 custom macros with PCI core versions (Frederick Lawler)

  - remove dead microblaze and xtensa code (Bjorn Helgaas)

  - use dev_printk() when possible in xtensa and mips (Bjorn Helgaas)

* pci/misc:
  MIPS: PCI: Use dev_printk() when possible
  xtensa/PCI: Use dev_printk() when possible
  xtensa/PCI: Make variables static
  xtensa/PCI: Remove dead code
  microblaze/PCI: Remove pcibios_claim_one_bus() dead code
  microblaze/PCI: Remove pcibios_finish_adding_to_bus() dead code
  IB/hfi1: Replace custom hfi1 macros with PCIe macros
  PCI: Add PCI_EXP_LNKCTL2_TLS* macros

  - fix use-before-set error in ibmphp (Dan Carpenter)

  - fix pciehp timeouts caused by Command Completed errata (Bjorn Helgaas)

  - fix refcounting in pnv_php hotplug (Julia Lawall)

  - clear pciehp Presence Detect and Data Link Layer Status Changed on
    resume so we don't miss hotplug events (Mika Westerberg)

  - only request pciehp control if we support it, so platform can use ACPI
    hotplug otherwise (Mika Westerberg)

  - convert SHPC to be builtin only (Mika Westerberg)

  - request SHPC control via _OSC if we support it (Mika Westerberg)

  - simplify SHPC handoff from firmware (Mika Westerberg)

* pci/hotplug:
  PCI: Improve "partially hidden behind bridge" log message
  PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() doc
  PCI: Move resource distribution for single bridge outside loop
  PCI: Account for all bridges on bus when distributing bus numbers
  ACPI / hotplug / PCI: Drop unnecessary parentheses
  ACPI / hotplug / PCI: Mark stale PCI devices disconnected
  ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug
  PCI: hotplug: Add hotplug_is_native()
  PCI: shpchp: Add shpchp_is_native()
  PCI: shpchp: Fix AMD POGO identification
  PCI: shpchp: Use dev_printk() for OSHP-related messages
  PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapper
  PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flags
  PCI: shpchp: Rely on previous _OSC results
  PCI: shpchp: Request SHPC control via _OSC when adding host bridge
  PCI: shpchp: Convert SHPC to be builtin only
  PCI: pciehp: Make pciehp_is_native() stricter
  PCI: pciehp: Rename host->native_hotplug to host->native_pcie_hotplug
  PCI: pciehp: Request control of native hotplug only if supported
  PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume
  PCI: pnv_php: Add missing of_node_put()
  PCI: pciehp: Add quirk for Command Completed errata
  PCI: Add Qualcomm vendor ID
  PCI: ibmphp: Fix use-before-set in get_max_bus_speed()

# Conflicts:
#	drivers/acpi/pci_root.c

  - neaten pci=earlydump output (Andy Shevchenko)

  - avoid errors when extended config space inaccessible (Gilles Buloz)

  - prevent sysfs disable of device while driver attached (Christoph
    Hellwig)

  - use core interface to report PCIe link properties in bnx2x, bnxt_en,
    cxgb4, ixgbe (Bjorn Helgaas)

  - remove unused pcie_get_minimum_link() (Bjorn Helgaas)

* pci/enumeration:
  PCI: Remove unused pcie_get_minimum_link()
  ixgbe: Report PCIe link properties with pcie_print_link_status()
  cxgb4: Report PCIe link properties with pcie_print_link_status()
  bnxt_en: Report PCIe link properties with pcie_print_link_status()
  bnx2x: Report PCIe link properties with pcie_print_link_status()
  PCI: Prevent sysfs disable of device while driver is attached
  PCI: Check whether bridges allow access to extended config space
  x86/PCI: Make pci=earlydump output neat

  - clear interrupt status in top half to avoid interrupt storm (Oza
    Pawandeep)

* pci/dpc:
  PCI/DPC: Clear interrupt status in interrupt handler top half

  - disable ASPM L1.2 substate if we don't have LTR (Bjorn Helgaas)

  - respect platform ownership of LTR (Bjorn Helgaas)

* pci/aspm:
  PCI/ACPI: Request LTR control from platform before using it
  PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR

  - unify AER decoding for native and ACPI CPER sources (Alexandru Gagniuc)

  - add TLP header info to AER tracepoint (Thomas Tai)

  - add generic pcie_wait_for_link() interface (Oza Pawandeep)

  - handle AER ERR_FATAL by removing and re-enumerating devices, as
    Downstream Port Containment does (Oza Pawandeep)

  - factor out common code between AER and DPC recovery (Oza Pawandeep)

  - stop triggering DPC for ERR_NONFATAL errors (Oza Pawandeep)

  - share ERR_FATAL recovery path between AER and DPC (Oza Pawandeep)

* pci/aer:
  PCI/AER: Replace struct pcie_device with pci_dev
  PCI/AER: Remove unused parameters
  PCI/AER: Decode Error Source Requester ID
  PCI/AER: Remove aer_recover_work_func() forward declaration
  PCI/DPC: Use the generic pcie_do_fatal_recovery() path
  PCI/AER: Pass service type to pcie_do_fatal_recovery()
  PCI/DPC: Disable ERR_NONFATAL handling by DPC
  PCI/portdrv: Add generic pcie_port_find_device()
  PCI/portdrv: Add generic pcie_port_find_service()
  PCI/AER: Factor out error reporting to drivers/pci/pcie/err.c
  PCI/AER: Rename error recovery interfaces to generic PCI naming
  PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices
  PCI: Add generic pcie_wait_for_link() interface
  PCI/AER: Add TLP header information to tracepoint
  PCI/AER: Unify error bit printing for native and CPER reporting

The AER driver only needed the pcie_device to get to the port pci_dev.
Save the pci_dev pointer directly in struct aer_rpc and remove the
unnecessary indirection.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Remove unused "struct pcie_device *" parameters to handle_error_source()
and aer_process_err_devices().  No functional change intended.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pci_scan_child_bus_extend() complains when we assign an unreachable
secondary bus number to a bridge.  For example, given the topology below:

  +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0
                                  +-01.0-[04-39]--
                                  \-02.0-[3a]----00.0

it logs the following messages:

  pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39]
  pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39]

These messages are incorrect (0000:02 is a bus, not a bridge) and
confusing.  Make the message more understandable:

  pci 0000:02:02.0: devices behind bridge are unusable because [bus 3a] cannot be assigned for them

Also, remove the reference to CardBus, because this issue affects all
varieties of PCI, not just CardBus.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: changelog]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

It is not immediately clear what the two functions actually return so
add kernel-doc comment explaining it a bit better.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

If there is only a single bridge on the bus, we assign all resources to it.
Currently this is done as a part of the resource distribution loop but it
does not have to be there, and moving it outside actually improves
readability because we can then save one indent level in the loop.

While there we can add hotplug_bridges == 1 && normal_bridges == 0 to
the same block because they are dealt the same way.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When distributing extra bus number space to hotplug bridges for future
extension, we don't account for the fact that there might be non-hotplug
bridges on the bus after the hotplug bridges.  For example:

  01:00.0 --+- 02:00.0 (HotPlug-) -- Thunderbolt host controller
            +- 02:01.0 (HotPlug+)
            \- 02:02.0 (HotPlug-) -- xHCI host controller

pci_scan_child_bus_extend() is supposed to distribute the remaining bus
numbers to the hotplug bridge at 02:01.0, but only after accounting for all
bridges on bus 02.  Since we don't check whether there's another
non-hotplug bridge after the hotplug bridge 02:01.0, it may not leave space
for the non-hotplug bridge:

  pci 0000:00:1b.0: PCI bridge to [bus 01-39]  (Root Port)
  pci 0000:01:00.0: PCI bridge to [bus 02-39]
  ...
  pci 0000:02:00.0: PCI bridge to [bus 03]
  pci 0000:02:01.0: PCI bridge to [bus 04]
  pci_bus 0000:04: [bus 04-39] extended by 0x35
  pci_bus 0000:04: bus scan returning with max=39
  pci_bus 0000:04: busn_res: [bus 04-39] end is updated to 39
  pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1
  pci_bus 0000:3a: scanning bus
  pci_bus 0000:3a: bus scan returning with max=3a
  pci_bus 0000:3a: busn_res: [bus 3a] end is updated to 3a
  pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39]
  pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39]
  pci_bus 0000:02: bus scan returning with max=3a
  pci_bus 0000:02: busn_res: [bus 02-39] end can not be updated to 3a

The resulting 'lspci -t' output looks like this:

  +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0
                             ^^   +-01.0-[04-39]--
                                  \-02.0-[3a]----00.0
                                          ^^
The xHCI host controller behind 02:02.0 is not usable because it would have
to be assigned bus 3a, which is not accessible through 00:1b.0.

To fix this, reserve at least one bus for each bridge while scanning
already configured bridges.  Then use this information in the second
scan to correct the available extra bus space for hotplug bridges.

After this change the 'lspci -t' output is what is expected:

  +-1b.0-[01-39]----00.0-[02-39]--+-00.0-[03]----00.0
                                  +-01.0-[04-38]--
                                  \-02.0-[39]----00.0

The xHCI controller is now on bus 39, where it is usable.

Fixes: 1c02ea81 ("PCI: Distribute available buses to hotplug-capable bridges")
Reported-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: changelog]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org

Remove unnecessary parentheses.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Following PCIehp mark the unplugged PCI devices disconnected.  This makes
sure PCI core code leaves the now missing hardware registers alone.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When acpiphp re-enumerates a PCI hierarchy because of an ACPI Notify()
event, we should skip bridges managed by native hotplug (pciehp or shpchp).
We don't want to scan below a native hotplug bridge until the hotplug
controller generates a hot-add event.

A typical scenario is a Root Port leading to a Thunderbolt host router that
remains powered off until something is connected to it.  See [1] for the
lspci details.

  1. Before something is connected, only the Root Port exists.  It has
     PCI_EXP_SLTCAP_HPC set and pciehp is responsible for hotplug:

       00:1b.0 Root Port (HotPlug+)

  2. When a USB-C or Thunderbolt device is connected, the Switch in the
     Thunderbolt host router is powered up, the Root Port signals a hotplug
     add event and pciehp enumerates the Switch:

       01:00.0 Switch Upstream Port   to [bus 02-39]
       02:00.0 Switch Downstream Port to [bus 03]    (HotPlug-, to NHI)
       02:01.0 Switch Downstream Port to [bus 04-38] (HotPlug+, to Thunderbolt connector)
       02:02.0 Switch Downstream Port to [bus 39]    (HotPlug-, to xHCI)

     The 02:00.0 and 02:02.0 Ports lead to Endpoints that are not powered
     up yet.  The Ports have PCI_EXP_SLTCAP_HPC cleared, so pciehp doesn't
     handle hotplug for them and we assign minimal resources to them.

     The 02:01.0 Port has PCI_EXP_SLTCAP_HPC set, so pciehp handles native
     hotplug events for it.

  3. The BIOS powers up the xHCI controller.  If a Thunderbolt device was
     connected (not just a USB-C device), it also powers up the NHI.  Then
     it sends an ACPI Notify() to the Root Port, and acpiphp enumerates the
     new device(s):

       03:00.0 Thunderbolt Host Controller (NHI) Endpoint
       39:00.0 xHCI Endpoint

  4. If a Thunderbolt device was connected, the host router firmware uses
     the NHI to set up Thunderbolt tunnels and triggers a native hotplug
     event (via 02:01.0 in this example).  Then pciehp enumerates the new
     Thunderbolt devices:

       04:00.0 Switch Upstream Port   to [bus 05-38]
       05:01.0 Switch Downstream Port to [bus 06-09] (HotPlug-)
       05:04.0 Switch Downstream Port to [bus 0a-38] (HotPlug+)

     In this example, 05:01.0 leads to another Switch and some NICs.  This
     subtree is static, so 05:01.0 doesn't support hotplug and has
     PCI_EXP_SLTCAP_HPC cleared.

In step 3, acpiphp previously enumerated everything below the Root Port,
including things below the 02:01.0 Port.  We don't want that because pciehp
expects to manage hotplug below that Port, and firmware on the host router
may be in the middle of configuring its Link so it may not be ready yet.

To make this work better with the native PCIe (pciehp) and standard PCI
(shpchp) hotplug drivers, we let them handle all slot management and
resource allocation for hotplug bridges and restrict ACPI hotplug to
non-hotplug bridges.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=199581#c5
Link: https://lkml.kernel.org/r/20180529160155.1738-1-mika.westerberg@linux.intel.comSigned-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: changelog, use hotplug_is_native() instead of
dev->is_hotplug_bridge]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add hotplug_is_native() to find out whether the OS is supposed to handle
native hotplug of a given bridge.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

In the same way we do for pciehp, add shpchp_is_native(), which returns
true if the bridge should be handled by the native SHPC driver.  Then
convert the driver to use this function.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The fix for an AMD POGO erratum related to SHPC incorrectly identified the
device.  The workaround should be applied only for AMD POGO devices, but it
was instead applied to:

  - all AMD bridges, and
  - all devices from any vendor with device ID 0x7458

Fixes: 53044f35 ("[PATCH] PCI Hotplug: shpchp: AMD POGO errata fix")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Decode the Requester ID from the AER Error Source Register into domain/
bus/device/function format to match other logging.  In cases where the ID
matches the device used for pci_err(), drop the extra ID completely so we
don't print it twice.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Just move the actual function up so that it is visible to its user
aer_recover_queue().

No functional changes.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Our goal is to handle ERR_FATAL errors similarly, whether they are reported
via AER or via DPC.  A previous commit changed AER so it handles ERR_FATAL
by calling driver .remove() methods and resetting the Link.  DPC already
does that (although the Link reset is done automatically by hardware and
happens before we call the driver .remove() methods).

Restructure the DPC code so it calls the same pcie_do_fatal_recovery()
interface used by AER.  This makes it clearer that we want to use the same
path.

Implement the .reset_link() method used by pcie_do_fatal_recovery().  For
DPC, the actual reset is done automatically by hardware, so we really only
have to wait for the Link to be inactive, then release the Port from DPC.
Signed-off-by: NOza Pawandeep <poza@codeaurora.org>
[bhelgaas: changelog, DPC_FATAL is not a bitfield, can be sequential]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Pass the service type to pcie_do_fatal_recovery() instead of assuming AER.
We will make DPC also use pcie_do_fatal_recovery(), and it needs to do
things a little differently for AER and DPC.
Signed-off-by: NOza Pawandeep <poza@codeaurora.org>
[bhelgaas: split to separate patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCIe ERR_NONFATAL errors mean a particular transaction is unreliable but
the Link is otherwise fully functional (PCIe r4.0, sec 6.2.2).

The AER driver handles these by logging the error details and calling
driver-supplied pci_error_handlers callbacks.  It does not reset downstream
devices, does not remove them from the PCI subsystem, does not re-enumerate
them, and does not call their driver .remove() or .probe() methods.

But DPC driver previously enabled DPC on ERR_NONFATAL, so if the hardware
supports DPC, these errors caused a Link reset (performed automatically by
the hardware), followed by the DPC driver removing affected devices (which
calls their .remove() methods), bringing the Link back up, and
re-enumerating (which calls driver .probe() methods).

Disable ERR_NONFATAL DPC triggering so these errors will only be handled by
AER.  This means drivers won't have to deal with different usage of their
pci_error_handlers callbacks and .probe() and .remove() methods based on
whether the platform has DPC support.
Signed-off-by: NOza Pawandeep <poza@codeaurora.org>
[bhelgaas: changelog]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add generic pcie_port_find_device() routine.
Signed-off-by: NOza Pawandeep <poza@codeaurora.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKeith Busch <keith.busch@intel.com>

Use dev_printk() for messages related to requesting control of SHPC hotplug
via the OSHP method.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

get_hp_hw_control_from_firmware() is a trivial wrapper around
acpi_get_hp_hw_control_from_firmware(), probably intended to be generic in
case other firmware needed similar OS/platform negotiation.

Remove get_hp_hw_control_from_firmware() and call
acpi_get_hp_hw_control_from_firmware() directly.  Add a stub for
acpi_get_hp_hw_control_from_firmware() for the non-ACPI case.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_get_hp_hw_control_from_firmware() no longer uses the flags parameter,
so remove it.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: split to separate patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If _OSC exists, we evaluated it when adding the ACPI host bridge, and we
requested SHPC control if the SHPC driver is present.  Use the result of
that _OSC evaluation instead of evaluating it again.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: split to separate patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The SHPC driver now must be builtin (it cannot be a module).  If it is
present, request SHPC control immediately when adding the ACPI host bridge.
This is similar to how we handle native PCIe hotplug via pciehp.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: split to separate patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We need to be able coordinate between SHPC and acpiphp to determine which
driver handles hotplug of a given bridge.  Because acpiphp is already bool,
convert SHPC to be bool as well.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Previously pciehp_is_native() returned true for any PCI device in a
hierarchy where _OSC says we can use pciehp.  This is incorrect because
bridges without PCI_EXP_SLTCAP_HPC capability should be managed by acpiphp
instead.

Improve pciehp_is_native() to return true only when PCI_EXP_SLTCAP_HPC is
set and the pciehp driver is present.  In any other case return false
to let acpiphp handle those.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: remove NULL pointer check]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Rename host->native_hotplug to host->native_pcie_hotplug to make room for a
similar flag for SHPC hotplug.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: split to separate patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The generic PCI host controller is often instantiated by hypervisors, and
they may add several of them or add them in addition to a physical host
controller like the Jailhouse hypervisor is doing.  Therefore, allow for
multiple domains so that we can handle them all.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add support for unbinding the generic PCI host controller.  This is
particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

of_pci_get_host_bridge_resources() allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, convert the existing
function to a managed version.
Tested-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Acked-by: NJoao Pinto <jpinto@synopsys.com>
Acked-by: NJingoo Han <jingoohan1@gmail.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Now that we have a device reference, make use of it for printing.
Tested-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>

Another step towards a managed version of
of_pci_get_host_bridge_resources(): Feed in the underlying device, rather
than just the OF node.  This will allow us to use managed resource
allocation internally later on.
Tested-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Acked-by: NJingoo Han <jingoohan1@gmail.com>
CC: Joao Pinto <Joao.Pinto@synopsys.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

We will add a "struct device *dev" parameter to this function soon, so
rename the existing "struct device_node *dev" parameter to "dev_node".
Tested-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>