Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679Signed-off-by: NThomas Vincent-Cross <me@tvc.id.au>
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>

The Ampere Computing PCIe root port does not support ACS at this point.
However, the hardware provides isolation and source validation through the
SMMU. The stream ID generated by the PCIe ports contain both the
bus/device/function number as well as the port ID in its 3 most significant
bits. Turn on ACS but disable all the peer-to-peer features.

APM is being rebranded to Ampere.  The Vendor and Device IDs change, but
the functionality stays the same.
Signed-off-by: NFeng Kan <fkan@apm.com>
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>

Add PCI-specific dev_printk() wrappers and use them to simplify the code
slightly.  No functional change intended.
Signed-off-by: NFrederick Lawler <fred@fredlawl.com>
[bhelgaas: squash into one patch]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().

When we have a pci_dev, extract the domain number from it.

The config access syscalls don't allow the user to supply a domain number,
so they only work on devices in domain 0, so we can just hard-code that.
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
[bhelgaas: squash quirk & syscall patches together]
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>

The Marvell 9128 is the original device generating bug 42679, from which
many other Marvell DMA alias quirks have been sourced, but we didn't have
positive confirmation of the fix on 9128 until now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Link: https://www.spinics.net/lists/kvm/msg161459.htmlReported-by: NBinarus <lists@binarus.de>
Tested-by: NBinarus <lists@binarus.de>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

HiSilicon Hip06/Hip07 can operate as either a Root Port or an Endpoint.  It
always advertises an MSI capability, but it can only generate MSIs when in
Endpoint mode.

The device has the same Vendor and Device IDs in both modes, so check the
Class Code and disable MSI only when operating as a Root Port.

[bhelgaas: changelog]
Fixes: 72f2ff0d ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports")
Signed-off-by: NDongdong Liu <liudongdong3@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NZhou Wang <wangzhou1@hisilicon.com>
Cc: stable@vger.kernel.org	# v4.11+

PCI_COMMAND_INTX_DISABLE is writable on the Ceton InfiniTV4, indicating
that the device supports disabling the INTx# signal, but it apparently
doesn't work.

Mark the device so we know we can't use PCI_COMMAND_INTX_DISABLE to disable
its interrupts.

