Merge branch 'remotes/lorenzo/pci/v3-semi'

  - Fix memory leak in probe error paths (Christophe JAILLET)

* remotes/lorenzo/pci/v3-semi:
  PCI: v3-semi: Fix a memory leak in v3_pci_probe() error handling paths

Merge branch 'remotes/lorenzo/pci/tegra'

  - Fix error message for failure to get reset GPIO from DT (Pali Rohár)

  - Fix runtime PM imbalance on error path (both tegra and tegra194)
    (Dinghao Liu)

* remotes/lorenzo/pci/tegra:
  PCI: tegra: Fix runtime PM imbalance on error
  PCI: tegra194: Fix runtime PM imbalance on error
  PCI: tegra: Fix reporting GPIO error value

Merge branch 'remotes/lorenzo/pci/rcar'

  - Fix rcar OB window programming (Andrew Murray)

  - Add rcar suspend/resume support (Kazufumi Ikeda)

  - Add r8a77961 to DT binding (Yoshihiro Shimoda)

  - Rename pcie-rcar.c to pcie-rcar-host.c to make room for endpoint mode
    (Lad Prabhakar)

  - Move shareable code to pcie-rcar.c (Lad Prabhakar)

  - Correct PCIEPAMR mask calculation for "size < 128" (Lad Prabhakar)

  - Add endpoint support for multiple outbound memory windows (Lad
    Prabhakar)

  - Add R-Car PCIe endpoint driver and DT bindings (Lad Prabhakar)

* remotes/lorenzo/pci/rcar:
  MAINTAINERS: Add file patterns for rcar PCI device tree bindings
  PCI: rcar: Add endpoint mode support
  dt-bindings: PCI: rcar: Add bindings for R-Car PCIe endpoint controller
  PCI: endpoint: Add support to handle multiple base for mapping outbound memory
  PCI: endpoint: Pass page size as argument to pci_epc_mem_init()
  PCI: rcar: Fix calculating mask for PCIEPAMR register
  PCI: rcar: Move shareable code to a common file
  PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.c
  dt-bindings: pci: rcar: add r8a77961 support
  PCI: rcar: Add suspend/resume
  PCI: rcar: Fix incorrect programming of OB windows

Merge branch 'remotes/lorenzo/pci/pci-bridge-emul'

  - Fix conflicts in pci-bridge-emul descriptions of Device Status and Slot
    Control (Jon Derrick)

  - Add emulation for more Device Status, Link Control, and Slot Control
    bits (Jon Derrick)

  - Improve emulation of reserved bits (Jon Derrick)

* remotes/lorenzo/pci/pci-bridge-emul:
  PCI: pci-bridge-emul: Eliminate the 'reserved' member
  PCI: pci-bridge-emul: Update for PCIe 5.0 r1.0
  PCI: pci-bridge-emul: Fix Root Cap/Status comment
  PCI: pci-bridge-emul: Fix PCIe bit conflicts

Merge branch 'remotes/lorenzo/pci/misc'

  - Correct MAINTAINERS typo for NXP LAYERSCAPE GEN4 (Lukas Bulwahn)

  - Make PCI endpoint doc section labels unique (Bryce Willey)

* remotes/lorenzo/pci/misc:
  Documentation: PCI: Give unique labels to sections
  MAINTAINERS: correct typo in new NXP LAYERSCAPE GEN4

Merge branch 'remotes/lorenzo/pci/hv'

  - Release resource in probe failure path (Wei Hu)

  - Retry PCI bus D0 entry if device state is invalid (Wei Hu)

  - Use struct_size() to help avoid type mistakes (Gustavo A. R. Silva)

* remotes/lorenzo/pci/hv:
  PCI: hv: Use struct_size() helper
  PCI: hv: Retry PCI bus D0 entry on invalid device state
  PCI: hv: Fix the PCI HyperV probe failure path to release resource properly

Merge branch 'remotes/lorenzo/pci/host-generic'

  - Constify struct pci_ecam_ops (Rob Herring)

  - Support building as modules (Rob Herring)

  - Eliminate wrappers for pci_host_common_probe() by using DT match table
    data (Rob Herring)

* remotes/lorenzo/pci/host-generic:
  PCI: host-generic: Eliminate pci_host_common_probe wrappers
  PCI: host-generic: Support building as modules
  PCI: Constify struct pci_ecam_ops

# Conflicts:
# drivers/pci/controller/dwc/pcie-hisi.c

Merge branch 'remotes/lorenzo/pci/endpoint'

  - Avoid NULL pointer dereference in dma_release_channel() (Kunihiko
    Hayashi)

* remotes/lorenzo/pci/endpoint:
  PCI: endpoint: functions/pci-epf-test: Fix DMA channel release

Merge branch 'remotes/lorenzo/pci/dwc'

  - Simplify computation of msix_tbl (Jiri Slaby)

  - Make hisi_pcie_platform_ops static (Zou Wei)

  - Warn about resources above 4G (Alan Mikhak)

  - Make intel_pcie_cpu_addr() static (Jason Yan)

  - Use devm_platform_ioremap_resource_byname() to simplify code and
    improve error checking (Wei Yongjun)

  - Fix inner MSI IRQ domain registration so it doesn't confuse debugfs
    (Marc Zyngier)

  - Don't use FAST_LINK_MODE on meson (Marc Zyngier)

  - Add Socionext UniPhier Pro5 PCIe endpoint controller driver and DT
    description (Kunihiko Hayashi)

* remotes/lorenzo/pci/dwc:
  PCI: uniphier: Add Socionext UniPhier Pro5 PCIe endpoint controller driver
  dt-bindings: PCI: Add UniPhier PCIe endpoint controller description
  PCI: dwc: Use private data pointer of "struct irq_domain" to get pcie_port
  PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link
  PCI: dwc: Fix inner MSI IRQ domain registration
  PCI: dwc: pci-dra7xx: Use devm_platform_ioremap_resource_byname()
  PCI: dwc: intel: Make intel_pcie_cpu_addr() static
  PCI: dwc: Program outbound ATU upper limit register
  PCI: dwc: Make hisi_pcie_platform_ops static
  PCI: dwc: Clean up computing of msix_tbl

Merge branch 'remotes/lorenzo/pci/cadence'

  - Deprecate 'cdns,max-outbound-regions' and 'cdns,no-bar-match-nbits'
    bindings in favor of deriving them from 'ranges' and 'dma-ranges'
    (Kishon Vijay Abraham I)

  - Read Vendor and Device ID as 32 bits (not 16) from DT (Kishon Vijay
    Abraham I)

* remotes/lorenzo/pci/cadence:
  PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DT
  PCI: cadence: Remove "cdns,max-outbound-regions" DT property
  dt-bindings: PCI: cadence: Deprecate inbound/outbound specific bindings

