1. 12 Oct, 2018 1 commit
  2. 10 Oct, 2018 2 commits
    • Christoph Hellwig's avatar
      PCI: Remove pci_unmap_addr() wrappers for DMA API · 18b01b16
      Christoph Hellwig authored
      Only some of these were still used by the cxgb4 driver, and that despite
      the fact that the driver otherwise uses the generic DMA API.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Logan Gunthorpe's avatar
      PCI/P2PDMA: Support peer-to-peer memory · 52916982
      Logan Gunthorpe authored
      Some PCI devices may have memory mapped in a BAR space that's intended for
      use in peer-to-peer transactions.  To enable such transactions the memory
      must be registered with ZONE_DEVICE pages so it can be used by DMA
      interfaces in existing drivers.
      Add an interface for other subsystems to find and allocate chunks of P2P
      memory as necessary to facilitate transfers between two PCI peers:
        struct pci_dev *pci_p2pmem_find[_many]();
        int pci_p2pdma_distance[_many]();
        void *pci_alloc_p2pmem();
      The new interface requires a driver to collect a list of client devices
      involved in the transaction then call pci_p2pmem_find() to obtain any
      suitable P2P memory.  Alternatively, if the caller knows a device which
      provides P2P memory, they can use pci_p2pdma_distance() to determine if it
      is usable.  With a suitable p2pmem device, memory can then be allocated
      with pci_alloc_p2pmem() for use in DMA transactions.
      Depending on hardware, using peer-to-peer memory may reduce the bandwidth
      of the transfer but can significantly reduce pressure on system memory.
      This may be desirable in many cases: for example a system could be designed
      with a small CPU connected to a PCIe switch by a small number of lanes
      which would maximize the number of lanes available to connect to NVMe
      The code is designed to only utilize the p2pmem device if all the devices
      involved in a transfer are behind the same PCI bridge.  This is because we
      have no way of knowing whether peer-to-peer routing between PCIe Root Ports
      is supported (PCIe r4.0, sec 1.3.1).  Additionally, the benefits of P2P
      transfers that go through the RC is limited to only reducing DRAM usage
      and, in some cases, coding convenience.  The PCI-SIG may be exploring
      adding a new capability bit to advertise whether this is possible for
      future hardware.
      This commit includes significant rework and feedback from Christoph
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: Logan Gunthorpe's avatarLogan Gunthorpe <logang@deltatee.com>
      [bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
      to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  3. 02 Oct, 2018 1 commit
  4. 28 Sep, 2018 1 commit
    • Felipe Balbi's avatar
      PCI: Add support for Immediate Readiness · d6112f8d
      Felipe Balbi authored
      PCIe r4.0, sec defines a new bit in the Status Register:
        Immediate Readiness – This optional bit, when Set, indicates the Function
        is guaranteed to be ready to successfully complete valid configuration
        accesses at any time following any reset that the host is capable of
        issuing Configuration Requests to this Function.
        When this bit is Set, for accesses to this Function, software is exempt
        from all requirements to delay configuration accesses following any type
        of reset, including but not limited to the timing requirements defined in
        Section 6.6.
      This means that all delays after a Conventional or Function Reset can be
      This patch reads such bit and caches its value in a flag inside struct
      pci_dev to be checked later if we should delay or can skip delays after a
      reset.  While at that, also move the explicit msleep(100) call from
      pcie_flr() and pci_af_flr() to pci_dev_wait().
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  5. 12 Sep, 2018 1 commit
  6. 22 Aug, 2018 1 commit
  7. 14 Aug, 2018 1 commit
    • Andy Shevchenko's avatar
      PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry · b72ae8ca
      Andy Shevchenko authored
      There are a lot of examples in the kernel where PCI_VDEVICE() is used and
      still looks not so convenient due to additional driver_data field attached.
      Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in
      shortest possible form. For example,
            (kernel_ulong_t) &dwc3_pci_mrfld_properties, },
          { PCI_DEVICE_DATA(INTEL, MRFLD, &dwc3_pci_mrfld_properties) },
      Drivers can be converted later on in independent way.
      While here, remove the unused macro with the same name from Ralink wireless
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: Kalle Valo <kvalo@codeaurora.org>	# for rt2x00
  8. 09 Aug, 2018 2 commits
  9. 31 Jul, 2018 1 commit
    • Hari Vyas's avatar
      PCI: Fix is_added/is_busmaster race condition · 44bda4b7
      Hari Vyas authored
      When a PCI device is detected, pdev->is_added is set to 1 and proc and
      sysfs entries are created.
      When the device is removed, pdev->is_added is checked for one and then
      device is detached with clearing of proc and sys entries and at end,
      pdev->is_added is set to 0.
      is_added and is_busmaster are bit fields in pci_dev structure sharing same
      memory location.
      A strange issue was observed with multiple removal and rescan of a PCIe
      NVMe device using sysfs commands where is_added flag was observed as zero
      instead of one while removing device and proc,sys entries are not cleared.
      This causes issue in later device addition with warning message
      "proc_dir_entry" already registered.
      Debugging revealed a race condition between the PCI core setting the
      is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue
      setting the is_busmaster bit in pci_set_master().  As these fields are not
      handled atomically, that clears the is_added bit.
      Move the is_added bit to a separate private flag variable and use atomic
      functions to set and retrieve the device addition state.  This avoids the
      race because is_added no longer shares a memory location with is_busmaster.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283Signed-off-by: default avatarHari Vyas <hari.vyas@broadcom.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLukas Wunner <lukas@wunner.de>
      Acked-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
  10. 19 Jul, 2018 6 commits
  11. 18 Jul, 2018 1 commit
    • Sergei Shtylyov's avatar
      PCI: OF: Fix I/O space page leak · a5fb9fb0
      Sergei Shtylyov authored
      When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY
      driver was left disabled, the kernel crashed with this BUG:
        kernel BUG at lib/ioremap.c:72!
        Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
        Hardware name: Renesas Condor board based on r8a77980 (DT)
        Workqueue: events deferred_probe_work_func
        pstate: 80000005 (Nzcv daif -PAN -UAO)
        pc : ioremap_page_range+0x370/0x3c8
        lr : ioremap_page_range+0x40/0x3c8
        sp : ffff000008da39e0
        x29: ffff000008da39e0 x28: 00e8000000000f07
        x27: ffff7dfffee00000 x26: 0140000000000000
        x25: ffff7dfffef00000 x24: 00000000000fe100
        x23: ffff80007b906000 x22: ffff000008ab8000
        x21: ffff000008bb1d58 x20: ffff7dfffef00000
        x19: ffff800009c30fb8 x18: 0000000000000001
        x17: 00000000000152d0 x16: 00000000014012d0
        x15: 0000000000000000 x14: 0720072007200720
        x13: 0720072007200720 x12: 0720072007200720
        x11: 0720072007300730 x10: 00000000000000ae
        x9 : 0000000000000000 x8 : ffff7dffff000000
        x7 : 0000000000000000 x6 : 0000000000000100
        x5 : 0000000000000000 x4 : 000000007b906000
        x3 : ffff80007c61a880 x2 : ffff7dfffeefffff
        x1 : 0000000040000000 x0 : 00e80000fe100f07
        Process kworker/0:1 (pid: 39, stack limit = 0x        (ptrval))
        Call trace:
        Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000)
      It turned out that pci_remap_iospace() wasn't undone when the driver's
      probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
      the probe was retried, finally causing the BUG due to trying to remap
      already remapped pages.
      Introduce the devm_pci_remap_iospace() managed API and replace the
      pci_remap_iospace() call with it to fix the bug.
      Fixes: dbf9826d ("PCI: generic: Convert to DT resource parsing API")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      [lorenzo.pieralisi@arm.com: split commit/updated the commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  12. 05 Jul, 2018 1 commit
  13. 30 Jun, 2018 2 commits
    • Sinan Kaya's avatar
      PCI: Enable PASID only if entire path supports End-End TLP prefixes · 7ce3f912
      Sinan Kaya authored
      A PCIe endpoint carries the process address space identifier (PASID) in
      the TLP prefix as part of the memory read/write transaction. The address
      information in the TLP is relevant only for a given PASID context.
      An IOMMU takes PASID value and the address information from the
      TLP to look up the physical address in the system.
      PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20).  Sec says
        It is an error to receive a TLP with an End-End TLP Prefix by a
        Receiver that does not support End-End TLP Prefixes. A TLP in
        violation of this rule is handled as a Malformed TLP. This is a
        reported error associated with the Receiving Port (see Section 6.2).
      Prevent error condition by proactively requiring End-End TLP prefix to be
      supported on the entire data path between the endpoint and the root port
      before enabling PASID.
      Signed-off-by: default avatarSinan Kaya <okaya@codeaurora.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Bjorn Helgaas's avatar
      PCI: Make pci_get_rom_size() static · 783e8496
      Bjorn Helgaas authored
      pci_get_rom_size() is called only from pci_map_rom(), so it can be static.
      Make it static and remove the declaration from include/linux/pci.h.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  14. 26 Jun, 2018 1 commit
    • Bjorn Helgaas's avatar
      PCI: shpchp: Separate existence of SHPC and permission to use it · b03799b0
      Bjorn Helgaas authored
      The shpchp driver registers for all PCI bridge devices.  Its probe method
      should fail if either (1) the bridge doesn't have an SHPC or (2) the OS
      isn't allowed to use it (the platform firmware may be operating the SHPC
      Separate these two tests into:
        - A new shpc_capable() that looks for the SHPC hardware and is applicable
          on all systems (ACPI and non-ACPI), and
        - A simplified acpi_get_hp_hw_control_from_firmware() that we call only
          when we already know an SHPC exists and there may be ACPI methods to
          either request permission to use it (_OSC) or transfer control to the
          OS (OSHP).
      acpi_get_hp_hw_control_from_firmware() is implemented when CONFIG_ACPI=y,
      but does nothing if the current platform doesn't support ACPI.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
  15. 02 Jun, 2018 3 commits
  16. 25 May, 2018 1 commit
    • Bjorn Helgaas's avatar
      PCI: Remove unused pcie_get_minimum_link() · e5b1db01
      Bjorn Helgaas authored
      In some cases pcie_get_minimum_link() returned misleading information
      because it found the slowest link and the narrowest link without
      considering the total bandwidth of the link.
      For example, consider a path with these two links:
        - 16.0 GT/s  x1 link  (16.0 * 10^9 * 128 / 130) *  1 / 8 = 1969 MB/s
        -  2.5 GT/s x16 link  ( 2.5 * 10^9 *   8 /  10) * 16 / 8 = 4000 MB/s
      The available bandwidth of the path is limited by the 16 GT/s link to about
      1969 MB/s, but pcie_get_minimum_link() returned 2.5 GT/s x1, which
      corresponds to only 250 MB/s.
      Callers should use pcie_print_link_status() instead, or
      pcie_bandwidth_available() if they need more detailed information.
      Remove pcie_get_minimum_link() since there are no callers left.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  17. 17 May, 2018 1 commit
  18. 15 May, 2018 1 commit
  19. 10 May, 2018 1 commit
    • Gil Kupfer's avatar
      PCI: Add "pci=noats" boot parameter · cef74409
      Gil Kupfer authored
      Adds a "pci=noats" boot parameter.  When supplied, all ATS related
      functions fail immediately and the IOMMU is configured to not use
      Any function that checks for ATS capabilities directly against the devices
      should also check this flag.  Currently, such functions exist only in IOMMU
      drivers, and they are covered by this patch.
      The motivation behind this patch is the existence of malicious devices.
      Lots of research has been done about how to use the IOMMU as protection
      from such devices.  When ATS is supported, any I/O device can access any
      physical address by faking device-IOTLB entries.  Adding the ability to
      ignore these entries lets sysadmins enhance system security.
      Signed-off-by: default avatarGil Kupfer <gilkup@cs.technion.ac.il>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>
  20. 09 May, 2018 1 commit
  21. 07 May, 2018 2 commits
    • Gilles Buloz's avatar
      PCI: Check whether bridges allow access to extended config space · 17e8f0d4
      Gilles Buloz authored
      Even if a device supports extended config space, i.e., it is a PCI-X Mode 2
      or a PCI Express device, the extended space may not be accessible if
      there's a conventional PCI bus in the path to it.
      We currently figure that out in pci_cfg_space_size() by reading the first
      dword of extended config space.  On most platforms that returns ~0 data if
      the space is inaccessible, but it may set error bits in PCI status
      registers, and on some platforms it causes exceptions that we currently
      don't recover from.
      For example, a PCIe-to-conventional PCI bridge treats config transactions
      with a non-zero Extended Register Address as an Unsupported Request on PCIe
      and a received Master-Abort on the destination bus (see PCI Express to
      PCI/PCI-X Bridge spec, r1.0, sec 4.1.3).
      A sample case is a LS1043A CPU (NXP QorIQ Layerscape) platform with the
      following bus topology:
        LS1043 PCIe Root Port
          -> PEX8112 PCIe-to-PCI bridge (doesn't support ext cfg on PCI side)
            -> PMC slot connector (for legacy PMC modules)
      With a PMC module topology as follows:
        PMC connector
          -> PCI-to-PCIe bridge
            -> PCIe switch (4 ports)
              -> 4 PCIe devices (one on each port)
      The PCIe devices on the PMC module support extended config space, but we
      can't reach it because the PEX8112 can't generate accesses to the extended
      space on its secondary bus.  Attempts to access it cause Unsupported
      Request errors, which result in synchronous aborts on this platform.
      To avoid these errors, check whether bridges are capable of generating
      extended config space addresses on their secondary interfaces.  If they
      can't, we restrict devices below the bridge to only the 256-byte
      PCI-compatible config space.
      Signed-off-by: default avatarGilles Buloz <gilles.buloz@kontron.com>
      [bhelgaas: changelog, rework patch so bus_flags testing is all in
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Bjorn Helgaas's avatar
      PCI: pciehp: Add quirk for Command Completed errata · d22b3621
      Bjorn Helgaas authored
      Several PCIe hotplug controllers have errata that mean they do not set the
      Command Completed bit unless writes to the Slot Command register change
      "Control" bits.  Command Completed is never set for writes that only change
      software notification "Enable" bits.  This results in timeouts like this:
        pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)
      When this erratum is present, avoid these timeouts by marking commands
      "completed" immediately unless they change the "Control" bits.
      Here's the text of the Intel erratum CF118.  We assume this applies to all
      Intel parts:
        CF118        PCIe Slot Status Register Command Completed bit not always
                     updated on any configuration write to the Slot Control
        Problem:     For PCIe root ports (devices 0 - 10) supporting hot-plug,
                     the Slot Status Register (offset AAh) Command Completed
                     (bit[4]) status is updated under the following condition:
                     IOH will set Command Completed bit after delivering the new
                     commands written in the Slot Controller register (offset
                     A8h) to VPP. The IOH detects new commands written in Slot
                     Control register by checking the change of value for Power
                     Controller Control (bit[10]), Power Indicator Control
                     (bits[9:8]), Attention Indicator Control (bits[7:6]), or
                     Electromechanical Interlock Control (bit[11]) fields. Any
                     other configuration writes to the Slot Control register
                     without changing the values of these fields will not cause
                     Command Completed bit to be set.
                     The PCIe Base Specification Revision 2.0 or later describes
                     the “Slot Control Register” in section 7.8.10, as follows
                     (Reference section 7.8.10, Slot Control Register, Offset
                     18h). In hot-plug capable Downstream Ports, a write to the
                     Slot Control register must cause a hot-plug command to be
                     generated (see Section for details on hot-plug
                     commands). A write to the Slot Control register in a
                     Downstream Port that is not hotplug capable must not cause a
                     hot-plug command to be executed.
                     The PCIe Spec intended that every write to the Slot Control
                     Register is a command and expected a command complete status
                     to abstract the VPP implementation specific nuances from the
                     OS software. IOH PCIe Slot Control Register implementation
                     is not fully conforming to the PCIe Specification in this
        Implication: Software checking on the Command Completed status after
                     writing to the Slot Control register may time out.
        Workaround:  Software can read the Slot Control register and compare the
                     existing and new values to determine if it should check the
                     Command Completed status after writing to the Slot Control
      Per Sinan, the Qualcomm QDF2400 controller also does not set the Command
      Completed bit unless writes to the Slot Command register change "Control"
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Link: https://lkml.kernel.org/r/8770820b-85a0-172b-7230-3a44524e6c9f@molgen.mpg.de
      Reported-by: Paul Menzel <pmenzel+linux-pci@molgen.mpg.de>	# Lenovo X60
      Tested-by: Paul Menzel <pmenzel+linux-pci@molgen.mpg.de>	# Lenovo X60
      Signed-off-by: Sinan Kaya <okaya@codeaurora.org>		# Qcom quirk
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
  22. 24 Apr, 2018 1 commit
    • Alexander Duyck's avatar
      PCI/IOV: Add pci_sriov_configure_simple() · 8effc395
      Alexander Duyck authored
      SR-IOV (Single Root I/O Virtualization) is an optional PCIe capability (see
      PCIe r4.0, sec 9).  A PCIe Function with the SR-IOV capability is referred
      to as a PF (Physical Function).  If SR-IOV is enabled on the PF, several
      VFs (Virtual Functions) may be created.  The VFs can be individually
      assigned to virtual machines, which allows them to share a single hardware
      device while being isolated from each other.
      Some SR-IOV devices have resources such as queues and interrupts that must
      be set up in the PF before enabling the VFs, so they require a PF driver to
      do that.
      Other SR-IOV devices don't require any PF setup before enabling VFs.  Add a
      pci_sriov_configure_simple() interface so PF drivers for such devices can
      use it without repeating the VF-enabling code.
      Tested-by: default avatarMark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      [bhelgaas: changelog, comment]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: Christoph Hellwig <hch@lst.de>:wq
  23. 23 Apr, 2018 1 commit
    • Bjorn Helgaas's avatar
      PCI/ACPI: Request LTR control from platform before using it · af8bb9f8
      Bjorn Helgaas authored
      Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC
      to request control of Latency Tolerance Reporting (LTR) before using it.
      Request control of LTR, and if the platform does not grant control, don't
      use it.
      N.B. If the hardware supports LTR and the ASPM L1.2 substate but the BIOS
      doesn't support LTR in _OSC, we previously would enable ASPM L1.2.  This
      patch will prevent us from enabling ASPM L1.2 in that case.  It does not
      prevent us from enabling PCI-PM L1.2, since that doesn't depend on LTR.
      See PCIe r40, sec 5.5.1, for the L1 PM substate entry conditions.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  24. 04 Apr, 2018 1 commit
  25. 03 Apr, 2018 2 commits
    • Tal Gilboa's avatar
      PCI: Add pcie_print_link_status() to log link speed and whether it's limited · 9e506a7b
      Tal Gilboa authored
      Add pcie_print_link_status().  This logs the current settings of the link
      (speed, width, and total available bandwidth).
      If the device is capable of more bandwidth but is limited by a slower
      upstream link, we include information about the link that limits the
      device's performance.
      The user may be able to move the device to a different slot for better
      This provides a unified method for all PCI devices to report status and
      issues, instead of each device reporting in a different way, using
      different code.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: changelog, reword log messages, print device capabilities when
      not limited, print bandwidth in Gb/s]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Tal Gilboa's avatar
      PCI: Add pcie_bandwidth_available() to compute bandwidth available to device · 6db79a88
      Tal Gilboa authored
      Add pcie_bandwidth_available() to compute the bandwidth available to a
      device.  This may be limited by the device itself or by a slower upstream
      link leading to the device.
      The available bandwidth at each link along the path is computed as:
        link_width * link_speed * (1 - encoding_overhead)
      2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth
      available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which
      reduces it by about 1.5%.
      The result is in Mb/s, i.e., megabits/second, of raw bandwidth.
      Also return the device with the slowest link and the speed and width of
      that link.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return
      bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find
      uppermost limiting device, return speed/width of the limiting device]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  26. 31 Mar, 2018 1 commit
    • Mathieu Malaterre's avatar
      PCI/IOV: Add missing prototypes for powerpc pcibios interfaces · 619e6f34
      Mathieu Malaterre authored
      Add missing prototypes for:
        resource_size_t pcibios_default_alignment(void);
        int pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs);
        int pcibios_sriov_disable(struct pci_dev *pdev);
      This fixes the following warnings treated as errors when using W=1:
        arch/powerpc/kernel/pci-common.c:236:17: error: no previous prototype for ‘pcibios_default_alignment’ [-Werror=missing-prototypes]
        arch/powerpc/kernel/pci-common.c:253:5: error: no previous prototype for ‘pcibios_sriov_enable’ [-Werror=missing-prototypes]
        arch/powerpc/kernel/pci-common.c:261:5: error: no previous prototype for ‘pcibios_sriov_disable’ [-Werror=missing-prototypes]
      Also, commit 978d2d68 ("PCI: Add pcibios_iov_resource_alignment()
      interface") added a new function but the prototype was located in the main
      header instead of the CONFIG_PCI_IOV specific section.  Move this function
      next to the newly added ones.
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarBjorn Helgaas <helgaas@kernel.org>
  27. 30 Mar, 2018 2 commits