Merge tag 'pci-v4.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

Pull PCI updates from Bjorn Helgaas:

 - add framework for supporting PCIe devices in Endpoint mode (Kishon
   Vijay Abraham I)

 - use non-postable PCI config space mappings when possible (Lorenzo
   Pieralisi)

 - clean up and unify mmap of PCI BARs (David Woodhouse)

 - export and unify Function Level Reset support (Christoph Hellwig)

 - avoid FLR for Intel 82579 NICs (Sasha Neftin)

 - add pci_request_irq() and pci_free_irq() helpers (Christoph Hellwig)

 - short-circuit config access failures for disconnected devices (Keith
   Busch)

 - remove D3 sleep delay when possible (Adrian Hunter)

 - freeze PME scan before suspending devices (Lukas Wunner)

 - stop disabling MSI/MSI-X in pci_device_shutdown() (Prarit Bhargava)

 - disable boot interrupt quirk for ASUS M2N-LR (Stefan Assmann)

 - add arch-specific alignment control to improve device passthrough by
   avoiding multiple BARs in a page (Yongji Xie)

 - add sysfs sriov_drivers_autoprobe to control VF driver binding
   (Bodong Wang)

 - allow slots below PCI-to-PCIe "reverse bridges" (Bjorn Helgaas)

 - fix crashes when unbinding host controllers that don't support
   removal (Brian Norris)

 - add driver for MicroSemi Switchtec management interface (Logan
   Gunthorpe)

 - add driver for Faraday Technology FTPCI100 host bridge (Linus
   Walleij)

 - add i.MX7D support (Andrey Smirnov)

 - use generic MSI support for Aardvark (Thomas Petazzoni)

 - make Rockchip driver modular (Brian Norris)

 - advertise 128-byte Read Completion Boundary support for Rockchip
   (Shawn Lin)

 - advertise PCI_EXP_LNKSTA_SLC for Rockchip root port (Shawn Lin)

 - convert atomic_t to refcount_t in HV driver (Elena Reshetova)

 - add CPU IRQ affinity in HV driver (K. Y. Srinivasan)

 - fix PCI bus removal in HV driver (Long Li)

 - add support for ThunderX2 DMA alias topology (Jayachandran C)

 - add ThunderX pass2.x 2nd node MCFG quirk (Tomasz Nowicki)

 - add ITE 8893 bridge DMA alias quirk (Jarod Wilson)

 - restrict Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices
   (Manish Jaggi)

* tag 'pci-v4.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (146 commits)
  PCI: Don't allow unbinding host controllers that aren't prepared
  ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
  MAINTAINERS: Add PCI Endpoint maintainer
  Documentation: PCI: Add userguide for PCI endpoint test function
  tools: PCI: Add sample test script to invoke pcitest
  tools: PCI: Add a userspace tool to test PCI endpoint
  Documentation: misc-devices: Add Documentation for pci-endpoint-test driver
  misc: Add host side PCI driver for PCI test function device
  PCI: Add device IDs for DRA74x and DRA72x
  dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access
  PCI: dwc: dra7xx: Workaround for errata id i870
  dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode
  PCI: dwc: dra7xx: Add EP mode support
  PCI: dwc: dra7xx: Facilitate wrapper and MSI interrupts to be enabled independently
  dt-bindings: PCI: Add DT bindings for PCI designware EP mode
  PCI: dwc: designware: Add EP mode support
  Documentation: PCI: Add binding documentation for pci-test endpoint function
  ixgbe: Use pcie_flr() instead of duplicating it
  IB/hfi1: Use pcie_flr() instead of duplicating it
  PCI: imx6: Fix spelling mistake: "contol" -> "control"
  ...

18 files changed, 1049 insertions, 21 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index e4e90104d7c3..44d4b2be92fd 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -301,3 +301,25 @@ Contact:	Emil Velikov <emil.l.velikov@gmail.com>
 Description:
                 This file contains the revision field of the PCI device.
                 The value comes from device config space. The file is read only.
+
+What:           /sys/bus/pci/devices/.../sriov_drivers_autoprobe
+Date:           April 2017
+Contact:        Bodong Wang<bodong@mellanox.com>
+Description:
+                This file is associated with the PF of a device that
+                supports SR-IOV.  It determines whether newly-enabled VFs
+                are immediately bound to a driver.  It initially contains
+                1, which means the kernel automatically binds VFs to a
+                compatible driver immediately after they are enabled.  If
+                an application writes 0 to the file before enabling VFs,
+                the kernel will not bind VFs to a driver.
+
+                A typical use case is to write 0 to this file, then enable
+                VFs, then assign the newly-created VFs to virtual machines.
+                Note that changing this file does not affect already-
+                enabled VFs.  In this scenario, the user must first disable
+                the VFs, write 0 to sriov_drivers_autoprobe, then re-enable
+                the VFs.
+
+                This is similar to /sys/bus/pci/drivers_autoprobe, but
+                affects only the VFs associated with a specific PF.
diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec
new file mode 100644
index 000000000000..48cb4c15e430
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-switchtec
@@ -0,0 +1,96 @@
+switchtec - Microsemi Switchtec PCI Switch Management Endpoint
+
+For details on this subsystem look at Documentation/switchtec.txt.
+
+What:           /sys/class/switchtec
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    The switchtec class subsystem folder.
+                Each registered switchtec driver is represented by a switchtecX
+                subfolder (X being an integer >= 0).
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/component_id
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Component identifier as stored in the hardware (eg. PM8543)
+                (read only)
+Values:         arbitrary string.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/component_revision
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Component revision stored in the hardware (read only)
+Values:         integer.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/component_vendor
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Component vendor as stored in the hardware (eg. MICROSEM)
+                (read only)
+Values:         arbitrary string.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/device_version
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Device version as stored in the hardware (read only)
+Values:         integer.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/fw_version
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Currently running firmware version (read only)
+Values:         integer (in hexadecimal).
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/partition
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Partition number for this device in the switch (read only)
+Values:         integer.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/partition_count
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Total number of partitions in the switch (read only)
+Values:         integer.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/product_id
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Product identifier as stored in the hardware (eg. PSX 48XG3)
+                (read only)
+Values:         arbitrary string.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/product_revision
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Product revision stored in the hardware (eg. RevB)
+                (read only)
+Values:         arbitrary string.
+
+
+What:           /sys/class/switchtec/switchtec[0-9]+/product_vendor
+Date:           05-Jan-2017
+KernelVersion:  v4.11
+Contact:        Logan Gunthorpe <logang@deltatee.com>
+Description:    Product vendor as stored in the hardware (eg. MICROSEM)
+                (read only)
+Values:         arbitrary string.
diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f1613e..00c9a90b6f38 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -12,3 +12,13 @@ pci.txt
         - info on the PCI subsystem for device driver authors
 pcieaer-howto.txt
         - the PCI Express Advanced Error Reporting Driver Guide HOWTO