Merge branch 'remotes/lorenzo/pci/brcmstb'

  - Assert fundamental reset on initialization (Nicolas Saenz Julienne)

  - Remove unnecessary clk_put(); devm_clk_get() handles this automatically
    (Jim Quinlan)

  - Fix outbound memory window register stride offset (Jim Quinlan)

  - Add "aspm-no-l0s" property for brcmstb and disable ASPM L0s when
    present (Jim Quinlan)

  - Add property to notify Raspberry Pi firmware of xHCI reset (Nicolas
    Saenz Julienne)

  - Add Raspberry Pi VL805 xHCI init function to trigger VL805 firmware
    load (Nicolas Saenz Julienne)

  - Wait in brcmstb probe for Raspberry Pi VL805 firmware initialization
    (Nicolas Saenz Julienne)

  - Load Raspberry Pi VL805 firmware in USB early handoff quirk (Nicolas
    Saenz Julienne)

* remotes/lorenzo/pci/brcmstb:
  USB: pci-quirks: Add Raspberry Pi 4 quirk
  PCI: brcmstb: Wait for Raspberry Pi's firmware when present
  firmware: raspberrypi: Introduce vl805 init routine
  soc: bcm2835: Add notify xHCI reset property
  PCI: brcmstb: Disable L0s component of ASPM if requested
  dt-bindings: PCI: brcmstb: New prop 'aspm-no-l0s'
  PCI: brcmstb: Fix window register offset from 4 to 8
  PCI: brcmstb: Don't clk_put() a managed clock
  PCI: brcmstb: Assert fundamental reset on initialization

Merge branch 'remotes/lorenzo/pci/altera'

  - Fix altera whitespace (Colin Ian King)

* remotes/lorenzo/pci/altera:
  PCI: altera: Clean up indentation issue on a return statement

Merge branch 'remotes/lorenzo/pci/aardvark'

  - Train link immediately after enabling link training to avoid issues
    with Compex WLE900VX and Turris MOX devices (Pali Rohár)

  - Remove ASPM config and let the PCI core do it (Pali Rohár)

  - Interpret zero 'max-link-speed' value as invalid (Pali Rohár)

  - Respect the 'max-link-speed' property and improve link training (Marek
    Behún)

  - Issue PERST via GPIO (Pali Rohár)

  - Add PHY support (Marek Behún)

  - Use standard PCIe capability macros (Pali Rohár)

  - Document new 'max-link-speed', 'phys', and 'reset-gpios' properties
    (Marek Behún)

* remotes/lorenzo/pci/aardvark:
  dt-bindings: PCI: aardvark: Describe new properties
  PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros
  PCI: aardvark: Add PHY support
  PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
  PCI: aardvark: Issue PERST via GPIO
  PCI: aardvark: Improve link training
  PCI: of: Zero max-link-speed value is invalid
  PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register
  PCI: aardvark: Train link immediately after enabling training

Merge branch 'pci/virtualization'

  - Remove unused xen_register_pirq() parameter (Wei Liu)

  - Quirk AMD Matisse HD Audio & USB 3.0 devices where FLR hangs the device
    (Marcos Scriven)

  - Quirk AMD Starship USB 3.0 device where FLR doesn't seem to work (Kevin
    Buettner)

  - Add ACS quirk for Intel RCiEPs (Ashok Raj)

* pci/virtualization:
  PCI: Add ACS quirk for Intel Root Complex Integrated Endpoints
  PCI: Avoid FLR for AMD Starship USB 3.0
  PCI: Avoid FLR for AMD Matisse HD Audio & USB 3.0
  x86/PCI: Drop unused xen_register_pirq() gsi_override parameter

Merge branch 'pci/switchtec'

  - Fix a minor bool type issue (Krzysztof Wilczynski)

* pci/switchtec:
  PCI/switchtec: Correct bool variable type assignment

Merge branch 'pci/resource'

  - Allow resizing BARs of devices on root bus (Ard Biesheuvel)

* pci/resource:
  PCI: Allow pci_resize_resource() for devices on root bus

Merge branch 'pci/pm'

  - Check .bridge_d3() hook for NULL before calling it (Bjorn Helgaas)

  - Disable PME# for Pericom OHCI/UHCI USB controllers because it's
    not reliably asserted on USB hotplug (Kai-Heng Feng)

  - Assume ports without DLL Link Active train links in 100 ms to work
    around Thunderbolt bridge defects (Mika Westerberg)

* pci/pm:
  PCI/PM: Assume ports without DLL Link Active train links in 100 ms
  PCI/PM: Adjust pcie_wait_for_link_delay() for caller delay
  PCI: Avoid Pericom USB controller OHCI/EHCI PME# defect
  serial: 8250_pci: Move Pericom IDs to pci_ids.h
  PCI/PM: Call .bridge_d3() hook only if non-NULL

Merge branch 'pci/p2pdma'

  - Add AMD Zen Raven and Renoir Root Ports to P2PDMA whitelist (Alex
    Deucher)

* pci/p2pdma:
  PCI/P2PDMA: Add AMD Zen Raven and Renoir Root Ports to whitelist

Merge branch 'pci/misc'

  - Clarify that platform_get_irq() should never return 0 (Bjorn Helgaas)

  - Check for platform_get_irq() failure consistently (Bjorn Helgaas)

  - Replace zero-length array with flexible-array (Gustavo A. R. Silva)

  - Unify pcie_find_root_port() and pci_find_pcie_root_port() (Yicong Yang)

  - Quirk Intel C620 MROMs, which have non-BARs in BAR locations (Xiaochun
    Lee)

  - Fix pcie_pme_resume() and pcie_pme_remove() kernel-doc (Jay Fang)

  - Rename _DSM constants to align with spec (Krzysztof Wilczyński)

* pci/misc:
  PCI: Rename _DSM constants to align with spec
  PCI/PME: Fix kernel-doc of pcie_pme_resume() and pcie_pme_remove()
  x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs
  PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port()
  PCI: Replace zero-length array with flexible-array
  PCI: Check for platform_get_irq() failure consistently
  driver core: platform: Clarify that IRQ 0 is invalid

Merge branch 'pci/kconfig'

  - Remove unnecessary "default y" Kconfig options (Bjorn Helgaas)

* pci/kconfig:
  PCI/AER: Don't select CONFIG_PCIEAER by default
  PCI: keystone: Don't select CONFIG_PCI_KEYSTONE_HOST by default
  PCI: dra7xx: Don't select CONFIG_PCI_DRA7XX_HOST by default

Merge branch 'pci/hotplug'

  - Remove unused pciehp EMI() and HP_SUPR_RM() macros (Ani Sinha)

  - Use of_node_name_eq() for node name comparisons (Rob Herring)

  - Convert shpchp_unconfigure_device() to void (Krzysztof Wilczynski)

* pci/hotplug:
  PCI: shpchp: Make shpchp_unconfigure_device() void
  PCI: Use of_node_name_eq() for node name comparisons
  PCI: pciehp: Remove unused EMI() and HP_SUPR_RM() macros

