1. 19 1月, 2018 1 次提交
  2. 17 1月, 2018 1 次提交
    • M
      PCI: Remove unnecessary messages for memory allocation failures · c7abb235
      Markus Elfring 提交于
      Per ebfdc409 ("checkpatch: attempt to find unnecessary 'out of memory'
      messages"), when a memory allocation fails, the memory subsystem emits
      generic "out of memory" messages (see slab_out_of_memory() for some of this
      logging).  Therefore, additional error messages in the caller don't add
      much value.
      
      Remove messages that merely report "out of memory".
      
      This preserves some messages that report additional information, e.g.,
      allocation failures that mean we drop hotplug events.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      [bhelgaas: changelog, squash patches, make similar changes to acpiphp,
      cpqphp, ibmphp, keep warning when dropping hotplug event]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c7abb235
  3. 07 11月, 2017 2 次提交
  4. 26 10月, 2017 1 次提交
    • C
      PCI: Add pci_resize_resource() for resizing BARs · 8bb705e3
      Christian König 提交于
      Add a pci_resize_resource() interface to allow device drivers to resize
      BARs of their devices.
      
      This is useful for devices with large local storage, e.g., graphics
      devices.  These devices often only expose 256MB BARs initially to be
      compatible with 32-bit systems.
      
      This function only tries to reprogram the windows of the bridge directly
      above the requesting device and only the BAR of the same type (usually mem,
      64bit, prefetchable).  This is done to avoid disturbing other drivers by
      changing the BARs of their devices.
      
      Drivers should use the following sequence to resize their BARs:
      1. Disable memory decoding of the device using the PCI cfg dword.
      2. Use pci_release_resource() to release all BARs which can move during the
         resize, including the one you want to resize.
      3. Call pci_resize_resource() for each BAR you want to resize.
      4. Call pci_assign_unassigned_bus_resources() to reassign new locations
         for all BARs which are not resized, but could move.
      5. If everything worked as expected, enable memory decoding in the device
         again using the PCI cfg dword.
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8bb705e3
  5. 25 10月, 2017 1 次提交
  6. 19 4月, 2017 1 次提交
  7. 30 12月, 2016 1 次提交
  8. 11 9月, 2016 1 次提交
  9. 18 8月, 2016 1 次提交
  10. 24 6月, 2016 1 次提交
    • L
      PCI: Add generic pci_bus_claim_resources() · 765bf9b7
      Lorenzo Pieralisi 提交于
      All PCI resources (bridge windows and BARs) should be inserted in the
      iomem_resource and ioport_resource trees so we know what space is occupied
      and what is available for other devices.  There's nothing arch-specific
      about this, but it is currently done by arch-specific code.
      
      Add a generic pci_bus_claim_resources() interface so we can migrate away
      from the arch-specific code.
      
      [bhelgaas: changelog]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Yinghai Lu <yinghai@kernel.org>
      765bf9b7
  11. 21 6月, 2016 1 次提交
    • G
      PCI: Add pcibios_setup_bridge() · d366d28c
      Gavin Shan 提交于
      Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
      which is called for once after PCI probing and resource assignment
      are completed, to allocate platform required resources for PCI devices:
      PE#, IO and MMIO mapping, DMA address translation (TCE) table etc.
      Obviously, it's not hotplug friendly.
      
      This adds weak function pcibios_setup_bridge(), which is called by
      pci_setup_bridge(). PowerPC PowerNV platform will reuse the function
      to assign above platform required resources to newly plugged PCI devices
      during PCI hotplug in subsequent patches.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d366d28c
  12. 06 2月, 2016 1 次提交
  13. 09 1月, 2016 1 次提交
  14. 30 10月, 2015 2 次提交
  15. 02 6月, 2015 1 次提交
    • Y
      PCI: Preserve resource size during alignment reordering · 552bc94e
      Yinghai Lu 提交于
      In d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing
      and assigning"), we store additional alignment in realloc_head and take
      this into consideration for assignment.
      
      In __assign_resources_sorted(), we changed dev_res->res->start, then used
      resource_start() (which depends on res->start), so the recomputed res->end
      was completely bogus.  Even if we'd had the correct size, the end would
      have been off by one.
      
      Preserve the resource size when we adjust its alignment.
      
      [bhelgaas: changelog]
      Fixes: d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      552bc94e
  16. 28 5月, 2015 1 次提交
    • W
      PCI: Fix IOV resource sorting by alignment requirement · a6b65983
      Wei Yang 提交于
      In d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing
      and assigning"), it stores additional alignment in realloc_head and takes
      this into consideration for assignment.
      
      After getting the additional alignment, it reorders the head list so
      resources with bigger alignment are ahead of resources with smaller
      alignment.  It does this by iterating over the head list and inserting
      ahead of any resource with smaller alignment.  This should be done for the
      first occurrence, but the code currently iterates over the whole list.
      
      Fix this by terminating the loop when we find the first smaller resource in
      the head list.
      
      [bhelgaas: changelog]
      Fixes: d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning")
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      a6b65983
  17. 09 4月, 2015 1 次提交
  18. 31 3月, 2015 1 次提交
    • W
      PCI: Consider additional PF's IOV BAR alignment in sizing and assigning · d74b9027
      Wei Yang 提交于
      When sizing and assigning resources, we divide the resources into two
      lists: the requested list and the additional list.  We don't consider the
      alignment of additional VF(n) BAR space.
      
      This is because the alignment required for the VF(n) BAR space is the size
      of an individual VF BAR, not the size of the space for *all* VFs.  But we
      want additional alignment to support partitioning on PowerNV.
      
      Consider the additional IOV BAR alignment when sizing and assigning
      resources.  When there is not enough system MMIO space to accomodate both
      the requested list and the additional list, the PF's IOV BAR alignment will
      not contribute to the bridge. When there is enough system MMIO space for
      both lists, the additional alignment will contribute to the bridge.
      
      The additional alignment is stored in the min_align of pci_dev_resource,
      which is stored in the additional list by add_to_list() at the end of
      pbus_size_mem(). The additional alignment is calculated in
      pci_resource_alignment().  For an IOV BAR, we have arch dependent function
      to get the alignment for different arch.
      
      [bhelgaas: changelog, printk cast]
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d74b9027
  19. 17 1月, 2015 2 次提交
    • Y
      PCI: Add pci_claim_bridge_resource() to clip window if necessary · 8505e729
      Yinghai Lu 提交于
      Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window.  This is
      like regular pci_claim_resource(), except that if we fail to claim the
      window, we check to see if we can reduce the size of the window and try
      again.
      
      This is for scenarios like this:
      
        pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
        pci 0000:00:01.0:   bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
        pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
      
      The 00:01.0 window is illegal: it starts before the host bridge window, so
      we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible.  We
      can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
      
      Previously we discarded the 00:01.0 window and tried to reassign that part
      of the hierarchy from scratch.  That is a problem because Linux doesn't
      always assign things optimally.  For example, in this case, BIOS put the
      01:00.0 device in a prefetchable window below 4GB, but after 5b285415,
      Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
      device can't use it.
      
      Clipping the 00:01.0 window is less intrusive than completely reassigning
      things and is sufficient to let us use most of the BIOS configuration.  Of
      course, it's possible that devices below 00:01.0 will no longer fit.  If
      that's the case, we'll have to reassign things.  But that's a separate
      problem.
      
      [bhelgaas: changelog, split into separate patch]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.16+
      8505e729
    • Y
      PCI: Pass bridge device, not bus, when updating bridge windows · 3f2f4dc4
      Yinghai Lu 提交于
      pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
      pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
      Previously they accepted a pointer to the pci_bus of the secondary bus,
      then looked up the bridge leading to that bus.  Pass the bridge directly,
      which will make it more convenient for future callers.
      
      No functional change.
      
      [bhelgaas: changelog, split into separate patch]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.16+
      3f2f4dc4
  20. 01 10月, 2014 1 次提交
  21. 09 7月, 2014 1 次提交
  22. 11 6月, 2014 2 次提交
  23. 28 5月, 2014 1 次提交
  24. 24 5月, 2014 4 次提交
    • B
      PCI: Add resource allocation comments · 67d29b5c
      Bjorn Helgaas 提交于
      Add comments in the code to match the allocation strategy of 7c671426dfc3
      ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").
      
      No functional change.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      67d29b5c
    • B
      PCI: Change pbus_size_mem() return values to be more conventional · 30afe8d0
      Bjorn Helgaas 提交于
      pbus_size_mem() previously returned 0 for failure and 1 for success.
      Change it to return -ENOSPC for failure and 0 for success.
      
      No functional change.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      30afe8d0
    • Y
      PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources · 5b285415
      Yinghai Lu 提交于
      This patch changes the way we handle 64-bit prefetchable bridge windows to
      make it more likely that we can assign space to all devices.
      
      Previously we put all prefetchable resources in the prefetchable bridge
      window.  If any of those resources was 32-bit only, we restricted the
      window to be below 4GB.
      
      After this patch, we only put 64-bit prefetchable resources in a 64-bit
      prefetchable window.  We put all 32-bit prefetchable resources in the
      non-prefetchable window, even if there are no 64-bit prefetchable
      resources.
      
      With the previous approach, if there was a 32-bit prefetchable resource
      behind a bridge, we forced the bridge's prefetchable window below 4GB,
      which meant that even if there was plenty of space above 4GB available, we
      couldn't use it, and assignment of large 64-bit resources could fail, as
      in the bugzilla below.
      
      The new strategy is:
      
        1) If the prefetchable window is 64 bits wide, we put only 64-bit
           prefetchable resources in it.  Any 32-bit prefetchable resources go in
           the non-prefetchable window.
      
        2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
           prefetchable resources in it.
      
        3) If there is no prefetchable window, all MMIO resources go in the
           non-prefetchable window.
      
      This reduces performance for 32-bit prefetchable resources below a bridge
      with a 64-bit prefetchable window.  We previously assigned prefetchable
      space, but now we'll assign non-prefetchable space.  This is the case even
      if there are no 64-bit prefetchable resources, or if they would all fit
      below 4GB.  In those cases, the old strategy would work and would have
      better performance.
      
      [bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151Tested-by: NGuo Chao <yan@linux.vnet.ibm.com>
      Tested-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5b285415
    • A
      PCI: Support BAR sizes up to 8GB · 14c8530d
      Alan 提交于
      This is needed for some of the Xeon Phi type systems.
      
      [bhelgaas: added Nikhil, use ARRAY_SIZE() to connect with decl, folded in
      Kevin's "order < 0" fix to ARRAY_SIZE() usage]
      Signed-off-by: NNikhil P Rao <nikhil.rao@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      14c8530d
  25. 30 4月, 2014 1 次提交
    • B
      PCI: Remove unnecessary __ref annotations · 10874f5a
      Bjorn Helgaas 提交于
      Some PCI functions used to be marked __devinit.  When CONFIG_HOTPLUG was
      not set, these functions were discarded after boot.  A few callers of these
      __devinit functions were marked __ref to indicate that they could safely
      call the __devinit functions even though the callers were not __devinit.
      
      But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
      annotations is also gone, so remove them.  Relevant historical commits:
      
        54b956b9 Remove __dev* markings from init.h
        a8e4b9c1 PCI: add generic pci_hp_add_bridge()
        0ab2b57f PCI: fix section mismatch warning in pci_scan_child_bus
        451124a7 PCI: fix 4x section mismatch warnings
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      10874f5a
  26. 22 12月, 2013 1 次提交
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      These interfaces:
      
        pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
      
      took a pci_dev, but they really depend only on the pci_bus.  And we want to
      use them in resource allocation paths where we have the bus but not a
      device, so this patch converts them to take the pci_bus instead of the
      pci_dev:
      
        pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
      
      In fact, with standard PCI-PCI bridges, they only depend on the host
      bridge, because that's the only place address translation occurs, but
      we aren't going that far yet.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  27. 13 12月, 2013 2 次提交
    • B
      PCI: Stop clearing bridge Secondary Status when setting up I/O aperture · 5b764b83
      Bjorn Helgaas 提交于
      pci_setup_bridge_io() accessed PCI_IO_BASE and PCI_IO_LIMIT using dword
      (32-bit) reads and writes, which also access the Secondary Status register.
      Since the Secondary Status register is in the upper 16 bits of the dword,
      and we preserved those upper 16 bits, this had the effect of clearing any
      of the write-1-to-clear bits that happened to be set in the Secondary
      Status register.
      
      That's not what we want, so use word (16-bit) accesses to update only
      PCI_IO_BASE and PCI_IO_LIMIT.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5b764b83
    • B
      PCI: Prevent bus conflicts while checking for bridge apertures · d2f54d9b
      Bjorn Helgaas 提交于
      pci_bridge_check_ranges() determines whether the bridge supports an I/O
      aperture and a prefetchable memory aperture.
      
      Previously, if the I/O aperture was unsupported, disabled, or configured at
      [io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
      if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
      The enabled aperture may conflict with other devices in the system.
      
      Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
      PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
      [mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
      
      All we need to know is whether the base and limit registers are writable,
      so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
      0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
      PCI_PREF_MEMORY_LIMIT = 0xffe0.
      
      Writing non-zero values to both the base and limit registers means we
      detect whether either or both are writable, as we did before.
      Reported-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Based-on-patch-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d2f54d9b
  28. 15 11月, 2013 1 次提交
  29. 26 9月, 2013 2 次提交
  30. 06 8月, 2013 1 次提交
  31. 03 8月, 2013 1 次提交