- use generic pci_mmap_resource_range() instead of powerpc and xtensa
    arch-specific versions (David Woodhouse)

* pci/resource-mmap:
  xtensa/PCI: Use generic pci_mmap_resource_range()
  powerpc/pci: Use generic pci_mmap_resource_range()

  - move pcieport_if.h to drivers/pci/pcie/ to encapsulate it (Frederick
    Lawler)

  - merge pcieport_if.h into portdrv.h (Bjorn Helgaas)

  - move workaround for BIOS PME issue from portdrv to PCI core (Bjorn
    Helgaas)

  - completely disable portdrv with "pcie_ports=compat" (Bjorn Helgaas)

  - remove portdrv link order dependency (Bjorn Helgaas)

  - remove support for unused VC portdrv service (Bjorn Helgaas)

  - simplify portdrv feature permission checking (Bjorn Helgaas)

  - remove "pcie_hp=nomsi" parameter (use "pci=nomsi" instead) (Bjorn
    Helgaas)

  - remove unnecessary "pcie_ports=auto" parameter (Bjorn Helgaas)

  - use cached AER capability offset (Frederick Lawler)

  - don't enable DPC if BIOS hasn't granted AER control (Mika Westerberg)

  - rename pcie-dpc.c to dpc.c (Bjorn Helgaas)

* pci/portdrv:
  PCI/DPC: Rename from pcie-dpc.c to dpc.c
  PCI/DPC: Do not enable DPC if AER control is not allowed by the BIOS
  PCI/AER: Use cached AER Capability offset
  PCI/portdrv: Rename and reverse sense of pcie_ports_auto
  PCI/portdrv: Encapsulate pcie_ports_auto inside the port driver
  PCI/portdrv: Remove unnecessary "pcie_ports=auto" parameter
  PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter
  PCI/portdrv: Remove unnecessary include of <linux/pci-aspm.h>
  PCI/portdrv: Simplify PCIe feature permission checking
  PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC
  PCI/portdrv: Remove pcie_port_bus_type link order dependency
  PCI/portdrv: Disable port driver in compat mode
  PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors
  PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver
  PCI/PM: Move pcie_clear_root_pme_status() to core
  PCI/portdrv: Merge pcieport_if.h into portdrv.h
  PCI/portdrv: Move pcieport_if.h to drivers/pci/pcie/

Conflicts:
	drivers/pci/pcie/Makefile
	drivers/pci/pcie/portdrv.h

  - don't set up INTx if MSI or MSI-X is enabled to align cris, frv, ia64,
    and mn10300 with x86 (Bjorn Helgaas)

* pci/msi:
  PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled

  - use PCI_EXP_DEVCTL2_COMP_TIMEOUT in rapidio/tsi721 (Bjorn Helgaas)

  - remove possible NULL pointer dereference in of_pci_bus_find_domain_nr()
    (Shawn Lin)

  - report quirk timings with dev_info (Bjorn Helgaas)

  - report quirks that take longer than 10ms (Bjorn Helgaas)

  - add and use Altera Vendor ID (Johannes Thumshirn)

  - tidy Makefiles and comments (Bjorn Helgaas)

* pci/misc:
  PCI: Always define the of_node helpers
  PCI: Tidy comments
  PCI: Tidy Makefiles
  mcb: Add Altera PCI ID to mcb-pci
  PCI: Add Altera vendor ID
  PCI: Report quirks that take more than 10ms
  PCI: Report quirk timings with pci_info() instead of pr_debug()
  PCI: Fix NULL pointer dereference in of_pci_bus_find_domain_nr()
  rapidio/tsi721: use PCI_EXP_DEVCTL2_COMP_TIMEOUT macro

  - add support for PCI I/O port space that's neither directly accessible
    via CPU in/out instructions nor directly mapped into CPU physical
    memory space (Zhichang Yuan)

  - add support for HiSilicon Hip06/Hip07 LPC I/O space (Zhichang Yuan,
    John Garry)

