There is no need to call the dev_err() function directly to print a
custom message when handling an error from either the platform_get_irq() or
platform_get_irq_byname() functions as both are going to display an
appropriate error message in case of a failure.

This change is as per suggestions from Coccinelle, e.g.,

  drivers/pci/controller/dwc/pcie-armada8k.c:252:2-9: line 252 is
  redundant because platform_get_irq() already prints an error

[bhelgaas: squashed into one commit]
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20200802142601.1635926-2-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-3-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-4-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-5-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-6-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-7-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-8-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-9-kw@linux.com
Link: https://lore.kernel.org/r/20200802142601.1635926-10-kw@linux.com
Link: https://lore.kernel.org/r/20200803071040.1663662-1-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> # altera
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> # dwc

Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.

This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.

There are a variety of indentation styles found.

  a) 4 spaces + '---help---'
  b) 7 spaces + '---help---'
  c) 8 spaces + '---help---'
  d) 1 space + 1 tab + '---help---'
  e) 1 tab + '---help---'    (correct indentation)
  f) 1 tab + 1 space + '---help---'
  g) 1 tab + 2 spaces + '---help---'

In order to convert all of them to 1 tab + 'help', I ran the
following commend:

  $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

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.comSigned-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>

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.comTested-by: NDarrel Goeddel <dgoeddel@forcepoint.com>
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex 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>

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.comSigned-off-by: NYicong Yang <yangyicong@hisilicon.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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-5520Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

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.comSigned-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.comSigned-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit c100beb9 ("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.comSigned-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.cnSigned-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NThierry Reding <treding@nvidia.com>

Versions of VMD with the Host Physical Address shadow register use this
register to calculate the bus address offset needed to do guest
passthrough of the domain. This register shadows the Host Physical
Address registers including the resource type bits. After calculating
the offset, the extra resource type bits lead to the VMD resources being
over-provisioned at the front and under-provisioned at the back.

Example:
pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]

Expected:
pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]

If other devices are mapped in the over-provisioned front, it could lead
to resource conflict issues with VMD or those devices.

Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com
Fixes: a1a30170 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Information printed under verbose_request is clearly used for debugging
only. Remove it and use dev_dbg() instead.
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/1590719092-8578-1-git-send-email-boris.ostrovsky@oracle.comReviewed-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>

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.cnSigned-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NVidya Sagar <vidyas@nvidia.com>

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@embeddedorSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NWei Liu <wei.liu@kernel.org>

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.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.lanSigned-off-by: NKevin Buettner <kevinb@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.comSigned-off-by: NMarcos Scriven <marcos@scriven.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add pci_ats_supported(), which checks whether a device has an ATS
capability, and whether it is trusted.  A device is untrusted if it is
plugged into an external-facing port such as Thunderbolt and could be
spoofing an existing device to exploit weaknesses in the IOMMU
configuration.  PCIe ATS is one such weaknesses since it allows
endpoints to cache IOMMU translations and emit transactions with
'Translated' Address Type (10b) that partially bypass the IOMMU
translation.

The SMMUv3 and VT-d IOMMU drivers already disallow ATS and transactions
with 'Translated' Address Type for untrusted devices.  Add the check to
pci_enable_ats() to let other drivers (AMD IOMMU for now) benefit from
it.

By checking ats_cap, the pci_ats_supported() helper also returns whether
ATS was globally disabled with pci=noats, and could later include more
things, for example whether the whole PCIe hierarchy down to the
endpoint supports ATS.
Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: NJoerg Roedel <jroedel@suse.de>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20200520152201.3309416-2-jean-philippe@linaro.orgSigned-off-by: NJoerg Roedel <jroedel@suse.de>

This controller can be found on Loongson-2K SoC, Loongson-3
systems with RS780E/LS7A PCH.

The RS780E part of code was previously located at
arch/mips/pci/ops-loongson3.c and now it can use generic PCI
driver implementation.
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>

Don't disable MEM/IO decoding when a device have both non_compliant_bars
and mmio_always_on.

That would allow us quirk devices with junk in BARs but can't disable
their decoding.
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Acked-by: NBjorn Helgaas <helgaas@kernel.org>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>

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.comSigned-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NGustavo Pimentel <gustavo.pimentel@synopsys.com>

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: 9c0ef6d3 ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Signed-off-by: NMarc Zyngier <maz@kernel.org>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NRob Herring <robh@kernel.org>

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.orgSigned-off-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NJingoo Han <jingoohan1@gmail.com>

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.comSigned-off-by: NWei Yongjun <weiyongjun1@huawei.com>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

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.comReported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

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.comSigned-off-by: NAlan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NGustavo Pimentel <gustavo.pimentel@synopsys.com>

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.comSigned-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRob Herring <robh@kernel.org>

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.comSigned-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRob Herring <robh@kernel.org>

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.comSigned-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRob Herring <robh@kernel.org>

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.comSigned-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRob Herring <robh@kernel.org>

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.comSigned-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

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.comSigned-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>

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.comSigned-off-by: NKrzysztof Wilczynski <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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: eec097d4 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints")
Reported-by: NAditya Paluri <Venkata.AdityaPaluri@synopsys.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.comSigned-off-by: NKrzysztof Wilczynski <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.comSigned-off-by: NKrzysztof Wilczynski <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>

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.comSigned-off-by: NJay Fang <f.fangjian@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

On s390 PCI Virtual Functions (VFs) are scanned by firmware and are made
available to Linux via the hot-plug interface. As such the common code
path of doing the scan directly using the parent Physical Function (PF)
is not used and fenced off with the no_vf_scan attribute.

Even if the partition created the VFs itself e.g. using the sriov_numvfs
attribute of a PF, the PF/VF links thus need to be established after the
fact. To do this when a VF is plugged we scan through all functions on
the same zbus and test whether they are the parent PF in which case we
establish the necessary links.

With these links established there is now no more need to fence off
pci_iov_remove_virtfn() for pdev->no_vf_scan as the common code now
works fine.
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Link: https://lore.kernel.org/r/20200506154139.90609-3-schnelle@linux.ibm.comSigned-off-by: NVasily Gorbik <gor@linux.ibm.com>

Currently pci_iov_add_virtfn() scans the SR-IOV BARs, adds the VF to the
bus and also creates the sysfs links between the newly added VF and its
parent PF.

With pdev->no_vf_scan fencing off the entire pci_iov_add_virtfn() call
s390 as the sole pdev->no_vf_scan user thus ends up missing these sysfs
links which are required for example by QEMU/libvirt.

Instead of duplicating the code refactor pci_iov_add_virtfn() to make
sysfs link creation callable separately.
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Link: https://lore.kernel.org/r/20200506154139.90609-1-schnelle@linux.ibm.comSigned-off-by: NVasily Gorbik <gor@linux.ibm.com>

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.comSigned-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NTom Joseph <tjoseph@cadence.com>