Merge branch 'pci/error'

  - Log only ACPI_NOTIFY_DISCONNECT_RECOVER events for EDR, not all ACPI
    SYSTEM-level events (Kuppuswamy Sathyanarayanan)

  - Rely only on _OSC (not _OSC + HEST FIRMWARE_FIRST) to negotiate AER
    Capability ownership (Alexandru Gagniuc)

  - Remove HEST/FIRMWARE_FIRST parsing that was previously used to help
    intuit AER Capability ownership (Kuppuswamy Sathyanarayanan)

  - Remove redundant pci_is_pcie() and dev->aer_cap checks (Kuppuswamy
    Sathyanarayanan)

  - Print IRQ number used by DPC (Yicong Yang)

* pci/error:
  PCI/DPC: Print IRQ number used by port
  PCI/AER: Use "aer" variable for capability offset
  PCI/AER: Remove redundant dev->aer_cap checks
  PCI/AER: Remove redundant pci_is_pcie() checks
  PCI/AER: Remove HEST/FIRMWARE_FIRST parsing for AER ownership
  PCI/AER: Use only _OSC to determine AER ownership
  PCI/EDR: Log only ACPI_NOTIFY_DISCONNECT_RECOVER events

Merge branch 'pci/enumeration'

  - Fix pci_register_host_bridge() device_register() error handling (Rob
    Herring)

  - Fix pci_host_bridge struct device release/free handling (Rob Herring)

  - Program MPS for RCiEP devices (Ashok Raj)

  - Inherit PTM settings from Switch Upstream Port so we can enable PTM on
    Endpoints (Bjorn Helgaas)

  - Add #defines for bridge windows (PCI_BRIDGE_IO_WINDOW,
    PCI_BRIDGE_MEM_WINDOW, etc) (Krzysztof Wilczynski)

* pci/enumeration:
  pcmcia: Use CardBus window names (PCI_CB_BRIDGE_IO_0_WINDOW etc) when freeing
  PCI: Use bridge window names (PCI_BRIDGE_IO_WINDOW etc)
  PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port
  PCI: Program MPS for RCiEP devices
  PCI: Fix pci_host_bridge struct device release/free handling
  PCI: Fix pci_register_host_bridge() device_register() error handling

Merge branch 'pci/aspm'

  - Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges (Kai-Heng Feng)

* pci/aspm:
  PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges

PCI: uniphier: Add Socionext UniPhier Pro5 PCIe endpoint controller driver

Add driver for the Socionext UniPhier Pro5 SoC endpoint controller.
This controller is based on the DesignWare PCIe core.

And add "host" to existing controller descriontions for the host controller
in Kconfig.

Link: https://lore.kernel.org/r/1589457801-12796-3-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>

PCI: Add ACS quirk for Intel Root Complex Integrated Endpoints

All Intel platforms guarantee that all root complex implementations must
send transactions up to IOMMU for address translations. Hence for Intel
RCiEP devices, we can assume some ACS-type isolation even without an ACS
capability.