* pci/lpc:
  MAINTAINERS: Add John Garry as maintainer for HiSilicon LPC driver
  HISI LPC: Add ACPI support
  ACPI / scan: Do not enumerate Indirect IO host children
  ACPI / scan: Rename acpi_is_serial_bus_slave() for more general use
  HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings
  of: Add missing I/O range exception for indirect-IO devices
  PCI: Apply the new generic I/O management on PCI IO hosts
  PCI: Add fwnode handler as input param of pci_register_io_range()
  PCI: Remove __weak tag from pci_register_io_range()
  lib: Add generic PIO mapping method

  - fix possible cpqphp NULL pointer dereference (Shawn Lin)

  - rescan more of the hierarchy on ACPI hotplug to fix Thunderbolt/xHCI
    hotplug (Mika Westerberg)

* pci/hotplug:
  ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status()
  PCI: cpqphp: Fix possible NULL pointer dereference

  - add decoding for 16 GT/s link speed (Jay Fang)

  - add interfaces to get max link speed and width (Tal Gilboa)

  - add pcie_bandwidth_capable() to compute max supported link bandwidth
    (Tal Gilboa)

  - add pcie_bandwidth_available() to compute bandwidth available to device
    (Tal Gilboa)

  - add pcie_print_link_status() to log link speed and whether it's limited
    (Tal Gilboa)

  - use PCI core interfaces to report when device performance may be
    limited by its slot instead of doing it in each driver (Tal Gilboa)

* pci/enumeration:
  fm10k: Report PCIe link properties with pcie_print_link_status()
  net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth
  net/mlx5: Report PCIe link properties with pcie_print_link_status()
  net/mlx4_core: Report PCIe link properties with pcie_print_link_status()
  PCI: Add pcie_print_link_status() to log link speed and whether it's limited
  PCI: Add pcie_bandwidth_available() to compute bandwidth available to device
  PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth
  PCI: Add pcie_get_width_cap() to find max supported link width
  PCI: Add pcie_get_speed_cap() to find max supported link speed
  PCI: Add decoding for 16 GT/s link speed

  - remove last user of pci_get_bus_and_slot() and the function itself
    (Sinan Kaya)

* pci/deprecate-get-bus-and-slot:
  PCI: Remove pci_get_bus_and_slot() function
  drm/i915: Deprecate pci_get_bus_and_slot()

  - skip ASPM common clock warning if BIOS already configured it (Sinan
    Kaya)

  - fix ASPM Coverity warning about threshold_ns (Gustavo A. R. Silva)

* pci/aspm:
  PCI/ASPM: Don't warn if already in common clock mode
  PCI/ASPM: Declare threshold_ns as u32, not u64

  - move pci_uevent_ers() out of pci.h (Michael Ellerman)

* pci/aer:
  PCI/AER: Move pci_uevent_ers() out of pci.h

Add John Garry as maintainer for drivers/bus/hisi_lpc.c, the HiSilicon LPC
driver.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Based on the previous patches, this patch supports the LPC host on
Hip06/Hip07 for ACPI FW.

It is the responsibility of the LPC host driver to enumerate the child
devices, as the ACPI scan code will not enumerate children of "indirect IO"
hosts.