+endpoint/pci-endpoint.txt
+        - guide to add endpoint controller driver and endpoint function driver.
+endpoint/pci-endpoint-cfs.txt
+        - guide to use configfs to configure the PCI endpoint function.
+endpoint/pci-test-function.txt
+        - specification of *PCI test* function device.
+endpoint/pci-test-howto.txt
+        - userguide for PCI endpoint test function.
+endpoint/function/binding/
+        - binding documentation for PCI endpoint function
diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt b/Documentation/PCI/endpoint/function/binding/pci-test.txt
new file mode 100644
index 000000000000..3b68b955fb50
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
@@ -0,0 +1,17 @@
+PCI TEST ENDPOINT FUNCTION
+
+name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
+
+Configurable Fields:
+vendorid         : should be 0x104c
+deviceid         : should be 0xb500 for DRA74x and 0xb501 for DRA72x
+revid            : don't care
+progif_code      : don't care
+subclass_code    : don't care
+baseclass_code   : should be 0xff
+cache_line_size  : don't care
+subsys_vendor_id : don't care
+subsys_id        : don't care
+interrupt_pin    : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
+msi_interrupts   : Should be 1 to 32 depending on the number of MSI interrupts
+                   to test
diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
new file mode 100644
index 000000000000..d740f29960a4
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
@@ -0,0 +1,105 @@
+                   CONFIGURING PCI ENDPOINT USING CONFIGFS
+                    Kishon Vijay Abraham I <kishon@ti.com>
+
+The PCI Endpoint Core exposes configfs entry (pci_ep) to configure the
+PCI endpoint function and to bind the endpoint function
+with the endpoint controller. (For introducing other mechanisms to
+configure the PCI Endpoint Function refer to [1]).
+
+*) Mounting configfs
+
+The PCI Endpoint Core layer creates pci_ep directory in the mounted configfs
+directory. configfs can be mounted using the following command.
+
+        mount -t configfs none /sys/kernel/config
+
+*) Directory Structure
+
+The pci_ep configfs has two directories at its root: controllers and
+functions. Every EPC device present in the system will have an entry in
+the *controllers* directory and and every EPF driver present in the system
+will have an entry in the *functions* directory.
+
+/sys/kernel/config/pci_ep/
+        .. controllers/
+        .. functions/
+
+*) Creating EPF Device
+
+Every registered EPF driver will be listed in controllers directory. The
+entries corresponding to EPF driver will be created by the EPF core.
+
+/sys/kernel/config/pci_ep/functions/
+        .. <EPF Driver1>/
+                ... <EPF Device 11>/
+                ... <EPF Device 21>/
+        .. <EPF Driver2>/
+                ... <EPF Device 12>/
+                ... <EPF Device 22>/
+
+In order to create a <EPF device> of the type probed by <EPF Driver>, the
+user has to create a directory inside <EPF DriverN>.
+
+Every <EPF device> directory consists of the following entries that can be
+used to configure the standard configuration header of the endpoint function.
+(These entries are created by the framework when any new <EPF Device> is
+created)
+
+        .. <EPF Driver1>/
+                ... <EPF Device 11>/
+                        ... vendorid
+                        ... deviceid
+                        ... revid
+                        ... progif_code
+                        ... subclass_code
+                        ... baseclass_code
+                        ... cache_line_size
+                        ... subsys_vendor_id
+                        ... subsys_id
+                        ... interrupt_pin
+
+*) EPC Device
+
+Every registered EPC device will be listed in controllers directory. The
+entries corresponding to EPC device will be created by the EPC core.
+
+/sys/kernel/config/pci_ep/controllers/
+        .. <EPC Device1>/
+                ... <Symlink EPF Device11>/
+                ... <Symlink EPF Device12>/
+                ... start
+        .. <EPC Device2>/
+                ... <Symlink EPF Device21>/
+                ... <Symlink EPF Device22>/
+                ... start
+
+The <EPC Device> directory will have a list of symbolic links to
+<EPF Device>. These symbolic links should be created by the user to
+represent the functions present in the endpoint device.
+
+The <EPC Device> directory will also have a *start* field. Once
+"1" is written to this field, the endpoint device will be ready to
+establish the link with the host. This is usually done after
+all the EPF devices are created and linked with the EPC device.
+
+
+                         | controllers/
+                                | <Directory: EPC name>/
+                                        | <Symbolic Link: Function>
+                                        | start
+                         | functions/
+                                | <Directory: EPF driver>/
+                                        | <Directory: EPF device>/
+                                                | vendorid
+                                                | deviceid
+                                                | revid
+                                                | progif_code
+                                                | subclass_code
+                                                | baseclass_code
+                                                | cache_line_size
+                                                | subsys_vendor_id
+                                                | subsys_id
+                                                | interrupt_pin
+                                                | function
+
+[1] -> Documentation/PCI/endpoint/pci-endpoint.txt
diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt b/Documentation/PCI/endpoint/pci-endpoint.txt
new file mode 100644
index 000000000000..9b1d66829290
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -0,0 +1,215 @@
+                            PCI ENDPOINT FRAMEWORK
+                    Kishon Vijay Abraham I <kishon@ti.com>
+
+This document is a guide to use the PCI Endpoint Framework in order to create
+endpoint controller driver, endpoint function driver, and using configfs
+interface to bind the function driver to the controller driver.
+
+1. Introduction
+
+Linux has a comprehensive PCI subsystem to support PCI controllers that
+operates in Root Complex mode. The subsystem has capability to scan PCI bus,
+assign memory resources and IRQ resources, load PCI driver (based on
+vendor ID, device ID), support other services like hot-plug, power management,
+advanced error reporting and virtual channels.
+
+However the PCI controller IP integrated in some SoCs is capable of operating
+either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
+add endpoint mode support in Linux. This will help to run Linux in an
+EP system which can have a wide variety of use cases from testing or
+validation, co-processor accelerator, etc.
+
+2. PCI Endpoint Core
+
+The PCI Endpoint Core layer comprises 3 components: the Endpoint Controller
+library, the Endpoint Function library, and the configfs layer to bind the
+endpoint function with the endpoint controller.
+
+2.1 PCI Endpoint Controller(EPC) Library
+
+The EPC library provides APIs to be used by the controller that can operate
+in endpoint mode. It also provides APIs to be used by function driver/library
+in order to implement a particular endpoint function.
+
+2.1.1 APIs for the PCI controller Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI controller driver.
+
+*) devm_pci_epc_create()/pci_epc_create()
+
+   The PCI controller driver should implement the following ops:
+         * write_header: ops to populate configuration space header
+         * set_bar: ops to configure the BAR
+         * clear_bar: ops to reset the BAR
+         * alloc_addr_space: ops to allocate in PCI controller address space
+         * free_addr_space: ops to free the allocated address space
+         * raise_irq: ops to raise a legacy or MSI interrupt
+         * start: ops to start the PCI link
+         * stop: ops to stop the PCI link
+
+   The PCI controller driver can then create a new EPC device by invoking
+   devm_pci_epc_create()/pci_epc_create().
+
+*) devm_pci_epc_destroy()/pci_epc_destroy()
+
+   The PCI controller driver can destroy the EPC device created by either
+   devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or
+   pci_epc_destroy().
+
+*) pci_epc_linkup()
+
+   In order to notify all the function devices that the EPC device to which
+   they are linked has established a link with the host, the PCI controller
+   driver should invoke pci_epc_linkup().
+
+*) pci_epc_mem_init()
+
+   Initialize the pci_epc_mem structure used for allocating EPC addr space.
+
+*) pci_epc_mem_exit()
+
+   Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
+
+2.1.2 APIs for the PCI Endpoint Function Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function driver.
+
+*) pci_epc_write_header()
+
+   The PCI endpoint function driver should use pci_epc_write_header() to
+   write the standard configuration header to the endpoint controller.
+
+*) pci_epc_set_bar()
+
+   The PCI endpoint function driver should use pci_epc_set_bar() to configure
+   the Base Address Register in order for the host to assign PCI addr space.
+   Register space of the function driver is usually configured
+   using this API.
+
+*) pci_epc_clear_bar()
+
+   The PCI endpoint function driver should use pci_epc_clear_bar() to reset
+   the BAR.
+
+*) pci_epc_raise_irq()
+
+   The PCI endpoint function driver should use pci_epc_raise_irq() to raise
+   Legacy Interrupt or MSI Interrupt.
+
+*) pci_epc_mem_alloc_addr()
+
+   The PCI endpoint function driver should use pci_epc_mem_alloc_addr(), to
+   allocate memory address from EPC addr space which is required to access
+   RC's buffer
+
+*) pci_epc_mem_free_addr()
+
+   The PCI endpoint function driver should use pci_epc_mem_free_addr() to
+   free the memory space allocated using pci_epc_mem_alloc_addr().
+
+2.1.3 Other APIs
+
+There are other APIs provided by the EPC library. These are used for binding
+the EPF device with EPC device. pci-ep-cfs.c can be used as reference for
+using these APIs.
+
+*) pci_epc_get()
+
+   Get a reference to the PCI endpoint controller based on the device name of
+   the controller.
+
+*) pci_epc_put()
+
+   Release the reference to the PCI endpoint controller obtained using
+   pci_epc_get()
+
+*) pci_epc_add_epf()
+
+   Add a PCI endpoint function to a PCI endpoint controller. A PCIe device
+   can have up to 8 functions according to the specification.
+
+*) pci_epc_remove_epf()
+
+   Remove the PCI endpoint function from PCI endpoint controller.
+
+*) pci_epc_start()
+
+   The PCI endpoint function driver should invoke pci_epc_start() once it
+   has configured the endpoint function and wants to start the PCI link.
+
+*) pci_epc_stop()
+
+   The PCI endpoint function driver should invoke pci_epc_stop() to stop
+   the PCI LINK.
+
+2.2 PCI Endpoint Function(EPF) Library
+
+The EPF library provides APIs to be used by the function driver and the EPC
+library to provide endpoint mode functionality.
+
+2.2.1 APIs for the PCI Endpoint Function Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function driver.
+
+*) pci_epf_register_driver()
+
+   The PCI Endpoint Function driver should implement the following ops:
+         * bind: ops to perform when a EPC device has been bound to EPF device
+         * unbind: ops to perform when a binding has been lost between a EPC
+           device and EPF device
+         * linkup: ops to perform when the EPC device has established a
+           connection with a host system
+
+  The PCI Function driver can then register the PCI EPF driver by using
+  pci_epf_register_driver().
+
+*) pci_epf_unregister_driver()
+
+  The PCI Function driver can unregister the PCI EPF driver by using
+  pci_epf_unregister_driver().
+
+*) pci_epf_alloc_space()
+
+  The PCI Function driver can allocate space for a particular BAR using
+  pci_epf_alloc_space().
+
+*) pci_epf_free_space()
+
+  The PCI Function driver can free the allocated space
+  (using pci_epf_alloc_space) by invoking pci_epf_free_space().
+
+2.2.2 APIs for the PCI Endpoint Controller Library
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint controller library.
+
+*) pci_epf_linkup()
+
+   The PCI endpoint controller library invokes pci_epf_linkup() when the
+   EPC device has established the connection to the host.
+
+2.2.2 Other APIs
+There are other APIs provided by the EPF library. These are used to notify
+the function driver when the EPF device is bound to the EPC device.
+pci-ep-cfs.c can be used as reference for using these APIs.
+
+*) pci_epf_create()
+
+   Create a new PCI EPF device by passing the name of the PCI EPF device.
+   This name will be used to bind the the EPF device to a EPF driver.
+
+*) pci_epf_destroy()
+
+   Destroy the created PCI EPF device.
+
+*) pci_epf_bind()
+
+   pci_epf_bind() should be invoked when the EPF device has been bound to
+   a EPC device.
+
+*) pci_epf_unbind()
+
+   pci_epf_unbind() should be invoked when the binding between EPC device
+   and EPF device is lost.
diff --git a/Documentation/PCI/endpoint/pci-test-function.txt b/Documentation/PCI/endpoint/pci-test-function.txt
new file mode 100644
index 000000000000..0c519c9bf94a
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -0,0 +1,66 @@
+                                PCI TEST
+                    Kishon Vijay Abraham I <kishon@ti.com>
+
+Traditionally PCI RC has always been validated by using standard
+PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
+However with the addition of EP-core in linux kernel, it is possible
+to configure a PCI controller that can operate in EP mode to work as
+a test device.
+
+The PCI endpoint test device is a virtual device (defined in software)
+used to test the endpoint functionality and serve as a sample driver
+for other PCI endpoint devices (to use the EP framework).
+
+The PCI endpoint test device has the following registers:
+
+        1) PCI_ENDPOINT_TEST_MAGIC
+        2) PCI_ENDPOINT_TEST_COMMAND
+        3) PCI_ENDPOINT_TEST_STATUS
+        4) PCI_ENDPOINT_TEST_SRC_ADDR
+        5) PCI_ENDPOINT_TEST_DST_ADDR
+        6) PCI_ENDPOINT_TEST_SIZE
+        7) PCI_ENDPOINT_TEST_CHECKSUM
+
+*) PCI_ENDPOINT_TEST_MAGIC
+
+This register will be used to test BAR0. A known pattern will be written
+and read back from MAGIC register to verify BAR0.
+
+*) PCI_ENDPOINT_TEST_COMMAND:
+
+This register will be used by the host driver to indicate the function
+that the endpoint device must perform.
+
+Bitfield Description:
+  Bit 0         : raise legacy IRQ
+  Bit 1         : raise MSI IRQ
+  Bit 2 - 7     : MSI interrupt number
+  Bit 8         : read command (read data from RC buffer)
+  Bit 9         : write command (write data to RC buffer)
+  Bit 10        : copy command (copy data from one RC buffer to another
+                  RC buffer)
+
+*) PCI_ENDPOINT_TEST_STATUS
+
+This register reflects the status of the PCI endpoint device.
+
+Bitfield Description:
+  Bit 0         : read success
+  Bit 1         : read fail
+  Bit 2         : write success
+  Bit 3         : write fail
+  Bit 4         : copy success
+  Bit 5         : copy fail
+  Bit 6         : IRQ raised
+  Bit 7         : source address is invalid
+  Bit 8         : destination address is invalid
+
+*) PCI_ENDPOINT_TEST_SRC_ADDR
+
+This register contains the source address (RC buffer address) for the
+COPY/READ command.
+
+*) PCI_ENDPOINT_TEST_DST_ADDR
+
+This register contains the destination address (RC buffer address) for
+the COPY/WRITE command.
diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt b/Documentation/PCI/endpoint/pci-test-howto.txt
new file mode 100644
index 000000000000..75f48c3bb191
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-howto.txt
@@ -0,0 +1,179 @@
+                            PCI TEST USERGUIDE
+                    Kishon Vijay Abraham I <kishon@ti.com>
+
+This document is a guide to help users use pci-epf-test function driver
+and pci_endpoint_test host driver for testing PCI. The list of steps to
+be followed in the host side and EP side is given below.
+
+1. Endpoint Device
+
+1.1 Endpoint Controller Devices
+
+To find the list of endpoint controller devices in the system:
+
+        # ls /sys/class/pci_epc/
+          51000000.pcie_ep
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+        # ls /sys/kernel/config/pci_ep/controllers
+          51000000.pcie_ep
+
+1.2 Endpoint Function Drivers
+
+To find the list of endpoint function drivers in the system:
+
+        # ls /sys/bus/pci-epf/drivers
+          pci_epf_test
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+        # ls /sys/kernel/config/pci_ep/functions
+          pci_epf_test
+
+1.3 Creating pci-epf-test Device
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-test device, the following commands can be used
+
+        # mount -t configfs none /sys/kernel/config
+        # cd /sys/kernel/config/pci_ep/
+        # mkdir functions/pci_epf_test/func1
+
+The "mkdir func1" above creates the pci-epf-test function device that will
+be probed by pci_epf_test driver.
+
+The PCI endpoint framework populates the directory with the following
+configurable fields.
+
+        # ls functions/pci_epf_test/func1
+          baseclass_code        interrupt_pin   revid           subsys_vendor_id
+          cache_line_size       msi_interrupts  subclass_code   vendorid
+          deviceid              progif_code     subsys_id
+
+The PCI endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-test driver populates
+vendorid with 0xffff and interrupt_pin with 0x0001
+
+        # cat functions/pci_epf_test/func1/vendorid
+          0xffff
+        # cat functions/pci_epf_test/func1/interrupt_pin
+          0x0001
+
+1.4 Configuring pci-epf-test Device
+
+The user can configure the pci-epf-test device using configfs entry. In order
+to change the vendorid and the number of MSI interrupts used by the function
+device, the following commands can be used.
+
+        # echo 0x104c > functions/pci_epf_test/func1/vendorid
+        # echo 0xb500 > functions/pci_epf_test/func1/deviceid
+        # echo 16 > functions/pci_epf_test/func1/msi_interrupts
+
+1.5 Binding pci-epf-test Device to EP Controller
+
+In order for the endpoint function device to be useful, it has to be bound to
+a PCI endpoint controller driver. Use the configfs to bind the function
+device to one of the controller driver present in the system.
+
+        # ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/
+
+Once the above step is completed, the PCI endpoint is ready to establish a link
+with the host.
+
+1.6 Start the Link
+
+In order for the endpoint device to establish a link with the host, the _start_
+field should be populated with '1'.
+
+        # echo 1 > controllers/51000000.pcie_ep/start
+
+2. RootComplex Device
+
+2.1 lspci Output
+
+Note that the devices listed here correspond to the value populated in 1.4 above
+
+        00:00.0 PCI bridge: Texas Instruments Device 8888 (rev 01)
+        01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
+
+2.2 Using Endpoint Test function Device
+
+pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
+tests. Before pcitest.sh can be used pcitest.c should be compiled using the
+following commands.
+
+        cd <kernel-dir>
+        make headers_install ARCH=arm
+        arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
+        cp pcitest  <rootfs>/usr/sbin/
+        cp tools/pci/pcitest.sh <rootfs>
+
+2.2.1 pcitest.sh Output
+        # ./pcitest.sh
+        BAR tests
+
+        BAR0:           OKAY
+        BAR1:           OKAY
+        BAR2:           OKAY
+        BAR3:           OKAY
+        BAR4:           NOT OKAY
+        BAR5:           NOT OKAY
+
+        Interrupt tests
+
+        LEGACY IRQ:     NOT OKAY
+        MSI1:           OKAY
+        MSI2:           OKAY
+        MSI3:           OKAY
+        MSI4:           OKAY
+        MSI5:           OKAY
+        MSI6:           OKAY
+        MSI7:           OKAY
+        MSI8:           OKAY
+        MSI9:           OKAY
+        MSI10:          OKAY
+        MSI11:          OKAY
+        MSI12:          OKAY
+        MSI13:          OKAY
+        MSI14:          OKAY
+        MSI15:          OKAY
+        MSI16:          OKAY
+        MSI17:          NOT OKAY
+        MSI18:          NOT OKAY
+        MSI19:          NOT OKAY
+        MSI20:          NOT OKAY
+        MSI21:          NOT OKAY
+        MSI22:          NOT OKAY
+        MSI23:          NOT OKAY
+        MSI24:          NOT OKAY
+        MSI25:          NOT OKAY
+        MSI26:          NOT OKAY
+        MSI27:          NOT OKAY
+        MSI28:          NOT OKAY
+        MSI29:          NOT OKAY
+        MSI30:          NOT OKAY
+        MSI31:          NOT OKAY
+        MSI32:          NOT OKAY
+
+        Read Tests
+
+        READ (      1 bytes):           OKAY
+        READ (   1024 bytes):           OKAY
+        READ (   1025 bytes):           OKAY
+        READ (1024000 bytes):           OKAY
+        READ (1024001 bytes):           OKAY
+
+        Write Tests
+
+        WRITE (      1 bytes):          OKAY
+        WRITE (   1024 bytes):          OKAY
+        WRITE (   1025 bytes):          OKAY
+        WRITE (1024000 bytes):          OKAY
+        WRITE (1024001 bytes):          OKAY
+
+        Copy Tests
+
+        COPY (      1 bytes):           OKAY
+        COPY (   1024 bytes):           OKAY
+        COPY (   1025 bytes):           OKAY
+        COPY (1024000 bytes):           OKAY
+        COPY (1024001 bytes):           OKAY
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt
index 2d91ae251982..d2a84151e99c 100644
--- a/Documentation/PCI/pci-iov-howto.txt
+++ b/Documentation/PCI/pci-iov-howto.txt
@@ -68,6 +68,18 @@ To disable SR-IOV capability:
         echo  0 > \
         /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
 