From the Intel VT-d spec, r3.1, sec 3.16 ("Root-Complex Peer to Peer
Considerations"):

  When DMA remapping is enabled, peer-to-peer requests through the
  Root-Complex must be handled as follows:

  - The input address in the request is translated (through first-level,
    second-level or nested translation) to a host physical address (HPA).
    The address decoding for peer addresses must be done only on the
    translated HPA. Hardware implementations are free to further limit
    peer-to-peer accesses to specific host physical address regions (or
    to completely disallow peer-forwarding of translated requests).

  - Since address translation changes the contents (address field) of
    the PCI Express Transaction Layer Packet (TLP), for PCI Express
    peer-to-peer requests with ECRC, the Root-Complex hardware must use
    the new ECRC (re-computed with the translated address) if it
    decides to forward the TLP as a peer request.

  - Root-ports, and multi-function root-complex integrated endpoints, may
    support additional peer-to-peer control features by supporting PCI
    Express Access Control Services (ACS) capability. Refer to ACS
    capability in PCI Express specifications for details.

Since Linux didn't give special treatment to allow this exception, certain
RCiEP MFD devices were grouped in a single IOMMU group. This doesn't permit
a single device to be assigned to a guest for instance.

In one vendor system: Device 14.x were grouped in a single IOMMU group.

  /sys/kernel/iommu_groups/5/devices/0000:00:14.0
  /sys/kernel/iommu_groups/5/devices/0000:00:14.2
  /sys/kernel/iommu_groups/5/devices/0000:00:14.3

After this patch:

  /sys/kernel/iommu_groups/5/devices/0000:00:14.0
  /sys/kernel/iommu_groups/5/devices/0000:00:14.2
  /sys/kernel/iommu_groups/6/devices/0000:00:14.3 <<< new group

14.0 and 14.2 are integrated devices, but legacy end points, whereas 14.3
was a PCIe-compliant RCiEP.

  00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
    Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00

This permits assigning this device to a guest VM.

[bhelgaas: drop "Fixes" tag since this doesn't fix a bug in that commit]
Link: https://lore.kernel.org/r/1590699462-7131-1-git-send-email-ashok.raj@intel.com
Tested-by: Darrel Goeddel <dgoeddel@forcepoint.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Cc: stable@vger.kernel.org
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Mark Scott <mscott@forcepoint.com>,
Cc: Romil Sharma <rsharma@forcepoint.com>

PCI/DPC: Print IRQ number used by port

Print IRQ number used by DPC port, like AER/PME does.  It provides
convenience to track DPC interrupts counts of certain port from
/proc/interrupts.

Link: https://lore.kernel.org/r/1589018214-52752-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/AER: Use "aer" variable for capability offset

Previously we used "pos" or "aer_pos" for the offset of the AER Capability.
Use "aer" consistently and initialize it the same way everywhere.  No
functional change intended.

Link: https://lore.kernel.org/r/20200529230915.GA479883@bjorn-Precision-5520
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

PCI/AER: Remove redundant dev->aer_cap checks

pcie_aer_get_firmware_first() checks dev->aer_cap, so we can remove
redundant dev->aer_cap checks in the callers.

Link: https://lore.kernel.org/r/d5ccc7a060ec9cdc234bdae7df8a0a4410f13f42.1590534843.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/AER: Remove redundant pci_is_pcie() checks

AER is a PCIe Extended Capability, so dev->aer_cap will only be set for
PCIe devices.  Remove redundant pci_is_pcie() checks.

Link: https://lore.kernel.org/r/361c622eabe5b845b8092e0bec04a3a2c262cb38.1590534843.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/AER: Remove HEST/FIRMWARE_FIRST parsing for AER ownership

Commit c100beb9ccfb ("PCI/AER: Use only _OSC to determine AER ownership")
removed the use of HEST in determining AER ownership, but the AER driver
still used HEST to verify AER ownership in some of its APIs.

Per the ACPI spec v6.3, sec 18.3.2.4, some HEST table entries contain a
FIRMWARE_FIRST bit, but that bit does not tell us anything about ownership
of the AER capability.

Remove parsing of HEST to look for FIRMWARE_FIRST.

Add pcie_aer_is_native() for the places that need to know whether the OS
owns the AER capability.

[bhelgaas: commit log, reorder patch, remove unused __aer_firmware_first]
Link: https://lore.kernel.org/r/9a37f53a4e6ff4942ff8e18dbb20b00e16c47341.1590534843.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: tegra: Fix runtime PM imbalance on error

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Also, call pm_runtime_disable() when pm_runtime_get_sync() returns
an error code.

Link: https://lore.kernel.org/r/20200521024709.2368-1-dinghao.liu@zju.edu.cn
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>

PCI: tegra194: Fix runtime PM imbalance on error

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Link: https://lore.kernel.org/r/20200521031355.7022-1-dinghao.liu@zju.edu.cn
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Vidya Sagar <vidyas@nvidia.com>

dt-bindings: PCI: Add UniPhier PCIe endpoint controller description

Add DT bindings for PCIe controller implemented in UniPhier SoCs
when configured in endpoint mode. This controller is based on
the DesignWare PCIe core.

Link: https://lore.kernel.org/r/1589457801-12796-2-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>

PCI: hv: Use struct_size() helper

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct hv_dr_state {
...
        struct hv_pcidev_description func[];
};

struct pci_bus_relations {
...
        struct pci_function_description func[];
} __packed;

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.

So, replace the following forms:

offsetof(struct hv_dr_state, func) +
(sizeof(struct hv_pcidev_description) *
(relations->device_count))

offsetof(struct pci_bus_relations, func) +
(sizeof(struct pci_function_description) *
(bus_rel->device_count))

with:

struct_size(dr, func, relations->device_count)

and

struct_size(bus_rel, func, bus_rel->device_count)

respectively.

Link: https://lore.kernel.org/r/20200525164319.GA13596@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>

PCI: Rename _DSM constants to align with spec

Rename PCI-related _DSM constants to align them with the PCI Firmware Spec,
r3.2, sec 4.6.  No functional change intended.

Link: https://lore.kernel.org/r/20200526213905.2479381-1-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Avoid FLR for AMD Starship USB 3.0

The AMD Starship USB 3.0 host controller advertises Function Level Reset
support, but it apparently doesn't work.  Add a quirk to prevent use of FLR
on this device.

Without this quirk, when attempting to assign (pass through) an AMD
Starship USB 3.0 host controller to a guest OS, the system becomes
increasingly unresponsive over the course of several minutes, eventually
requiring a hard reset.  Shortly after attempting to start the guest, I see
these messages:

  vfio-pci 0000:05:00.3: not ready 1023ms after FLR; waiting
  vfio-pci 0000:05:00.3: not ready 2047ms after FLR; waiting
  vfio-pci 0000:05:00.3: not ready 4095ms after FLR; waiting
  vfio-pci 0000:05:00.3: not ready 8191ms after FLR; waiting

And then eventually:

  vfio-pci 0000:05:00.3: not ready 65535ms after FLR; giving up
  INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs
  perf: interrupt took too long (642744 > 2500), lowering kernel.perf_event_max_sample_rate to 1000
  INFO: NMI handler (perf_event_nmi_handler) took too long to run: 82.270 msecs
  INFO: NMI handler (perf_event_nmi_handler) took too long to run: 680.608 msecs
  INFO: NMI handler (perf_event_nmi_handler) took too long to run: 100.952 msecs
  ...
  watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [qemu-system-x86:7487]

Tested on a Micro-Star International Co., Ltd. MS-7C59/Creator TRX40
motherboard with an AMD Ryzen Threadripper 3970X.

Link: https://lore.kernel.org/r/20200524003529.598434ff@f31-4.lan
Signed-off-by: Kevin Buettner <kevinb@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Avoid FLR for AMD Matisse HD Audio & USB 3.0

The AMD Matisse HD Audio & USB 3.0 devices advertise Function Level Reset
support, but hang when an FLR is triggered.

To reproduce the problem, attach the device to a VM, then detach and try to
attach again.

Rename the existing quirk_intel_no_flr(), which was not Intel-specific, to
quirk_no_flr(), and apply it to prevent the use of FLR on these AMD
devices.

Link: https://lore.kernel.org/r/CAAri2DpkcuQZYbT6XsALhx2e6vRqPHwtbjHYeiH7MNp4zmt1RA@mail.gmail.com
Signed-off-by: Marcos Scriven <marcos@scriven.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Drop unused xen_register_pirq() gsi_override parameter

All callers of xen_register_pirq() pass -1 (no override) for the
gsi_override parameter.  Remove it and related code.

Link: https://lore.kernel.org/r/20200428153640.76476-1-wei.liu@kernel.org
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

PCI: dwc: Use private data pointer of "struct irq_domain" to get pcie_port

No functional change. Get "struct pcie_port *" from private data
pointer of "struct irq_domain" in dw_pcie_irq_domain_free() to make
it look similar to how "struct pcie_port *" is obtained in
dw_pcie_irq_domain_alloc()

Link: https://lore.kernel.org/r/20191220100550.777-1-kishon@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>

PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link

The vim3l board does not work with a standard PCIe switch (ASM1184e),
spitting all kind of errors - hinting at HW misconfiguration (no link,
port enumeration issues, etc).

According to the the Synopsys DWC PCIe Reference Manual, in the section
dedicated to the PLCR register, bit 7 is described (FAST_LINK_MODE) as:

"Sets all internal timers to fast mode for simulation purposes."

it is sound to set this bit from a simulation perspective, but on actual
silicon, which expects timers to have a nominal value, it is not.

Make sure the FAST_LINK_MODE bit is cleared when configuring the RC
to solve this problem.

Link: https://lore.kernel.org/r/20200429164230.309922-1-maz@kernel.org
Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Signed-off-by: Marc Zyngier <maz@kernel.org>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: dwc: Fix inner MSI IRQ domain registration

On a system that uses the internal DWC MSI widget, I get this
warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected:

  debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present!

This is due to the fact that the DWC MSI code tries to register two
IRQ domains for the same firmware node, without telling the low
level code how to distinguish them (by setting a bus token). This
further confuses debugfs which tries to create corresponding
files for each domain.

Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is
the closest thing we have as to "generic MSI".

Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>

PCI: dwc: pci-dra7xx: Use devm_platform_ioremap_resource_byname()

platform_get_resource() may fail and return NULL, so we had better
check its return value to avoid a NULL pointer dereference a bit later
in the code. Fix it to use devm_platform_ioremap_resource_byname()
instead of calling platform_get_resource_byname() and devm_ioremap().

Link: https://lore.kernel.org/r/20200429015027.134485-1-weiyongjun1@huawei.com
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

PCI: dwc: intel: Make intel_pcie_cpu_addr() static

Fix the following sparse warning:

drivers/pci/controller/dwc/pcie-intel-gw.c:456:5: warning: symbol
'intel_pcie_cpu_addr' was not declared. Should it be static?

Link: https://lore.kernel.org/r/20200415084953.6533-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

PCI: dwc: Program outbound ATU upper limit register

Function dw_pcie_prog_outbound_atu_unroll() does not program the upper
32-bit ATU limit register. Since ATU programming functions limit the
size of the translated region to 4GB by using a u32 size parameter,
these issues may combine into undefined behavior for resource sizes
with non-zero upper 32-bits.

For example, a 128GB address space starting at physical CPU address of
0x2000000000 with size of 0x2000000000 needs the following values
programmed into the lower and upper 32-bit limit registers:
 0x3fffffff in the upper 32-bit limit register
 0xffffffff in the lower 32-bit limit register

Currently, only the lower 32-bit limit register is programmed with a
value of 0xffffffff but the upper 32-bit limit register is not being
programmed. As a result, the upper 32-bit limit register remains at its
default value after reset of 0x0.

These issues may combine to produce undefined behavior since the ATU
limit address may be lower than the ATU base address. Programming the
upper ATU limit address register prevents such undefined behavior despite
the region size getting truncated due to the 32-bit size limit.

Link: https://lore.kernel.org/r/1585785493-23210-1-git-send-email-alan.mikhak@sifive.com
Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>

PCI: pci-bridge-emul: Eliminate the 'reserved' member

Per PCIe 5.0 r1.0, Terms and Acronyms, Page 80:

  Reserved register fields must be read only and must return 0 (all 0's
  for multi-bit fields) when read. Reserved encodings for register and
  packet fields must not be used. Any implementation dependence on a
  Reserved field value or encoding will result in an implementation that
  is not PCI Express-compliant.

This patch ensures reads will return 0 for any bit not in the Read-Only,
Read-Write, or Write-1-to-Clear bitmasks.

Link: https://lore.kernel.org/r/20200511162117.6674-5-jonathan.derrick@intel.com
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: pci-bridge-emul: Update for PCIe 5.0 r1.0

Add missing bits from PCIe 4.0 and updates for PCIe 5.0 r1.0.

PCIe 4.0:
Device Status bit 6 - W1C - Emergency Power Reduction Detected
Link Control bits 15:14 - RW - DRS Signaling Control
Slot Control bit 13 - RW - Auto Slow Power Limit Disable

PCIe 5.0:
Slot Control bit 14 - RW - In-Band PD Disable

Link: https://lore.kernel.org/r/20200511162117.6674-4-jonathan.derrick@intel.com
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: pci-bridge-emul: Fix Root Cap/Status comment

The upper 16-bits of Root Control contain the Root Capabilities
register. The code instead describes the Root Status register in the
upper 16-bits, although it uses the correct bit definition for Root
Capabilities, and for Root Status in the next definition.

Fix this comment and add a comment describing the Root Status register.

Link: https://lore.kernel.org/r/20200511162117.6674-3-jonathan.derrick@intel.com
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: pci-bridge-emul: Fix PCIe bit conflicts

This patch fixes two bit conflicts in the pci-bridge-emul driver:

1. Bit 3 of Device Status (19 of Device Control) is marked as both
   Write-1-to-Clear and Read-Only. It should be Write-1-to-Clear.
   The Read-Only and Reserved bitmasks are shifted by 1 bit due to this
   error.

2. Bit 12 of Slot Control is marked as both Read-Write and Reserved.
   It should be Read-Write.

Link: https://lore.kernel.org/r/20200511162117.6674-2-jonathan.derrick@intel.com
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

MAINTAINERS: Add file patterns for rcar PCI device tree bindings

Add file pattern entry for rcar PCI devicetree binding, so that when
people run ./scripts/get_maintainer.pl the rcar PCI maintainers could also
be listed.

Link: https://lore.kernel.org/r/1588854799-13710-9-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

PCI: rcar: Add endpoint mode support

Add support for R-Car PCIe controller to work in endpoint mode.

Link: https://lore.kernel.org/r/1588854799-13710-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

dt-bindings: PCI: rcar: Add bindings for R-Car PCIe endpoint controller

This patch adds the bindings for the R-Car PCIe endpoint driver.

Link: https://lore.kernel.org/r/1588854799-13710-7-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

PCI: endpoint: Add support to handle multiple base for mapping outbound memory

R-Car PCIe controller has support to map multiple memory regions for
mapping the outbound memory in local system also the controller limits
single allocation for each region (that is, once a chunk is used from the
region it cannot be used to allocate a new one). This features inspires to
add support for handling multiple memory bases in endpoint framework.

With this patch pci_epc_mem_init() initializes address space for endpoint
controller which support single window and pci_epc_multi_mem_init()
initializes multiple windows supported by endpoint controller.

Link: https://lore.kernel.org/r/1588854799-13710-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>

pcmcia: Use CardBus window names (PCI_CB_BRIDGE_IO_0_WINDOW etc) when freeing

Remove the loop used to free CardBus resources and replace it with
a yenta_free_res() helper used to release bridge resources explicitly.

Link: https://lore.kernel.org/r/20200520183411.1534621-3-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>

PCI: Use bridge window names (PCI_BRIDGE_IO_WINDOW etc)

Use bridge resource definitions instead of using the PCI_BRIDGE_RESOURCES
constant with an integer offeset.

Link: https://lore.kernel.org/r/20200520183411.1534621-2-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port

Except for Endpoints, we enable PTM at enumeration-time.  Previously we did
not account for the fact that Switch Downstream Ports are not permitted to
have a PTM capability; their PTM behavior is controlled by the Upstream
Port (PCIe r5.0, sec 7.9.16).  Since Downstream Ports don't have a PTM
capability, we did not mark them as "ptm_enabled", which meant that
pci_enable_ptm() on an Endpoint failed because there was no PTM path to it.

Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM
enabled.

Fixes: eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints")
Reported-by: Aditya Paluri <Venkata.AdityaPaluri@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: shpchp: Make shpchp_unconfigure_device() void

shpchp_unconfigure_device() always returned 0, so there's no reason for a
return value.  In addition, remove_board() checked the return value for
possible error which is unnecessary.

Convert shpchp_unconfigure_device() to a void function and remove the
return value check.  This addresses the following Coccinelle warning:

  drivers/pci/hotplug/shpchp_pci.c:66:5-7: Unneeded variable: "rc".  Return "0" on line 86

Link: https://lore.kernel.org/r/20200521190457.1066600-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/switchtec: Correct bool variable type assignment

Use "true" instead of 1 to initialize "bool use_dma_mrpc".  This resolves
the following Coccinelle warning:

  drivers/pci/switch/switchtec.c:28:12-24: WARNING: Assignment of 0/1 to bool variable

Link: https://lore.kernel.org/r/20200521200439.1076672-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

PCI/PME: Fix kernel-doc of pcie_pme_resume() and pcie_pme_remove()

Fix kernel-doc of the "srv" parameter to pcie_pme_resume() and
pcie_pme_remove().  Building with W=1 produced these warnings:

  drivers/pci/pcie/pme.c:414: warning: Function parameter or member 'srv' not described in 'pcie_pme_resume'
  drivers/pci/pcie/pme.c:437: warning: Function parameter or member 'srv' not described in 'pcie_pme_remove'

Link: https://lore.kernel.org/r/1589612414-61682-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DT

The PCI Bus Binding specification (IEEE Std 1275-1994 Revision 2.1 [1])
defines both Vendor ID and Device ID to be 32-bits. Fix
pcie-cadence-host.c driver to read 32-bit Vendor ID and Device ID
properties from device tree.

[1] -> https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf

Link: https://lore.kernel.org/r/20200508130646.23939-4-kishon@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Tom Joseph <tjoseph@cadence.com>

PCI: cadence: Remove "cdns,max-outbound-regions" DT property

"cdns,max-outbound-regions" device tree property provides the
maximum number of outbound regions supported by the Host PCIe
controller. However the outbound regions are configured based
on what is populated in the "ranges" DT property.

Avoid using two properties for configuring outbound regions and
use only "ranges" property instead.

Link: https://lore.kernel.org/r/20200508130646.23939-3-kishon@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Tom Joseph <tjoseph@cadence.com>

dt-bindings: PCI: cadence: Deprecate inbound/outbound specific bindings

Deprecate cdns,max-outbound-regions and cdns,no-bar-match-nbits for
host mode as both these could be derived from "ranges" and "dma-ranges"
property. "cdns,max-outbound-regions" property would still be required
for EP mode.

Link: https://lore.kernel.org/r/20200508130646.23939-2-kishon@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Tom Joseph <tjoseph@cadence.com>

dt-bindings: PCI: aardvark: Describe new properties

Document the possibility to reference a PHY and reset-gpios and to set
max-link-speed property.

Link: https://lore.kernel.org/r/20200430080625.26070-10-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org

PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros

PCI-E capability macros are already defined in linux/pci_regs.h.
Remove their reimplementation in pcie-aardvark.

Link: https://lore.kernel.org/r/20200430080625.26070-9-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: aardvark: Add PHY support

With recent proposed changes for U-Boot it is possible that bootloader
won't initialize the PHY for this controller (currently the PHY is
initialized regardless whether PCI is used in U-Boot, but with these
proposed changes the PHY is initialized only on request).

Since the mvebu-a3700-comphy driver by Miquèl Raynal supports enabling
PCIe PHY, and since Linux' functionality should be independent on what
bootloader did, add code for enabling generic PHY if found in device OF
node.

The mvebu-a3700-comphy driver does PHY powering via SMC calls to ARM
Trusted Firmware. The corresponding code in ARM Trusted Firmware skips
one register write which U-Boot does not: step 7 ("Enable TX"), see [1].
Instead ARM Trusted Firmware expects PCIe driver to do this step,
probably because the register is in PCIe controller address space,
instead of PHY address space. We therefore add this step into the
advk_pcie_setup_hw function.

[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/marvell/comphy/phy-comphy-3700.c?h=v2.3-rc2#n836

Link: https://lore.kernel.org/r/20200430080625.26070-8-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Miquèl Raynal <miquel.raynal@bootlin.com>

PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access

This register is applicable only when the controller is configured for
Endpoint mode, which is not the case for the current version of this
driver.

Attempting to remove this code though caused some ath10k cards to stop
working, so for some unknown reason it is needed here.

This should be investigated and a comment explaining this should be put
before the code, so we add a FIXME comment for now.

Link: https://lore.kernel.org/r/20200430080625.26070-7-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: aardvark: Issue PERST via GPIO

Add support for issuing PERST via GPIO specified in 'reset-gpios'
property (as described in PCI device tree bindings).

Some buggy cards (e.g. Compex WLE900VX or WLE1216) are not detected
after reboot when PERST is not issued during driver initialization.

If bootloader already enabled link training then issuing PERST has no
effect for some buggy cards (e.g. Compex WLE900VX) and these cards are
not detected. We therefore clear the LINK_TRAINING_EN register before.

It was observed that Compex WLE900VX card needs to be in PERST reset
for at least 10ms if bootloader enabled link training.

Tested on Turris MOX.

Link: https://lore.kernel.org/r/20200430080625.26070-6-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: aardvark: Improve link training

Currently the aardvark driver trains link in PCIe gen2 mode. This may
cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or
even not detected. Moreover when ASPM code tries to retrain link second
time, these cards may stop responding and link goes down. If gen1 is
used this does not happen.

Unconditionally forcing gen1 is not a good solution since it may have
performance impact on gen2 cards.

To overcome this, read 'max-link-speed' property (as defined in PCI
device tree bindings) and use this as max gen mode. Then iteratively try
link training at this mode or lower until successful. After successful
link training choose final controller gen based on Negotiated Link Speed
from Link Status register, which should match card speed.

Link: https://lore.kernel.org/r/20200430080625.26070-5-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: of: Zero max-link-speed value is invalid

Interpret zero value of max-link-speed property as invalid,
as the device tree bindings documentation specifies.

Link: https://lore.kernel.org/r/20200430080625.26070-4-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register

Trying to change Link Status register does not have any effect as this
is a read-only register. Trying to overwrite bits for Negotiated Link
Width does not make sense.

In future proper change of link width can be done via Lane Count Select
bits in PCIe Control 0 register.

Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link
Control register is wrong. There should be at least some detection if
endpoint supports L0s as isn't mandatory.

Moreover ASPM Control bits in Link Control register are controlled by
pcie/aspm.c code which sets it according to system ASPM settings,
immediately after aardvark driver probes. So setting these bits by
aardvark driver has no long running effect.

Remove code which touches ASPM L0s bits from this driver and let
kernel's ASPM implementation to set ASPM state properly.

Some users are reporting issues that this code is problematic for some
Intel wifi cards and removing it fixes them, see e.g.:
https://bugzilla.kernel.org/show_bug.cgi?id=196339

If problems with Intel wifi cards occur even after this commit, then
pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state
for affected problematic cards.

Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI: aardvark: Train link immediately after enabling training

Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link
training and starting link training causes detection issues with some
buggy cards (such as Compex WLE900VX).

Move the code which enables link training immediately before the one
which starts link traning.

This fixes detection issues of Compex WLE900VX card on Turris MOX after
cold boot.

Link: https://lore.kernel.org/r/20200430080625.26070-2-pali@kernel.org
Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...")
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

PCI/PM: Assume ports without DLL Link Active train links in 100 ms

Kai-Heng Feng reported that it takes a long time (> 1 s) to resume
Thunderbolt-connected devices from both runtime suspend and system sleep
(s2idle).

This was because some Downstream Ports that support > 5 GT/s do not also
support Data Link Layer Link Active reporting.  Per PCIe r5.0 sec 6.6.1:

  With a Downstream Port that supports Link speeds greater than 5.0 GT/s,
  software must wait a minimum of 100 ms after Link training completes
  before sending a Configuration Request to the device immediately below
  that Port. Software can determine when Link training completes by polling
  the Data Link Layer Link Active bit or by setting up an associated
  interrupt (see Section 6.7.3.3).

Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but
at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel
JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not.

Previously we tried to wait for Link training to complete, but since there
was no DLL Link Active reporting, all we could do was wait the worst-case
1000 ms, then another 100 ms.

Instead of using the supported speeds to determine whether to wait for Link
training, check whether the port supports DLL Link Active reporting.  The
Ports in question do not, so we'll wait only the 100 ms required for Ports
that support Link speeds <= 5 GT/s.

This of course assumes these Ports always train the Link within 100 ms even
if they are operating at > 5 GT/s, which is not required by the spec.

[bhelgaas: commit log, comment]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837
Link: https://lore.kernel.org/r/20200514133043.27429-1-mika.westerberg@linux.intel.com
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/PM: Adjust pcie_wait_for_link_delay() for caller delay

The caller of pcie_wait_for_link_delay() specifies the time to wait after
the link becomes active.  When the downstream port doesn't support link
active reporting, obviously we can't tell when the link becomes active, so
we waited the worst-case time (1000 ms) plus 100 ms, ignoring the delay
from the caller.

Instead, wait for 1000 ms + the delay from the caller.

Fixes: 4827d63891b6 ("PCI/PM: Add pcie_wait_for_link_delay()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs

The Intel C620 Platform Controller Hub has MROM functions that have non-PCI
registers (undocumented in the public spec) where BAR 0 is supposed to be,
which results in messages like this:

  pci 0000:00:11.0: [Firmware Bug]: reg 0x30: invalid BAR (can't size)

Mark these MROM functions as having non-compliant BARs so we don't try to
probe any of them.  There are no other BARs on these devices.

See the Intel C620 Series Chipset Platform Controller Hub Datasheet,
May 2019, Document Number 336067-007US, sec 2.1, 35.5, 35.6.

[bhelgaas: commit log, add 0xa26d]
Link: https://lore.kernel.org/r/1589513467-17070-1-git-send-email-lixiaochun.2888@163.com
Signed-off-by: Xiaochun Lee <lixc17@lenovo.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

PCI: Program MPS for RCiEP devices

Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge,
so pci_configure_mps() previously ignored them, which may result in reduced
performance.

Instead, program the Max_Payload_Size of RCiEPs to the maximum supported
value (unless it is limited for the PCIE_BUS_PEER2PEER case).  This also
affects the subsequent programming of Max_Read_Request_Size because Linux
programs MRRS based on the MPS value.

Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to pci_configure_device()")
Link: https://lore.kernel.org/r/1585343775-4019-1-git-send-email-ashok.raj@intel.com
Tested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

PCI: Fix pci_host_bridge struct device release/free handling

The PCI code has several paths where the struct pci_host_bridge is freed
directly. This is wrong because it contains a struct device which is
refcounted and should be freed using put_device(). This can result in
use-after-free errors. I think this problem has existed since 2012 with
commit 7b5436635800 ("PCI: add generic device into pci_host_bridge
struct"). It generally hasn't mattered as most host bridge drivers are
still built-in and can't unbind.

The problem is a struct device should never be freed directly once
device_initialize() is called and a ref is held, but that doesn't happen
until pci_register_host_bridge(). There's then a window between allocating
the host bridge and pci_register_host_bridge() where kfree should be used.
This is fragile and requires callers to do the right thing. To fix this, we
need to split device_register() into device_initialize() and device_add()
calls, so that the host bridge struct is always freed by using a
put_device().

devm_pci_alloc_host_bridge() is using devm_kzalloc() to allocate struct
pci_host_bridge which will be freed directly. Instead, we can use a custom
devres action to call put_device().

Link: https://lore.kernel.org/r/20200513223859.11295-2-robh@kernel.org
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

PCI: Fix pci_register_host_bridge() device_register() error handling

If device_register() has an error, we should bail out of
pci_register_host_bridge() rather than continuing on.

Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface")
Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>

PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port()

Previously we used pcie_find_root_port() to find a Root Port from a PCIe
device and pci_find_pcie_root_port() to find a Root Port from a
Conventional PCI device.

Unify the two functions and use pcie_find_root_port() to find a Root Port
from either a Conventional PCI device or a PCIe device.  Then there is no
need to distinguish the type of the device.

Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # thunderbolt

USB: pci-quirks: Add Raspberry Pi 4 quirk

On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
VideoCore. Inform VideoCore that VL805 was just reset.

Also, as this creates a dependency between USB_PCI and VideoCore's
firmware interface, and since USB_PCI can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.

Link: https://lore.kernel.org/r/20200505161318.26200-5-nsaenzjulienne@suse.de
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>

PCI: brcmstb: Wait for Raspberry Pi's firmware when present

xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
RPi4's VideoCore firmware interface to be up and running. It's possible
for both initializations to race, so make sure it's available prior to
starting.

Link: https://lore.kernel.org/r/20200505161318.26200-4-nsaenzjulienne@suse.de
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>

firmware: raspberrypi: Introduce vl805 init routine

The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
that implements xHCI. After a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
co-processor, VideoCore. RPi4's VideoCore OS contains both the non public
firmware load logic and the VL805 firmware blob. The function this patch
introduces triggers the aforementioned process.

Link: https://lore.kernel.org/r/20200505161318.26200-3-nsaenzjulienne@suse.de
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>

soc: bcm2835: Add notify xHCI reset property

The property is needed in order to trigger VL805's firmware load. Note
that gap between the property introduced and the previous one is due to
the properties not being defined.

Link: https://lore.kernel.org/r/20200505161318.26200-2-nsaenzjulienne@suse.de
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>

PCI: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these as a flexible array member [1][2], introduced in C99:

  struct foo {
    int stuff;
    struct boo array[];
  };

By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that dynamic memory allocations won't be affected by this
change:

  Flexible array members have incomplete type, and so the sizeof operator
  may not be applied. As a quirk of the original implementation of
  zero-length arrays, sizeof evaluates to zero. [1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type [1]. There are some instances of code in which
the sizeof() operator is being incorrectly/erroneously applied to
zero-length arrays, and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also help
to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200507190544.GA15633@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Check for platform_get_irq() failure consistently

The platform_get_irq*() interfaces return either a negative error number or
a valid IRQ.  0 is not a valid return value, so check for "< 0" to detect
failure as recommended by the function documentation.

On failure, return the error number from platform_get_irq*() instead of
making up a new one.

Link: https://lore.kernel.org/r/cover.1583952275.git.amanharitsh123@gmail.com
[bhelgaas: commit log, squash into one patch]
Signed-off-by: Aman Sharma <amanharitsh123@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>

driver core: platform: Clarify that IRQ 0 is invalid

These interfaces return a negative error number or an IRQ:

  platform_get_irq()
  platform_get_irq_optional()
  platform_get_irq_byname()
  platform_get_irq_byname_optional()

The function comments suggest checking for error like this:

  irq = platform_get_irq(...);
  if (irq < 0)
    return irq;

which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0
is invalid.  But some callers check for "irq <= 0", and it's not obvious
from the source that we never return an IRQ 0.

Make this more explicit by updating the comments to say that an IRQ number
is always non-zero and adding a WARN() if we ever do return zero.  If we do
return IRQ 0, it likely indicates a bug in the arch-specific parts of
platform_get_irq().

Relevant prior discussion at [1, 2].

[1] https://lore.kernel.org/r/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/
[2] https://lore.kernel.org/r/Pine.LNX.4.64.0701252029570.25027@woody.linux-foundation.org/
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Documentation: PCI: Give unique labels to sections

Make subsection labels more specific to avoid sphinx warnings.

Exact warning:
 Documentation/PCI/endpoint/pci-endpoint.rst:208: WARNING: duplicate label
pci/endpoint/pci-endpoint:other apis, other instance in Documentation/PCI/endpoint/pci-endpoint.rst

Link: https://lore.kernel.org/r/20200503214926.23748-1-bryce.steven.willey@gmail.com
Signed-off-by: Bryce Willey <Bryce.Steven.Willey@gmail.com>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rob Herring <robh@kernel.org>

MAINTAINERS: correct typo in new NXP LAYERSCAPE GEN4

Commit 3edeb49525bb ("dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4
controller") includes a new entry in MAINTAINERS, but slipped in a typo in
one of the file entries.

Hence, since then, ./scripts/get_maintainer.pl --self-test complains:

  warning: no file matches F: \
    drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c

Correct the typo in PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER.

Link: https://lore.kernel.org/r/20200506052130.5780-1-lukas.bulwahn@gmail.com
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: hv: Retry PCI bus D0 entry on invalid device state

When kdump is triggered, some PCI devices may have not been shut down
cleanly before the kdump kernel starts.

This causes the initial attempt to enter D0 state in the kdump kernel to
fail with invalid device state returned from Hyper-V host.

When this happens, explicitly call hv_pci_bus_exit() and retry to enter
the D0 state.

Link: https://lore.kernel.org/r/20200507050300.10974-1-weh@microsoft.com
Signed-off-by: Wei Hu <weh@microsoft.com>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>

PCI: hv: Fix the PCI HyperV probe failure path to release resource properly

In some error cases in hv_pci_probe(), allocated resources are not freed.

Fix this by adding a field to keep track of the high water mark for slots
that have resources allocated to them.  In case of an error, this high
water mark is used to know which slots have resources that must be released.
Since slots are numbered starting with zero, a value of -1 indicates no
slots have been allocated resources.  There may be unused slots in the range
between slot 0 and the high water mark slot, but these slots are already
ignored by the existing code in the allocate and release loops with the call
to get_pcichild_wslot().

Link: https://lore.kernel.org/r/20200507050211.10923-1-weh@microsoft.com
Signed-off-by: Wei Hu <weh@microsoft.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>

PCI: brcmstb: Disable L0s component of ASPM if requested

Some informal internal experiments has shown that the BrcmSTB ASPM L0s
savings may introduce an undesirable noise signal on some customers'
boards.  In addition, L0s was found lacking in realized power savings,
especially relative to the L1 ASPM component.  This is BrcmSTB's
experience and may not hold for others.  At any rate, if the
'aspm-no-l0s' property is present L0s will be disabled.

Link: https://lore.kernel.org/r/20200507201544.43432-5-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

dt-bindings: PCI: brcmstb: New prop 'aspm-no-l0s'

For various reasons, one may want to disable the ASPM L0s
capability.

Link: https://lore.kernel.org/r/20200507201544.43432-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: brcmstb: Fix window register offset from 4 to 8

The outbound memory window registers were being referenced
with an incorrect stride offset.  This probably wasn't noticed
previously as there was likely only one such window employed.

Link: https://lore.kernel.org/r/20200507201544.43432-3-james.quinlan@broadcom.com
Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

PCI: brcmstb: Don't clk_put() a managed clock

clk_put() was being invoked on a clock obtained by
devm_clk_get_optional().

Link: https://lore.kernel.org/r/20200507201544.43432-2-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

PCI: brcmstb: Assert fundamental reset on initialization

While preparing the driver for upstream this detail was missed.

If not asserted during the initialization process, devices connected on
the bus will not be made aware of the internal reset happening. This,
potentially resulting in unexpected behavior.

Link: https://lore.kernel.org/r/20200507172020.18000-1-nsaenzjulienne@suse.de
Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>

PCI: endpoint: Pass page size as argument to pci_epc_mem_init()

pci_epc_mem_init() internally used page size equal to *PAGE_SIZE* to
manage the address space so instead just pass the page size as a
argument to pci_epc_mem_init().

Also make pci_epc_mem_init() as a C function instead of a macro function
in preparation for adding support for pci-epc-mem core to handle multiple
windows.

Link: https://lore.kernel.org/r/1588854799-13710-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>

PCI: rcar: Fix calculating mask for PCIEPAMR register

The mask value was calculated incorrectly for PCIEPAMR register if the
size was less than 128 bytes. Fix this issue by adding a check on size.

Link: https://lore.kernel.org/r/1588854799-13710-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

PCI: rcar: Move shareable code to a common file

Move shareable code to common file pcie-rcar.c and the #defines to
pcie-rcar.h so that the common code can be reused with endpoint driver.
There are no functional changes with this patch for the host controller
driver.

Link: https://lore.kernel.org/r/1588854799-13710-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.c

This commit renames pcie-rcar.c to pcie-rcar-host.c in preparation for
adding support for endpoint mode. CONFIG_PCIE_RCAR is kept so that arm64
defconfig change can be a separate patch.

With this patch both config options PCIE_RCAR and PCIE_RCAR_HOST will be
available but PCIE_RCAR internally selects PCIE_RCAR_HOST so that bisect
builds wont be affected.

Link: https://lore.kernel.org/r/1588854799-13710-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

PCI: tegra: Fix reporting GPIO error value

Error code is stored in rp->reset_gpio and not in err variable.

Link: https://lore.kernel.org/r/20200414102512.27506-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>

PCI: Avoid Pericom USB controller OHCI/EHCI PME# defect

Both Pericom OHCI and EHCI devices advertise PME# support from all power
states:

  06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI])
    Subsystem: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e]
    Capabilities: [80] Power Management version 3
      Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)

  06:00.2 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] (rev 01) (prog-if 20 [EHCI])
    Subsystem: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f]
    Capabilities: [80] Power Management version 3
      Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)

But testing shows that it's unreliable: there is a 20% chance PME# won't be
asserted when a USB device is plugged.

Remove PME support for both devices to make USB plugging work reliably.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205981
Link: https://lore.kernel.org/r/20200508065343.32751-2-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org