The ACPI table for the LPC host controller and the child devices is in the
following format:

  Device (LPC0) {
    Name (_HID, "HISI0191")  // HiSi LPC
    Name (_CRS, ResourceTemplate () {
      Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000)
    })
  }

  Device (LPC0.IPMI) {
    Name (_HID, "IPI0001")
    Name (LORS, ResourceTemplate() {
      QWordIO (
        ResourceConsumer,
        MinNotFixed,     // _MIF
        MaxNotFixed,     // _MAF
        PosDecode,
        EntireRange,
        0x0,             // _GRA
        0xe4,            // _MIN
        0x3fff,          // _MAX
        0x0,             // _TRA
        0x04,            // _LEN
        , ,
        BTIO
      )
    })

Since the IO resources of the child devices need to be translated from LPC
bus addresses to logical PIO addresses, and we shouldn't modify the
resources of the devices generated in the FW scan, a per-child MFD is
created as a substitute.  The MFD IO resources will be the translated bus
addresses of the ACPI child.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Through the logical PIO framework, systems which otherwise have no IO space
access to legacy ISA/LPC devices may access these devices through so-called
"indirect IO" method.  In this, IO space accesses for non-PCI hosts are
redirected to a host LLDD to manually generate the IO space (bus) accesses.
Hosts are able to register a region in logical PIO space to map to its bus
address range.

Indirect IO child devices have an associated host-specific bus address.
Special translation is required to map between a logical PIO address for a
device and its host bus address.

Since in the ACPI tables the child device IO resources would be the
host-specific values, it is required the ACPI scan code should not
enumerate these devices, and that this should be the responsibility of the
host driver so that it can "fixup" the resources so that they map to the
appropriate logical PIO addresses.

To avoid enumerating these child devices, add a check from
acpi_device_enumeration_by_parent() as to whether the parent for a device
is a member of a known list of "indirect IO" hosts.  For now, the HiSilicon
LPC host controller ID is added.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently the ACPI scan has special handling for serial bus slaves, in that
it makes it the responsibility of the slave device's parent to enumerate
the device.

To support other types of slave devices which require the same special
handling but where the bus is not strictly a serial bus, such as devices on
the HiSilicon LPC controller bus, rename acpi_is_serial_bus_slave() to
acpi_device_enumeration_by_parent(), so that the name can fit the wider
purpose.

Also rename the associated device flag acpi_device_flags.serial_bus_slave
to .enumeration_by_parent.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The low-pin-count (LPC) interface of Hip06/Hip07 accesses I/O port space of
peripherals.

Implement the LPC host controller driver which performs the I/O operations
on the underlying hardware.  We don't want to touch existing drivers such
as ipmi-bt, so this driver applies the indirect-IO introduced in the
previous patch after registering an indirect-IO node to the indirect-IO
devices list which will be searched by the I/O accessors to retrieve the
host-local I/O port.

The driver config is set as a bool instead of a tristate.  The reason here
is that, by the very nature of the driver providing a logical PIO range, it
does not make sense to have this driver as a loadable module.  Another more
specific reason is that the Huawei D03 board which includes Hip06 SoC
requires the LPC bus for UART console, so should be built in.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Zou Rongrong <zourongrong@huawei.com>
Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>	# dts part

There are some special ISA/LPC devices that work on a specific I/O range
where it is not correct to specify a 'ranges' property in the DTS parent
node as CPU addresses translated from DTS node are only for memory space on
some architectures, such as ARM64.  Without the parent 'ranges' property,
of_translate_address() returns an error.

Here we add special handling for this case.

During the OF address translation, some checking will be performed to
identify whether the device node is registered as indirect-IO.  If it is,
the I/O translation will be done in a different way from that one of PCI
MMIO.  In this way, the I/O 'reg' property of the special ISA/LPC devices
will be parsed correctly.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>    # earlier draft
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>

After introducing the new generic I/O space management (Logical PIO), the
original PCI MMIO relevant helpers need to be updated based on the new
interfaces defined in logical PIO.

Adapt the corresponding code to match the changes introduced by logical
PIO.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>        # earlier draft
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

In preparation for having the PCI MMIO helpers use the new generic I/O
space management (logical PIO) we need to add the fwnode handler as an
extra input parameter.

Changes the signature of pci_register_io_range() and its callers as
needed.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>

pci_register_io_range() has only one definition, so there is no need for
the __weak attribute.  Remove it.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Previously the driver used pcie_get_minimum_link() to warn when the NIC
is in a slot that can't supply as much bandwidth as the NIC could use.

pcie_get_minimum_link() can be misleading because it finds the slowest link
and the narrowest link (which may be different links) without considering
the total bandwidth of each link.  For a path with a 16 GT/s x1 link and a
2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
bandwidth, not the true available bandwidth of about 1969 MB/s for a
16 GT/s x1 link.

Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself.  This finds
the slowest link in the path to the device by computing the total bandwidth
of each link and compares that with the capabilities of the device.

Note that the driver previously used dev_warn() to suggest using a
different slot, but pcie_print_link_status() uses dev_info() because if the
platform has no faster slot available, the user can't do anything about the
warning and may not want to be bothered with it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>

Use the new pci_bandwidth_available() function to calculate maximum
available bandwidth through the PCI chain instead of computing it ourselves
with mlx5e_get_pci_bw().

This is used to detect when the device is capable of more bandwidth than is
available in the current slot.  The driver may adjust compression settings
accordingly.

Note that pci_bandwidth_available() accounts for PCIe encoding overhead, so
it is more accurate than mlx5e_get_pci_bw() was.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: remove mlx5e_get_pci_bw() wrapper altogether]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>

