1. 09 8月, 2005 2 次提交
  2. 08 8月, 2005 1 次提交
    • I
      [PATCH] Fix restore of 64-bit PCI BAR's · cf7bee5a
      Ivan Kokshaysky 提交于
      For 64-bit BAR[i] only pci_dev->resource[i] is valid, ->resource[i+1]
      slot is unused and contains zeroes in all fields.
      
      So when we update a PCI BAR, all we need is just to check that we're
      going to update a _valid_ resource.
      
      Also make sure to write high bits - use "x >> 16 >> 16" (rather than the
      simpler ">> 32") to avoid warnings on 32-bit architectures where we're
      not going to have any high bits.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cf7bee5a
  3. 05 8月, 2005 1 次提交
    • J
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · fec59a71
      John W. Linville 提交于
      Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
      (including BARs) when transitioning from D3hot->D0.  This leaves such
      a device in an inaccessible state.  The patch below causes the BARs
      to be restored when enabling such a device, so that its driver will
      be able to access it.
      
      The patch also adds pci_restore_bars as a new global symbol, and adds a
      correpsonding EXPORT_SYMBOL_GPL for that.
      
      Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
      (re)boot.  Most drivers call pci_enable_device very early, so devices
      left in D3hot that lose configuration during the D3hot->D0 transition
      will be inaccessible to their drivers.
      
      Drivers could be modified to account for this, but it would
      be difficult to know which drivers need modification.  This is
      especially true since often many devices are covered by the same
      driver.  It likely would be necessary to replicate code across dozens
      of drivers.
      
      The patch below should trigger only when transitioning from D3hot->D0
      (or at boot), and only for devices that have the "no soft reset" bit
      cleared in the PM control register.  I believe it is safe to include
      this patch as part of the PCI infrastructure.
      
      The cleanest implementation of pci_restore_bars was to call
      pci_update_resource.  Unfortunately, that does not currently exist
      for the sparc64 architecture.  The patch below includes a null
      implemenation of pci_update_resource for sparc64.
      
      Some have expressed interest in making general use of the the
      pci_restore_bars function, so that has been exported to GPL licensed
      modules.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fec59a71
  4. 03 8月, 2005 1 次提交
    • L
      pci: make bus resource start address override minimum IO address · 688d1918
      Linus Torvalds 提交于
      The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because
      we want to protect badly documented motherboard PCI resources and thus
      don't want to allocate new resources in low IO/MEM space.
      
      However, if we have already discovered a PCI bridge with a specified
      resource base, that should override that decision.
      
      This change will allow us to move the "careful" region upwards without
      resulting in problems allocating resources in low mappings.  This was
      brought on by us having allocated a bus resource at 0x1000, conflicting
      with a undocumented VAIO Sony PI resources.
      688d1918
  5. 30 7月, 2005 3 次提交
  6. 12 7月, 2005 5 次提交
  7. 08 7月, 2005 1 次提交
  8. 07 7月, 2005 4 次提交
  9. 02 7月, 2005 9 次提交
  10. 28 6月, 2005 13 次提交