Link: https://lkml.kernel.org/r/92a65068-60b2-c1a8-9e17-ac41fe3c5c93@code.jackst.comReported-by: NJohn Strader <strader.john@code.jackst.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The file was converted from print_fn_descriptor_symbol() to %pF some time
ago (c9bbb4ab "PCI: use %pF instead of print_fn_descriptor_symbol()
in quirks.c").  kallsyms does not seem to be needed anymore.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Freescale PCIe controller advertises the MSI/MSI-X capability in both
RC and Endpoint mode, but in RC mode it doesn't support MSI/MSI-X by
itself; it can only transfer MSI/MSI-X from downstream devices.

Add a quirk to prevent use of MSI/MSI-X in RC mode.
Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NMinghuan Lian <minghuan.Lian@nxp.com>

Extend the Cavium ThunderX ACS quirk to cover more device IDs and restrict
it to only Root Ports.
Signed-off-by: NVadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
[bhelgaas: changelog, stable tag]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v4.12+

The Cavium ThunderX (CN8XXX) family of PCIe Root Ports does not advertise
an ACS capability.  However, the RTL internally implements similar
protection as if ACS had Request Redirection, Completion Redirection,
Source Validation, and Upstream Forwarding features enabled.

Change Cavium ACS capabilities quirk flags accordingly.

Fixes: b404bcfb ("PCI: Add ACS quirk for all Cavium devices")
Signed-off-by: NVadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
[bhelgaas: tidy changelog, comment, stable tag]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v4.6+: b77d537d: PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices

Root ports of cn8xxx do not function after bus reset when used with some
e1000e and LSI HBA devices.  Add a quirk to prevent bus reset on these root
ports.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
[jglauber@cavium.com: fixed typo and whitespaces]
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

... and __initconst if applicable.

Based on similar work for an older kernel in the Grsecurity patch.

[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

Fix various typos and whitespace errors:

  s/Synopsis/Synopsys/
  s/Designware/DesignWare/
  s/Keystine/Keystone/
  s/gpio/GPIO/
  s/pcie/PCIe/
  s/phy/PHY/
  s/confgiruation/configuration/

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

VMD currently only exists for Intel x86 products, so move the VMD quirk to
arch/x86.
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe
Root Port where Upstream Transaction Layer Packets with the Relaxed
Ordering Attribute clear are allowed to bypass earlier TLPs with
Relaxed Ordering set, it would cause Data Corruption, so we need
to disable Relaxed Ordering Attribute when Upstream TLPs to the
Root Port.
Reported-and-suggested-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Acked-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the Intel spec section 3.9.1 said:

    3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory
          and Toward MMIO Regions (P2P)

    In order to maximize performance for PCIe devices in the processors
    listed in Table 3-6 below, the soft- ware should determine whether the
    accesses are toward coherent memory (system memory) or toward MMIO
    regions (P2P access to other devices). If the access is toward MMIO
    region, then software can command HW to set the RO bit in the TLP
    header, as this would allow hardware to achieve maximum throughput for
    these types of accesses. For accesses toward coherent memory, software
    can command HW to clear the RO bit in the TLP header (no RO), as this
    would allow hardware to achieve maximum throughput for these types of
    accesses.

    Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing
               PCIe Performance

    Processor                            CPU RP Device IDs

    Intel Xeon processors based on       6F01H-6F0EH
    Broadwell microarchitecture

    Intel Xeon processors based on       2F01H-2F0EH
    Haswell microarchitecture

It means some Intel processors has performance issue when use the Relaxed
Ordering Attribute, so disable Relaxed Ordering for these root port.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Acked-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When bit4 is set in the PCIe Device Control register, it indicates
whether the device is permitted to use relaxed ordering.
On some platforms using relaxed ordering can have performance issues or
due to erratum can cause data-corruption. In such cases devices must avoid
using relaxed ordering.

The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
Relaxed Ordering (RO) attribute should not be used for Transaction Layer
Packets (TLP) targeted towards these affected root complexes.

This patch checks if there is any node in the hierarchy that indicates that
using relaxed ordering is not safe. In such cases the patch turns off the
relaxed ordering by clearing the capability for this device.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Acked-by: NAshok Raj <ashok.raj@intel.com>
Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Acked-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The APM X-Gene PCIe root port does not support ACS at this point.  However,
the hardware provides isolation and source validation through the SMMU.
The stream ID generated by the PCIe ports contain both the bus/device/
function number as well as the port ID in its 3 most significant bits.
Turn on ACS but disable all the peer-to-peer features.
Signed-off-by: NFeng Kan <fkan@apm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NTanmay Inamdar <tinamdar@apm.com>

We're about to amend ACPI bus scan with DMI checks whether we're running
on a Mac to support Apple device properties in AML.  The DMI checks are
performed for every single device, adding overhead for everything x86
that isn't Apple, which is the majority.  Rafael and Andy therefore
request to perform the DMI match only once and cache the result.

Outside of ACPI various other Apple DMI checks exist and it seems
reasonable to use the cached value there as well.  Rafael, Andy and
Darren suggest performing the DMI check in arch code and making it
available with a header in include/linux/platform_data/x86/.

To this end, add early_platform_quirks() to arch/x86/kernel/quirks.c
to perform the DMI check and invoke it from setup_arch().  Switch over
all existing Apple DMI checks, thereby fixing two deficiencies:

* They are now #defined to false on non-x86 arches and can thus be
  optimized away if they're located in cross-arch code.

* Some of them only match "Apple Inc." but not "Apple Computer, Inc.",
  which is used by BIOSes released between January 2006 (when the first
  x86 Macs started shipping) and January 2007 (when the company name
  changed upon introduction of the iPhone).
Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Suggested-by: NDarren Hart <dvhart@infradead.org>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ATS is broken on this hardware and causes IOMMU stalls and system failure.
Disable ATS on these devices to make them usable again with IOMMU enabled.

Note that the commit in the Fixes tag is not buggy; it just uncovers the
problem in the hardware by increasing the ATS flush rate.

Link: https://lists.linuxfoundation.org/pipermail/iommu/2017-March/020836.html
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1409201
Fixes: b1516a14 ("iommu/amd: Implement flush queue")
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>

Per PCIe r3.1, sec 2.2.6.2 and 7.8.4, a Requester may not use 8-bit Tags
unless its Extended Tag Field Enable is set, but all Receivers/Completers
must handle 8-bit Tags correctly regardless of their Extended Tag Field
Enable.

Some devices do not handle 8-bit Tags as Completers, so add a quirk for
them.  If we find such a device, we disable Extended Tags for the entire
hierarchy to make peer-to-peer DMA possible.

The Broadcom HT2100 seems to have issues with handling 8-bit tags.  Mark it
as broken.

The pci_walk_bus() in the quirk handles devices we've enumerated in the
past, and pci_configure_device() handles devices we enumerate in the
future.

Fixes: 60db3a4d ("PCI: Enable PCIe Extended Tags if supported")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1467674Reported-and-tested-by: NWim ten Have <wim.ten.have@oracle.com>
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
[bhelgaas: changelog, tweak messages, rename bit and quirk]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
delay when powering on a device, i.e., transitioning from state D3hot to
D0.

Apparently some devices require more time, and d1f9809e ("drm/radeon:
add quirk for d3 delay during switcheroo poweron for apple macbooks") added
an additional delay for the Radeon device in a MacBook Pro.  4807c5a8
("drm/radeon: add a PX quirk list") made the affected device more explicit.

Add a generic PCI quirk to increase the d3_delay.  This means we will use
the additional delay for *all* wakeups from D3, not just those initiated by
radeon_switcheroo_set_state().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAndreas Boll <andreas.boll.dev@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
CC: Maarten Lankhorst <maarten.lankhorst@canonical.com>

PCI_STD_RESOURCE_END is (confusingly) the index of the last valid BAR, not
the *number* of BARs.  To iterate through all possible BARs, we need to
include PCI_STD_RESOURCE_END.

Fixes: 9fe373f9 ("PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Just like the other XL710 and X710 variants, the XXV710 device IDs appear
to have the same hardware bug, the status register doesn't report pending
interrupts resulting in "irq xx: nobody cared..." errors from the spurious
interrupt handler when we try to use it with device assignment.
Reported-by: NStefan Assmann <sassmann@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>

The ASUS M2N-LR should not trigger boot interrupt quirks although it
carries an Intel 6702PXH.  On this board the boot interrupt quirks cause
incorrect IRQ assignments and should be disabled.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43074Tested-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Instead of copy & pasting and old version of the code.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The 82599 quirk contained an outdated copy of the FLR code.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

On Cavium ThunderX2 arm64 SoCs (formerly known as Broadcom Vulcan), the PCI
topology is slightly unusual.  For a multi-node system, it looks like:

    00:00.0 PCI bridge to [bus 01-1e]
    01:0a.0 PCI-to-PCIe bridge to [bus 02-04]
    02:00.0 PCIe Root Port bridge to [bus 03-04] (XLATE_ROOT)
    03:00.0 PCIe Endpoint

pci_for_each_dma_alias() assumes IOMMU translation is done at the root of
the PCI hierarchy.  It generates 03:00.0, 01:0a.0, and 00:00.0 as DMA
aliases for 03:00.0 because buses 01 and 00 are non-PCIe buses that don't
carry the Requester ID.

Because the ThunderX2 IOMMU is at 02:00.0, the Requester IDs 01:0a.0 and
00:00.0 are never valid for the endpoint.  This quirk stops alias
generation at the XLATE_ROOT bridge so we won't generate 01:0a.0 or
00:00.0.

The current IOMMU code only maps the last alias (this is a separate bug in
itself).  Prior to this quirk, we only created IOMMU mappings for the
invalid Requester ID 00:00:0, which never matched any DMA transactions.

With this quirk, we create IOMMU mappings for a valid Requester ID, which
fixes devices with no aliases but leaves devices with aliases still broken.

The last alias for the endpoint is also used by the ARM GICv3 MSI-X code.
Without this quirk, the GIC Interrupt Translation Tables are setup with the
invalid Requester ID, and the MSI-X generated by the device fails to be
translated and routed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195447Signed-off-by: NJayachandran C <jnair@caviumnetworks.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NDavid Daney <david.daney@cavium.com>

The ITE 8893 bridge has the same problems as the ITE 8892, which were
resulting in crippling an older PCI 1Gbps NIC down to 45Mbps throughput
with IOMMU and VT-d enabled.  With the patch, this old e1000 goes back up
to ~900Mbps.
Suggested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

Per Intel Specification Update 335553-002 (see link below), some 82579
network adapters advertise a Function Level Reset (FLR) capability, but
they can hang when an FLR is triggered.

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

Add a quirk to prevent the use of FLR on these devices.

[bhelgaas: changelog, comments]
Link: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/82579lm-82579v-gigabit-network-connection-spec-update.pdfSigned-off-by: NSasha Neftin <sasha.neftin@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Only apply the Cavium ACS quirk to devices with ID in the range
0xa000-0xa0ff.  These are the on-chip PCI devices for CN81xx/CN83xx/CN88xx.

Fixes: b404bcfb ("PCI: Add ACS quirk for all Cavium devices")
Reported-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NManish Jaggi <mjaggi@cavium.com>
Acked-by: NDavid Daney <david.daney@cavium.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>

QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
access issue too, while read the common pci-sysfs access interface shown as

 /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd

with simple 'cat' could cause system hang and panic:

  Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
  1. Integrated Management Log (IML)
  2. OA Syslog
  3. OA Forward Progress Log
  4. iLO Event Log
  CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
   0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
   ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
   0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
  Call Trace:
   <NMI>  [<ffffffff817193de>] dump_stack+0x63/0x81
   [<ffffffff81714072>] panic+0xd0/0x20e
   [<ffffffffa00b390d>] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
   [<ffffffff81021fc9>] ? sched_clock+0x9/0x10
   [<ffffffff8101c101>] nmi_handle+0x91/0x170
   [<ffffffff8101c10c>] ? nmi_handle+0x9c/0x170
   [<ffffffff8101c5fe>] io_check_error+0x1e/0xa0
   [<ffffffff8101c719>] default_do_nmi+0x99/0x140
   [<ffffffff8101c8b4>] do_nmi+0xf4/0x170
   [<ffffffff817232c5>] end_repeat_nmi+0x1a/0x1e
   [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
   [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
   [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
   <<EOE>>  [<ffffffff815db4b3>] raw_pci_read+0x23/0x40
   [<ffffffff815db4fc>] pci_read+0x2c/0x30
   [<ffffffff8136f612>] pci_user_read_config_word+0x72/0x110
   [<ffffffff8136f746>] pci_vpd_pci22_wait+0x96/0x130
   [<ffffffff8136ff9b>] pci_vpd_pci22_read+0xdb/0x1a0
   [<ffffffff8136ea30>] pci_read_vpd+0x20/0x30
   [<ffffffff8137d590>] read_vpd_attr+0x30/0x40
   [<ffffffff8128e037>] sysfs_kf_bin_read+0x47/0x70
   [<ffffffff8128d24e>] kernfs_fop_read+0xae/0x180
   [<ffffffff8120dd97>] __vfs_read+0x37/0x100
   [<ffffffff812ba7e4>] ? security_file_permission+0x84/0xa0
   [<ffffffff8120e366>] ? rw_verify_area+0x56/0xe0
   [<ffffffff8120e476>] vfs_read+0x86/0x140
   [<ffffffff8120f3f5>] SyS_read+0x55/0xd0
   [<ffffffff81720f2e>] system_call_fastpath+0x12/0x71
  Shutting down cpus with NMI
  Kernel Offset: disabled
  drm_kms_helper: panic occurred, switching back to text console

So blacklist the access to its VPD.
Signed-off-by: NEthan Zhao <ethan.zhao@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v4.6+

Fix typos and add the following to the scripts/spelling.txt:

  followings||following

While we are here, add a missing colon in the boilerplate in DT binding
documents.  The "you SoC" in allwinner,sunxi-pinctrl.txt was fixed as
well.

I reworded "as the followings:" to "as follows:" for
drivers/usb/gadget/udc/renesas_usb3.c.

Link: http://lkml.kernel.org/r/1481573103-11329-32-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The Qualcomm QDF2xxx root ports don't advertise an ACS capability, but they
do provide ACS-like features to disable peer transactions and validate bus
numbers in requests.

To be specific:
* Hardware supports source validation but it will report the issue as
Completer Abort instead of ACS Violation.

* Hardware doesn't support peer-to-peer and each root port is a root
complex with unique segment numbers.

* It is not possible for one root port to pass traffic to the other root
port.  All PCIe transactions are terminated inside the root port.

Add an ACS quirk for the QDF2400 and QDF2432 products.

[bhelgaas: changelog]
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

Sort the list of Intel devices that have no PCI D3 delay by ID.  Add a
comment for group of devices that had not been marked yet.

There is no functional change.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCIe Root Port in Hip06/Hip07 SoCs advertises an MSI capability, but it
cannot generate MSIs.  It can transfer MSI/MSI-X from downstream devices,
but does not support MSI/MSI-X itself.

Add a quirk to prevent use of MSI/MSI-X by the Root Port.

[bhelgaas: changelog, sort vendor ID #define, drop device ID #define]
Signed-off-by: NDongdong Liu <liudongdong3@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Reviewed-by: NZhou Wang <wangzhou1@hisilicon.com>

The Broadcom Northstar2 SoC has a number of quirks for the PAXC
(internal/fake) PCI bus.  Specifically, the PCI config space is shared
between the root port and the first PF (ie., PF0), and a number of fields
are tied to zero (thus preventing them from being set).  These cannot be
"fixed" in device firmware, so we must fix them with a quirk.
Signed-off-by: NJon Mason <jon.mason@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Intel 200-series chipsets have the same errata as 100-series: the ACS
capability doesn't follow the PCIe spec, the capability and control
registers are dwords rather than words.  Add PCIe root port device IDs to
existing quirk.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>