Use pcie_print_link_status() to report PCIe link speed and possible
limitations.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>

Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Add pcie_print_link_status().  This logs the current settings of the link
(speed, width, and total available bandwidth).

If the device is capable of more bandwidth but is limited by a slower
upstream link, we include information about the link that limits the
device's performance.

The user may be able to move the device to a different slot for better
performance.

This provides a unified method for all PCI devices to report status and
issues, instead of each device reporting in a different way, using
different code.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: changelog, reword log messages, print device capabilities when
not limited, print bandwidth in Gb/s]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Add pcie_bandwidth_available() to compute the bandwidth available to a
device.  This may be limited by the device itself or by a slower upstream
link leading to the device.

The available bandwidth at each link along the path is computed as:

  link_width * link_speed * (1 - encoding_overhead)

2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth
available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which
reduces it by about 1.5%.

The result is in Mb/s, i.e., megabits/second, of raw bandwidth.

Also return the device with the slowest link and the speed and width of
that link.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return
bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find
uppermost limiting device, return speed/width of the limiting device]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Rename pcie-dpc.c to dpc.c.  The path "drivers/pci/pcie/pcie-dpc.c" has
more occurrences of "pci" than necessary.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Simply move these inline functions outside the ifdef instead of duplicating
them as stubs in the !OF case.  The struct device of_node field does not
depend on OF.

This also fixes the missing stubbed pci_bus_to_OF_node().
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>

Commit eed85ff4 ("PCI/DPC: Enable DPC only if AER is available") made
DPC control dependent whether AER is enabled in the OS.  However, it does
not take into account situations where BIOS has not given OS control of
AER:

  acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
  acpi PNP0A08:00: _OSC: platform does not support [AER]
  acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability]

I think here it is better not to enable DPC even if the capability is
available because then it would be against what "Determination of DPC
Control" note in PCIe 4.0 sec 6.1.10 recommends.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>

Replace pci_find_ext_capability(..., PCI_EXT_CAP_ID_ERR) calls with
pci_dev->aer_cap.

pci_dev->aer_cap is initialized in pci_init_capabilities(), which happens
before any of these users of the AER Capability.
Signed-off-by: Frederick Lawler <fred@fredlawl.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The platform may restrict the OS's use of PCIe services, e.g., via the ACPI
_OSC method.  The user may use "pcie_ports=native" to force the port driver
to use PCIe services even if the platform asked us not to.

The "pcie_ports=native" parameter determines the setting of
pcie_ports_auto.  Rename this to pcie_ports_native and reverse the
sense to simplify the code.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

"pcie_ports_auto" is only used inside the PCIe port driver itself, so
move it from include/linux/pci.h to portdrv.h so it's not visible to the
whole kernel.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The "pcie_ports=auto" parameter set pcie_ports_disabled and pcie_ports_auto
to their compiled-in defaults, so specifying the parameter is the same as
not using it at all.

Remove the "pcie_ports=auto" parameter and update the documentation.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