+To enable auto probing VFs by a compatible driver on the host, run
+command below before enabling SR-IOV capabilities. This is the
+default behavior.
+        echo 1 > \
+        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
+
+To disable auto probing VFs by a compatible driver on the host, run
+command below before enabling SR-IOV capabilities. Updating this
+entry will not affect VFs which are already probed.
+        echo  0 > \
+        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
+
 3.2 Usage example
 
 Following piece of code illustrates the usage of the SR-IOV API.
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 1392c705ceca..b2480dd38c11 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -6,30 +6,40 @@ Required properties:
 - reg-names: Must be "config" for the PCIe configuration space.
     (The old way of getting the configuration address space from "ranges"
     is deprecated and should be avoided.)
+- num-lanes: number of lanes to use
+RC mode:
 - #address-cells: set to <3>
 - #size-cells: set to <2>
 - device_type: set to "pci"
 - ranges: ranges for the PCI memory and I/O regions
 - #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map: standard PCI properties
-        to define the mapping of the PCIe interface to interrupt
+- interrupt-map-mask and interrupt-map: standard PCI
+        properties to define the mapping of the PCIe interface to interrupt
         numbers.
-- num-lanes: number of lanes to use
+EP mode:
+- num-ib-windows: number of inbound address translation
+        windows
+- num-ob-windows: number of outbound address translation
+        windows
 
 Optional properties:
-- num-viewport: number of view ports configured in hardware.  If a platform
-  does not specify it, the driver assumes 2.
 - num-lanes: number of lanes to use (this property should be specified unless
   the link is brought already up in BIOS)
 - reset-gpio: gpio pin number of power good signal
-- bus-range: PCI bus numbers covered (it is recommended for new devicetrees to
-  specify this property, to keep backwards compatibility a range of 0x00-0xff
-  is assumed if not present)
 - clocks: Must contain an entry for each entry in clock-names.
         See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
         - "pcie"
         - "pcie_bus"
+RC mode:
+- num-viewport: number of view ports configured in
+  hardware. If a platform does not specify it, the driver assumes 2.
+- bus-range: PCI bus numbers covered (it is recommended
+  for new devicetrees to specify this property, to keep backwards
+  compatibility a range of 0x00-0xff is assumed if not present)
+EP mode:
+- max-functions: maximum number of functions that can be
+  configured
 
 Example configuration:
 
diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
new file mode 100644
index 000000000000..35d4a979bb7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
@@ -0,0 +1,129 @@
+Faraday Technology FTPCI100 PCI Host Bridge
+
+This PCI bridge is found inside that Cortina Systems Gemini SoC platform and
+is a generic IP block from Faraday Technology. It exists in two variants:
+plain and dual PCI. The plain version embeds a cascading interrupt controller
+into the host bridge. The dual version routes the interrupts to the host
+chips interrupt controller.
+
+The host controller appear on the PCI bus with vendor ID 0x159b (Faraday
+Technology) and product ID 0x4321.
+
+Mandatory properties:
+
+- compatible: ranging from specific to generic, should be one of
+  "cortina,gemini-pci", "faraday,ftpci100"
+  "cortina,gemini-pci-dual", "faraday,ftpci100-dual"
+  "faraday,ftpci100"
+  "faraday,ftpci100-dual"
+- reg: memory base and size for the host bridge
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells: set to <1>
+- bus-range: set to <0x00 0xff>
+- device_type, set to "pci"
+- ranges: see pci.txt
+- interrupt-map-mask: see pci.txt
+- interrupt-map: see pci.txt
+- dma-ranges: three ranges for the inbound memory region. The ranges must
+  be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB,
+  128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as
+  pre-fetchable.
+
+Mandatory subnodes:
+- For "faraday,ftpci100" a node representing the interrupt-controller inside the
+  host bridge is mandatory. It has the following mandatory properties:
+  - interrupt: see interrupt-controller/interrupts.txt
+  - interrupt-parent: see interrupt-controller/interrupts.txt
+  - interrupt-controller: see interrupt-controller/interrupts.txt
+  - #address-cells: set to <0>
+  - #interrupt-cells: set to <1>
+
+I/O space considerations:
+
+The plain variant has 128MiB of non-prefetchable memory space, whereas the
+"dual" variant has 64MiB. Take this into account when describing the ranges.
+
+Interrupt map considerations:
+
+The "dual" variant will get INT A, B, C, D from the system interrupt controller
+and should point to respective interrupt in that controller in its
+interrupt-map.
+
+The code which is the only documentation of how the Faraday PCI (the non-dual
+variant) interrupts assigns the default interrupt mapping/swizzling has
+typically been like this, doing the swizzling on the interrupt controller side
+rather than in the interconnect:
+
+interrupt-map-mask = <0xf800 0 0 7>;
+interrupt-map =
+        <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+        <0x4800 0 0 2 &pci_intc 1>,
+        <0x4800 0 0 3 &pci_intc 2>,
+        <0x4800 0 0 4 &pci_intc 3>,
+        <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+        <0x5000 0 0 2 &pci_intc 2>,
+        <0x5000 0 0 3 &pci_intc 3>,
+        <0x5000 0 0 4 &pci_intc 0>,
+        <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+        <0x5800 0 0 2 &pci_intc 3>,
+        <0x5800 0 0 3 &pci_intc 0>,
+        <0x5800 0 0 4 &pci_intc 1>,
+        <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+        <0x6000 0 0 2 &pci_intc 0>,
+        <0x6000 0 0 3 &pci_intc 1>,
+        <0x6000 0 0 4 &pci_intc 2>;
+
+Example:
+
+pci@50000000 {
+        compatible = "cortina,gemini-pci", "faraday,ftpci100";
+        reg = <0x50000000 0x100>;
+        interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
+                        <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
+                        <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
+                        <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
+        #address-cells = <3>;
+        #size-cells = <2>;
+        #interrupt-cells = <1>;
+
+        bus-range = <0x00 0xff>;
+        ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
+                 <0x01000000 0 0          0x50000000 0 0x00100000>,
+                 /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
+                 <0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
+
+        /* DMA ranges */
+        dma-ranges =
+        /* 128MiB at 0x00000000-0x07ffffff */
+        <0x02000000 0 0x00000000 0x00000000 0 0x08000000>,
+        /* 64MiB at 0x00000000-0x03ffffff */
+        <0x02000000 0 0x00000000 0x00000000 0 0x04000000>,
+        /* 64MiB at 0x00000000-0x03ffffff */
+        <0x02000000 0 0x00000000 0x00000000 0 0x04000000>;
+
+        interrupt-map-mask = <0xf800 0 0 7>;
+        interrupt-map =
+                <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+                <0x4800 0 0 2 &pci_intc 1>,
+                <0x4800 0 0 3 &pci_intc 2>,
+                <0x4800 0 0 4 &pci_intc 3>,
+                <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+                <0x5000 0 0 2 &pci_intc 2>,
+                <0x5000 0 0 3 &pci_intc 3>,
+                <0x5000 0 0 4 &pci_intc 0>,
+                <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+                <0x5800 0 0 2 &pci_intc 3>,
+                <0x5800 0 0 3 &pci_intc 0>,
+                <0x5800 0 0 4 &pci_intc 1>,
+                <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+                <0x6000 0 0 2 &pci_intc 0>,
+                <0x6000 0 0 3 &pci_intc 0>,
+                <0x6000 0 0 4 &pci_intc 0>;
+        pci_intc: interrupt-controller {
+                interrupt-parent = <&intcon>;
+                interrupt-controller;
+                #address-cells = <0>;
+                #interrupt-cells = <1>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index 83aeb1f5a645..e3d5680875b1 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -4,7 +4,11 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
 and thus inherits all the common properties defined in designware-pcie.txt.
 
 Required properties:
-- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
+- compatible:
+        - "fsl,imx6q-pcie"
+        - "fsl,imx6sx-pcie",
+        - "fsl,imx6qp-pcie"
+        - "fsl,imx7d-pcie"
 - reg: base address and length of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -34,6 +38,14 @@ Additional required properties for imx6sx-pcie:
 - clock names: Must include the following additional entries:
         - "pcie_inbound_axi"
 
+Additional required properties for imx7d-pcie:
+- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
+- resets: Must contain phandles to PCIe-related reset lines exposed by SRC
+  IP block
+- reset-names: Must contain the following entires:
+               - "pciephy"
+               - "apps"
+
 Example:
 
         pcie@0x01000000 {
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e25161f351..6a07c96227e0 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,17 +1,22 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
- - reg : Two register ranges as listed in the reg-names property
- - reg-names : The first entry must be "ti-conf" for the TI specific registers
-               The second entry must be "rc-dbics" for the designware pcie
-               registers
-               The third entry must be "config" for the PCIe configuration space
+ - compatible: Should be "ti,dra7-pcie" for RC
+               Should be "ti,dra7-pcie-ep" for EP
  - phys : list of PHY specifiers (used by generic PHY framework)
  - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
                number of PHYs as specified in *phys* property.
  - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
                where <X> is the instance number of the pcie from the HW spec.
+ - num-lanes as specified in ../designware-pcie.txt
+
+HOST MODE
+=========
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : The first entry must be "ti-conf" for the TI specific registers
+               The second entry must be "rc-dbics" for the DesignWare PCIe
+               registers
+               The third entry must be "config" for the PCIe configuration space
  - interrupts : Two interrupt entries must be specified. The first one is for
                 main interrupt line and the second for MSI interrupt line.
  - #address-cells,
@@ -19,13 +24,36 @@ PCIe Designware Controller
    #interrupt-cells,
    device_type,
    ranges,
-   num-lanes,
    interrupt-map-mask,
    interrupt-map : as specified in ../designware-pcie.txt
 
+DEVICE MODE
+===========
+ - reg : Four register ranges as listed in the reg-names property
+ - reg-names : "ti-conf" for the TI specific registers
+               "ep_dbics" for the standard configuration registers as
+                they are locally accessed within the DIF CS space
+               "ep_dbics2" for the standard configuration registers as
+                they are locally accessed within the DIF CS2 space
+               "addr_space" used to map remote RC address space
+ - interrupts : one interrupt entries must be specified for main interrupt.
+ - num-ib-windows : number of inbound address translation windows
+ - num-ob-windows : number of outbound address translation windows
+ - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
+                               should contain the register offset within syscon
+                               and the 2nd argument should contain the bit field
+                               for setting the bit to enable unaligned
+                               access.
+
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
 
+NOTE: Two DT nodes may be added for each PCI controller; one for host
+mode and another for device mode. So in order for PCI to
+work in host mode, EP mode DT node should be disabled and in order to PCI to
+work in EP mode, host mode DT node should be disabled. Host mode and EP
+mode are mutually exclusive.
+
 Example:
 axi {
         compatible = "simple-bus";
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index bf34d5b3a733..e72587fe477d 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -342,8 +342,10 @@ PER-CPU MEM
   devm_free_percpu()
 
 PCI
-  pcim_enable_device()  : after success, all PCI ops become managed
-  pcim_pin_device()     : keep PCI device enabled after release
+  devm_pci_remap_cfgspace()     : ioremap PCI configuration space
+  devm_pci_remap_cfg_resource() : ioremap PCI configuration space resource
+  pcim_enable_device()          : after success, all PCI ops become managed
+  pcim_pin_device()             : keep PCI device enabled after release
 
 PHY
   devm_usb_get_phy()
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 6ea1ceda6f52..06f1d64c6f70 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -113,9 +113,18 @@ Supporting PCI access on new platforms
 --------------------------------------
 
 In order to support PCI resource mapping as described above, Linux platform
-code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function.
-Platforms are free to only support subsets of the mmap functionality, but
-useful return codes should be provided.
+code should ideally define ARCH_GENERIC_PCI_MMAP_RESOURCE and use the generic
+implementation of that functionality. To support the historical interface of
+mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
+
+Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
+implementation of pci_mmap_page_range() instead of defining
+ARCH_GENERIC_PCI_MMAP_RESOURCE.
+
+Platforms which support write-combining maps of PCI resources must define
+arch_can_pci_mmap_wc() which shall evaluate to non-zero at runtime when
+write-combining is permitted. Platforms which support maps of I/O resources
+define arch_can_pci_mmap_io() similarly.
 
 Legacy resources are protected by the HAVE_PCI_LEGACY define.  Platforms
 wishing to support legacy functionality should define it and provide
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index a77ead911956..eccb675a2852 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code  Seq#(hex)	Include File		Comments
 'W'     00-1F   linux/watchdog.h        conflict!
 'W'     00-1F   linux/wanrouter.h       conflict!               (pre 3.9)
 'W'     00-3F   sound/asound.h          conflict!
+'W'     40-5F   drivers/pci/switch/switchtec.c
 'X'     all     fs/xfs/xfs_fs.h         conflict!
                 and fs/xfs/linux-2.6/xfs_ioctl32.h
                 and include/linux/falloc.h
diff --git a/Documentation/misc-devices/pci-endpoint-test.txt b/Documentation/misc-devices/pci-endpoint-test.txt
new file mode 100644
index 000000000000..4ebc3594b32c
--- /dev/null
+++ b/Documentation/misc-devices/pci-endpoint-test.txt
@@ -0,0 +1,35 @@
+Driver for PCI Endpoint Test Function
+
+This driver should be used as a host side driver if the root complex is
+connected to a configurable PCI endpoint running *pci_epf_test* function
+driver configured according to [1].
+
+The "pci_endpoint_test" driver can be used to perform the following tests.
+
+The PCI driver for the test device performs the following tests
+        *) verifying addresses programmed in BAR
+        *) raise legacy IRQ
+        *) raise MSI IRQ
+        *) read data
+        *) write data
+        *) copy data
+
+This misc driver creates /dev/pci-endpoint-test.<num> for every
+*pci_epf_test* function connected to the root complex and "ioctls"
+should be used to perform the above tests.
+
+ioctl
+-----
+ PCITEST_BAR: Tests the BAR. The number of the BAR to be tested
+              should be passed as argument.
+ PCITEST_LEGACY_IRQ: Tests legacy IRQ
+ PCITEST_MSI: Tests message signalled interrupts. The MSI number
+              to be tested should be passed as argument.
+ PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
+                as argument.
+ PCITEST_READ: Perform read tests. The size of the buffer should be passed
+               as argument.
+ PCITEST_COPY: Perform read tests. The size of the buffer should be passed
+               as argument.
+
+[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
new file mode 100644
index 000000000000..a0a9c7b3d4d5
--- /dev/null
+++ b/Documentation/switchtec.txt
@@ -0,0 +1,80 @@
+========================
+Linux Switchtec Support
+========================
+
+Microsemi's "Switchtec" line of PCI switch devices is already
+supported by the kernel with standard PCI switch drivers. However, the
+Switchtec device advertises a special management endpoint which
+enables some additional functionality. This includes:
+
+* Packet and Byte Counters
+* Firmware Upgrades
+* Event and Error logs
+* Querying port link status
+* Custom user firmware commands
+
+The switchtec kernel module implements this functionality.
+
+
+Interface
+=========
+
+The primary means of communicating with the Switchtec management firmware is
+through the Memory-mapped Remote Procedure Call (MRPC) interface.
+Commands are submitted to the interface with a 4-byte command
+identifier and up to 1KB of command specific data. The firmware will
+respond with a 4 bytes return code and up to 1KB of command specific
+data. The interface only processes a single command at a time.
+
+
+Userspace Interface
+===================
+
+The MRPC interface will be exposed to userspace through a simple char
+device: /dev/switchtec#, one for each management endpoint in the system.
+
+The char device has the following semantics:
+
+* A write must consist of at least 4 bytes and no more than 1028 bytes.
+  The first four bytes will be interpreted as the command to run and
+  the remainder will be used as the input data. A write will send the
+  command to the firmware to begin processing.
+
+* Each write must be followed by exactly one read. Any double write will
+  produce an error and any read that doesn't follow a write will
+  produce an error.
+
+* A read will block until the firmware completes the command and return
+  the four bytes of status plus up to 1024 bytes of output data. (The
+  length will be specified by the size parameter of the read call --
+  reading less than 4 bytes will produce an error.
+
+* The poll call will also be supported for userspace applications that
+  need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+  of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+  any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+  indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+  for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+  with the event_id, index and flags set (index being the partition or PFF
+  number for non-global events). It returns whether the event has
+  occurred, the number of times and any event specific data. The flags
+  can be used to clear the count or enable and disable actions to
+  happen when the event occurs.
+  By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+  you can set an event to trigger a poll command to return with
+  POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+  between PCI Function Framework number (used by the event system)
+  and Switchtec Logic Port ID and Partition number (which is more
+  user friendly).