1. 18 Nov, 2016 1 commit
    • Lukas Wunner's avatar
      PCI: Autosense device removal in pci_bridge_d3_update() · 1ed276a7
      Lukas Wunner authored
      The algorithm to update the flag indicating whether a bridge may go to D3
      makes a few optimizations based on whether the update was caused by the
      removal of a device on the one hand, versus the addition of a device or the
      change of its D3cold flags on the other hand.
      
      The information whether the update pertains to a removal is currently
      passed in by the caller, but the function may as well determine that itself
      by examining the device in question, thereby allowing for a considerable
      simplification and reduction of the code.
      
      Out of several options to determine removal, I've chosen the function
      device_is_registered() because it's cheap:  It merely returns the
      dev->kobj.state_in_sysfs flag.  That flag is set through device_add() when
      the root bus is scanned and cleared through device_remove().  The call to
      pci_bridge_d3_update() happens after each of these calls, respectively, so
      the ordering is correct.
      
      No functional change intended.
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1ed276a7
  2. 13 Jun, 2016 1 commit
    • Mika Westerberg's avatar
      PCI: Put PCIe ports into D3 during suspend · 9d26d3a8
      Mika Westerberg authored
      Currently the Linux PCI core does not touch power state of PCI bridges and
      PCIe ports when system suspend is entered.  Leaving them in D0 consumes
      power unnecessarily and may prevent the CPU from entering deeper C-states.
      
      With recent PCIe hardware we can power down the ports to save power given
      that we take into account few restrictions:
      
        - The PCIe port hardware is recent enough, starting from 2015.
      
        - Devices connected to PCIe ports are effectively in D3cold once the port
          is transitioned to D3 (the config space is not accessible anymore and
          the link may be powered down).
      
        - Devices behind the PCIe port need to be allowed to transition to D3cold
          and back.  There is a way both drivers and userspace can forbid this.
      
        - If the device behind the PCIe port is capable of waking the system it
          needs to be able to do so from D3cold.
      
      This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
      flag is set and cleared by the PCI core whenever there is a change in power
      management state of any of the devices behind the PCIe port.  When system
      later on is suspended we only need to check this flag and if it is true
      transition the port to D3 otherwise we leave it in D0.
      
      Also provide override mechanism via command line parameter
      "pcie_port_pm=[off|force]" that can be used to disable or enable the
      feature regardless of the BIOS manufacturing date.
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  3. 06 Jun, 2016 1 commit
    • Bjorn Helgaas's avatar
      PCI: Add devm_request_pci_bus_resources() · 950334bc
      Bjorn Helgaas authored
      Several host bridge drivers iterate through the list of bridge windows to
      request resources.  Several others don't request the window resources at
      all.
      
      Add a devm_request_pci_bus_resources() interface to make it easier for
      drivers to request all the window resources.  Export to GPL modules (from
      Arnd Bergmann <arnd@arndb.de>).
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      950334bc
  4. 02 May, 2016 2 commits
    • Lukas Wunner's avatar
      PCI: Do not treat EPROBE_DEFER as device attach failure · 9a2a5a63
      Lukas Wunner authored
      Linux 4.5 introduced a behavioral change in device probing during the
      suspend process with commit 013c074f ("PM / sleep: prohibit devices
      probing during suspend/hibernation"): It defers device probing during the
      entire suspend process, starting from the prepare phase and ending with the
      complete phase.  A rule existed before that "we rely on subsystems not to
      do any probing once a device is suspended" but it is enforced only now
      (Alan Stern, https://lkml.org/lkml/2015/9/15/908).
      
      This resulted in a WARN splat if a PCI device (e.g., Thunderbolt) is
      plugged in while the system is asleep: Upon waking up, pciehp_resume()
      discovers new devices in the resume phase and immediately tries to bind
      them to a driver.  Since probing is now deferred, device_attach() returns
      -EPROBE_DEFER, which provoked a WARN in pci_bus_add_device().
      
      Linux 4.6-rc1 aggravates the situation with commit ab1a187b ("PCI:
      Check device_attach() return value always"): If device_attach() returns a
      negative value, pci_bus_add_device() now removes the sysfs and procfs
      entries for the device and pci_bus_add_devices() subsequently locks up with
      a BUG.  Even with the BUG fixed we're still in trouble because the device
      remains on the deferred probing list even though its sysfs and procfs
      entries are gone and its children won't be added.
      
      Fix by not interpreting -EPROBE_DEFER as failure.  The device will be
      probed eventually (through device_unblock_probing() in dpm_complete()) and
      there is proper locking in place to avoid races (e.g., if devices are
      unplugged again und thus deleted from the system before deferred probing
      happens, I have tested this).  Also, those functions which dereference
      dev->driver (e.g. pci_pm_*()) do contain proper NULL pointer checks.  So it
      seems safe to ignore -EPROBE_DEFER.
      
      Fixes: ab1a187b ("PCI: Check device_attach() return value always")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      9a2a5a63
    • Lukas Wunner's avatar
      PCI: Fix BUG on device attach failure · 1e398eae
      Lukas Wunner authored
      Previously when pci_bus_add_device() called device_attach() and it returned
      a negative value, we emitted a WARN but carried on.
      
      Commit ab1a187b ("PCI: Check device_attach() return value always"),
      introduced in Linux 4.6-rc1, changed this to unwind all steps preceding
      device_attach() and to not set dev->is_added = 1.
      
      The latter leads to a BUG if pci_bus_add_device() was called from
      pci_bus_add_devices().  Fix by not recursing to a child bus if
      device_attach() failed for the bridge leading to it.
      
      This can be triggered by plugging in a PCI device (e.g. Thunderbolt) while
      the system is asleep.  The system locks up when woken because
      device_attach() returns -EPROBE_DEFER.
      
      Fixes: ab1a187b ("PCI: Check device_attach() return value always")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e398eae
  5. 08 Mar, 2016 1 commit
  6. 05 Feb, 2016 1 commit
  7. 06 Jan, 2016 1 commit
  8. 22 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Clear IORESOURCE_UNSET when clipping a bridge window · b838b39e
      Bjorn Helgaas authored
      c770cb4c ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET
      if we fail to claim a resource.  If we tried to claim a bridge window,
      failed, clipped the window, and tried to claim the clipped window, we
      failed again because of IORESOURCE_UNSET:
      
        pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window]
        pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window
        pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0:   bridge window [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned
      
      The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref].  That
      starts before the host bridge window [mem 0xc0000000-0xffffffff window], so
      we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref].
      But we left it marked IORESOURCE_UNSET, so the second claim failed when it
      should have succeeded.
      
      This means downstream devices will also fail for lack of resources, e.g.,
      in the bugzilla below,
      
        radeon 0000:01:00.0: Fatal error during GPU init
      
      Clear IORESOURCE_UNSET when we clip a bridge window.  Also clear
      IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly
      what the original window was and how it now fits inside the upstream
      window.
      
      Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c47Based-on-patch-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Based-on-patch-by: default avatarYinghai Lu <yinghai@kernel.org>
      Tested-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      CC: stable@vger.kernel.org	# v4.1+
      b838b39e
  9. 29 May, 2015 1 commit
  10. 05 Feb, 2015 1 commit
  11. 16 Jan, 2015 1 commit
  12. 10 Jun, 2014 1 commit
  13. 30 May, 2014 1 commit
  14. 14 Apr, 2014 1 commit
  15. 19 Mar, 2014 3 commits
    • Bjorn Helgaas's avatar
      PCI: Change pci_bus_alloc_resource() type_mask to unsigned long · 664c2848
      Bjorn Helgaas authored
      The pci_bus_alloc_resource() "type_mask" parameter is used to compare with
      the "flags" member of a struct resource, so it should be the same type,
      namely "unsigned long".
      
      No functional change because all current IORESOURCE_* flags fit in 32 bits.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      664c2848
    • Bjorn Helgaas's avatar
      PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region() · aa11fc58
      Bjorn Helgaas authored
      When allocating space from a bus resource, i.e., from apertures leading to
      this bus, make sure the entire resource type matches.  The previous code
      assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit
      set, but this is not true.  IORESOURCE_TYPE_BITS is really an enumeration,
      and we have to check all the bits.
      
      See 72dcb119 ("resources: Add register address resource type").
      
      No functional change.  If we used this path for allocating IRQs, DMA
      channels, or bus numbers, this would fix a bug because those types are
      indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM.  But we
      don't, so this shouldn't make any difference.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      aa11fc58
    • Bjorn Helgaas's avatar
      PCI: Don't check resource_size() in pci_bus_alloc_resource() · e20fa660
      Bjorn Helgaas authored
      Paul reported that after f75b99d5 ("PCI: Enforce bus address limits in
      resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not
      set), intel-gtt complained "can't ioremap flush page - no chipset
      flushing".  In addition, other PCI resource allocations, e.g., for bridge
      windows, failed.
      
      This happens because we incorrectly skip bus resources of
      [mem 0x00000000-0xffffffff] because we think they are of size zero.
      When resource_size_t is 32 bits wide, resource_size() on
      [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1)
      overflows.
      
      Therefore, we can't use "resource_size() == 0" to decide that allocation
      from this resource will fail.  allocate_resource() should fail anyway if it
      can't satisfy the address constraints, so we should just depend on that.
      
      A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
      but we do fall back to it as a default when we don't have information about
      host bridge apertures.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
      Fixes: f75b99d5 PCI: Enforce bus address limits in resource allocation
      Reported-and-tested-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      e20fa660
  16. 12 Mar, 2014 1 commit
    • Bjorn Helgaas's avatar
      PCI: Don't check resource_size() in pci_bus_alloc_resource() · ac93ac74
      Bjorn Helgaas authored
      Paul reported that after f75b99d5 ("PCI: Enforce bus address limits in
      resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not
      set), intel-gtt complained "can't ioremap flush page - no chipset
      flushing".  In addition, other PCI resource allocations, e.g., for bridge
      windows, failed.
      
      This happens because we incorrectly skip bus resources of
      [mem 0x00000000-0xffffffff] because we think they are of size zero.
      When resource_size_t is 32 bits wide, resource_size() on
      [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1)
      overflows.
      
      Therefore, we can't use "resource_size() == 0" to decide that allocation
      from this resource will fail.  allocate_resource() should fail anyway if it
      can't satisfy the address constraints, so we should just depend on that.
      
      A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
      but we do fall back to it as a default when we don't have information about
      host bridge apertures.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
      Fixes: f75b99d5 PCI: Enforce bus address limits in resource allocation
      Reported-and-tested-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      ac93ac74
  17. 07 Jan, 2014 3 commits
    • Yinghai Lu's avatar
      PCI: Allocate 64-bit BARs above 4G when possible · d56dbf5b
      Yinghai Lu authored
      Try to allocate space for 64-bit BARs above 4G first, to preserve the space
      below 4G for 32-bit BARs.  If there's no space above 4G available, fall
      back to allocating anywhere.
      
      [bhelgaas: reworked starting from http://lkml.kernel.org/r/1387485843-17403-2-git-send-email-yinghai@kernel.org]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d56dbf5b
    • Yinghai Lu's avatar
      PCI: Enforce bus address limits in resource allocation · f75b99d5
      Yinghai Lu authored
      When allocating space for 32-bit BARs, we previously limited RESOURCE
      addresses so they would fit in 32 bits.  However, the BUS address need not
      be the same as the resource address, and it's the bus address that must fit
      in the 32-bit BAR.
      
      This patch adds:
      
        - pci_clip_resource_to_region(), which clips a resource so it contains
          only the range that maps to the specified bus address region, e.g., to
          clip a resource to 32-bit bus addresses, and
      
        - pci_bus_alloc_from_region(), which allocates space for a resource from
          the specified bus address region,
      
      and changes pci_bus_alloc_resource() to allocate space for 64-bit BARs from
      the entire bus address region, and space for 32-bit BARs from only the bus
      address region below 4GB.
      
      If we had this window:
      
        pci_root HWP0002:0a: host bridge window [mem 0xf0180000000-0xf01fedfffff] (bus address [0x80000000-0xfedfffff])
      
      we previously could not put a 32-bit BAR there, because the CPU addresses
      don't fit in 32 bits.  This patch fixes this, so we can use this space for
      32-bit BARs.
      
      It's also possible (though unlikely) to have resources with 32-bit CPU
      addresses but bus addresses above 4GB.  In this case the previous code
      would allocate space that a 32-bit BAR could not map.
      
      Remove PCIBIOS_MAX_MEM_32, which is no longer used.
      
      [bhelgaas: reworked starting from http://lkml.kernel.org/r/1386658484-15774-3-git-send-email-yinghai@kernel.org]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      f75b99d5
    • Bjorn Helgaas's avatar
      PCI: Split out bridge window override of minimum allocation address · 36e097a8
      Bjorn Helgaas authored
      pci_bus_alloc_resource() avoids allocating space below the "min" supplied
      by the caller (usually PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM).  This is to
      protect badly documented motherboard resources.  But if we're allocating
      space inside an already-configured PCI-PCI bridge window, we ignore "min".
      
      See 688d1918 ("pci: make bus resource start address override minimum IO
      address").
      
      This patch moves the check to make it more visible and simplify future
      patches.  No functional change.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      36e097a8
  18. 18 Dec, 2013 1 commit
  19. 25 Jul, 2013 1 commit
  20. 27 May, 2013 1 commit
  21. 07 May, 2013 1 commit
  22. 17 Apr, 2013 1 commit
  23. 12 Apr, 2013 1 commit
  24. 25 Jan, 2013 2 commits
    • Yinghai Lu's avatar
      PCI: Put pci_dev in device tree as early as possible · 4f535093
      Yinghai Lu authored
      We want to put pci_dev structs in the device tree as soon as possible so
      for_each_pci_dev() iteration will not miss them, but driver attachment
      needs to be delayed until after pci_assign_unassigned_resources() to make
      sure all devices have resources assigned first.
      
      This patch moves device registering from pci_bus_add_devices() to
      pci_device_add(), which happens earlier, leaving driver attachment in
      pci_bus_add_devices().
      
      It also removes unattached child bus handling in pci_bus_add_devices().
      That's not needed because child bus via pci_add_new_bus() is already
      in parent bus children list.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4f535093
    • Yinghai Lu's avatar
      PCI: Skip attaching driver in device_add() · 58d9a38f
      Yinghai Lu authored
      We want to add PCI devices to the device tree as early as possible but
      delay attaching drivers.
      
      device_add() adds a device to the device hierarchy and (via
      device_attach()) attaches a matching driver and calls its .probe() method.
      We want to separate adding the device to the hierarchy from attaching the
      driver.
      
      This patch does that by adding "match_driver" in struct pci_dev.  When
      false, we return failure from pci_bus_match(), which makes device_attach()
      believe there's no matching driver.
      
      Later, we set "match_driver = true" and call device_attach() again, which
      now attaches the driver and calls its .probe() method.
      
      [bhelgaas: changelog, explicitly init dev->match_driver,
      fold device_attach() call into pci_bus_add_device()]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58d9a38f
  25. 07 Jan, 2013 1 commit
  26. 05 Dec, 2012 1 commit
  27. 02 Nov, 2012 1 commit
    • Huang Ying's avatar
      PCI/PM: Fix deadlock when unbinding device if parent in D3cold · 90b5c1d7
      Huang Ying authored
      If a PCI device and its parents are put into D3cold, unbinding the
      device will trigger deadlock as follow:
      
      - driver_unbind
        - device_release_driver
          - device_lock(dev)				<--- previous lock here
          - __device_release_driver
            - pm_runtime_get_sync
              ...
                - rpm_resume(dev)
                  - rpm_resume(dev->parent)
                    ...
                      - pci_pm_runtime_resume
                        ...
                        - pci_set_power_state
                          - __pci_start_power_transition
                            - pci_wakeup_bus(dev->parent->subordinate)
                              - pci_walk_bus
                                - device_lock(dev)	<--- deadlock here
      
      
      If we do not do device_lock in pci_walk_bus, we can avoid deadlock.
      Device_lock in pci_walk_bus is introduced in commit:
      d71374da, corresponding email thread
      is: https://lkml.org/lkml/2006/5/26/38.  The patch author Zhang Yanmin
      said device_lock is added to pci_walk_bus because:
      
        Some error handling functions call pci_walk_bus. For example, PCIe
        aer. Here we lock the device, so the driver wouldn't detach from the
        device, as the cb might call driver's callback function.
      
      So I fixed the deadlock as follows:
      
      - remove device_lock from pci_walk_bus
      - add device_lock into callback if callback will call driver's callback
      
      I checked pci_walk_bus users one by one, and found only PCIe aer needs
      device lock.
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org		# v3.6+
      CC: Zhang Yanmin <yanmin.zhang@intel.com>
      90b5c1d7
  28. 18 Sep, 2012 1 commit
    • Yinghai Lu's avatar
      PCI: Use correct type when freeing bus resource list · 817a2685
      Yinghai Lu authored
      Should use struct pci_bus_resource instead of struct pci_host_bridge_window
      
      Commit 45ca9e97 ("PCI: add helpers for building PCI bus resource lists")
      added pci_free_resource_list() and used it in pci_bus_remove_resources().
      Later it was also used for host bridge aperture lists, which was fine until
      commit 0efd5aab ("PCI: add struct pci_host_bridge_window with CPU/bus
      address offset").  That commit added offset information, so we needed a
      struct pci_host_bridge_window that was separate from struct
      pci_bus_resource.
      
      Commit 0efd5aab should have split the host bridge aperture users of
      pci_free_resource_list() from the pci_bus_resource user
      (pci_bus_remove_resources()), but it did not.
      
      [bhelgaas: changelog -- 0efd5aab was mine, so this is all my fault]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      817a2685
  29. 16 Jul, 2012 1 commit
  30. 10 Jul, 2012 1 commit
    • Myron Stowe's avatar
      PCI: call final fixups hot-added devices · 735bff10
      Myron Stowe authored
      Final fixups are currently applied only at boot-time by
      pci_apply_final_quirks(), which is an fs_initcall().  Hot-added devices
      don't get these fixups, so they may not be completely initialized.
      
      This patch makes us run final fixups for hot-added devices in
      pci_bus_add_device() just before the new device becomes eligible for driver
      binding.
      
      This patch keeps the fs_initcall() for devices present at boot because we
      do resource assignment between pci_bus_add_device and the fs_initcall(),
      and we don't want to break any fixups that depend on that assignment.  This
      is a design issue that may be addressed in the future -- any resource
      assignment should be done *before* device_add().
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      735bff10
  31. 24 Feb, 2012 1 commit
    • Bjorn Helgaas's avatar
      PCI: add struct pci_host_bridge_window with CPU/bus address offset · 0efd5aab
      Bjorn Helgaas authored
      Some PCI host bridges apply an address offset, so bus addresses on PCI are
      different from CPU addresses.  This patch adds a way for architectures to
      tell the PCI core about this offset.  For example:
      
          LIST_HEAD(resources);
          pci_add_resource_offset(&resources, host->io_space, host->io_offset);
          pci_add_resource_offset(&resources, host->mem_space, host->mem_offset);
          pci_scan_root_bus(parent, bus, ops, sysdata, &resources);
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0efd5aab
  32. 06 Jan, 2012 1 commit
  33. 21 May, 2011 1 commit
  34. 17 Dec, 2010 1 commit