7570a333 ("PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp
driver") added the "pcie_hp=nomsi" kernel parameter to work around this
error on shutdown:

  irq 16: nobody cared (try booting with the "irqpoll" option)
  Pid: 1081, comm: reboot Not tainted 3.2.0 #1
  ...
  Disabling IRQ #16

This happened on an unspecified system (possibly involving the Integrated
Device Technology, Inc. Device 807f bridge) where "an un-wanted interrupt
is generated when PCI driver switches from MSI/MSI-X to INTx while shutting
down the device."

The implication was that the device was buggy, but it is normal for a
device to use INTx after MSI/MSI-X have been disabled.  The only problem
was that the driver was still attached and it wasn't prepared for INTx
interrupts.  Prarit Bhargava fixed this issue with fda78d7a ("PCI/MSI:
Stop disabling MSI/MSI-X in pci_device_shutdown()").

There is no automated way to set this parameter, so it's not very useful
for distributions or end users.  It's really only useful for debugging, and
we have "pci=nomsi" for that purpose.

Revert 7570a333 to remove the "pcie_hp=nomsi" parameter.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
CC: Prarit Bhargava <prarit@redhat.com>

portdrv_pci.c doesn't use anything from <linux/pci-aspm.h>.  Remove the
include of it.  No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the
platform firmware or the OS, so the host bridge driver may have to request
permission from the platform before using them.  On ACPI systems, this is
done by negotiate_os_control() in acpi_pci_root_add().

The PCIe port driver later uses pcie_port_platform_notify() and
pcie_port_acpi_setup() to figure out whether it can use these features.
But all we need is a single bit for each service, so these interfaces are
needlessly complicated.

Simplify this by adding bits in the struct pci_host_bridge to show when the
OS has permission to use each feature:

  + unsigned int native_aer:1;       /* OS may use PCIe AER */
  + unsigned int native_hotplug:1;   /* OS may use PCIe hotplug */
  + unsigned int native_pme:1;       /* OS may use PCIe PME */

These are set when we create a host bridge, and the host bridge driver can
clear the bits corresponding to any feature the platform doesn't want us to
use.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

No driver registers for PCIE_PORT_SERVICE_VC, so remove it.

This removes the VC "service" files from /sys/bus/pci_express/devices,
e.g., 0000:07:00.0:pcie108, 0000:08:04.0:pcie208 (all the files that
contained "8" as the last digit of the "pcieXXX" part).  The port driver
created these files for PCIe port devices that have a VC Capability.

Since this reduces PCIE_PORT_DEVICE_MAXSERVICES and moves DPC down into the
spot where VC used to be, the DPC sysfs files will now be named "pcieXX8".
I don't think there's anything useful userspace can do with those files, so
I hope nobody cares about these filenames.

There is no VC driver that calls pcie_port_service_register(), so there
never was a /sys/bus/pci_express/drivers/vc directory.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>

The pcie_port_bus_type must be registered before drivers that depend on it
can be registered.  Those drivers include:

  pcied_init()                # PCIe native hotplug driver
  aer_service_init()          # AER driver
  dpc_service_init()          # DPC driver
  pcie_pme_service_init()     # PME driver

Previously we registered pcie_port_bus_type from pcie_portdrv_init(), a
device_initcall.  The callers of pcie_port_service_register() (above) are
also device_initcalls.  This is fragile because the device_initcall
ordering depends on link order, which is not explicit.

Register pcie_port_bus_type from pci_driver_init() along with pci_bus_type.
This removes the link order dependency between portdrv and the pciehp, AER,
DPC, and PCIe PME drivers.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>

The "pcie_ports=compat" kernel parameter sets pcie_ports_disabled, which is
intended to disable the PCIe port driver.  But even when it was disabled,
we registered pcie_portdriver so we could work around a BIOS PME issue (see
fe31e697 ("PCI/PCIe: Clear Root PME Status bits early during system
resume")).

Registering the driver meant that the pcie_portdrv_probe() path called
pci_enable_device(), pci_save_state(), pm_runtime_set_autosuspend_delay(),
pm_runtime_use_autosuspend(), etc., even when the driver was disabled.

We've since moved the BIOS PME workaround from the port driver to the core,
so stop registering the PCIe port driver in compat mode.

This means "pcie_ports=compat" will now be basically the same as turning
off CONFIG_PCIEPORTBUS completely.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Per PCIe r4.0, sec 6.1.6, Root Complex Event Collectors can generate PME
interrupts on behalf of Root Complex Integrated Endpoints.

Linux does not currently enable PME interrupts from RC Event Collectors,
but fe31e697 ("PCI/PCIe: Clear Root PME Status bits early during system
resume") suggests PME interrupts may be enabled by the platform for ACPI-
based runtime wakeup.

Clear the PCIe PME Status bit for Root Complex Event Collectors during
resume, just like we already do for Root Ports.

If the BIOS enables PME interrupts for an event collector and neglects to
clear the status bit on resume, this change should fix the same bug as
fe31e697 (PMEs not working after waking from a sleep state), but for
Root Complex Integrated Endpoints.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Add pcie_bandwidth_capable() to compute the max link bandwidth supported by
a device, based on the max link speed and width, adjusted by the encoding
overhead.

The maximum bandwidth of the link is computed as:

  max_link_width * max_link_speed * (1 - encoding_overhead)

2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth
available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which
reduces it by about 1.5%.

The result is in Mb/s, i.e., megabits/second, of raw bandwidth.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: add 16 GT/s, adjust for pcie_get_speed_cap() and
pcie_get_width_cap() signatures, don't export outside drivers/pci]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>