1. 22 9月, 2012 1 次提交
  2. 19 9月, 2012 2 次提交
  3. 06 7月, 2012 1 次提交
  4. 14 6月, 2012 2 次提交
  5. 29 3月, 2012 1 次提交
  6. 24 2月, 2012 1 次提交
  7. 07 1月, 2012 3 次提交
  8. 01 11月, 2011 1 次提交
  9. 04 4月, 2010 1 次提交
  10. 24 2月, 2010 2 次提交
    • B
      PCI: augment bus resource table with a list · 2fe2abf8
      Bjorn Helgaas 提交于
      Previously we used a table of size PCI_BUS_NUM_RESOURCES (16) for resources
      forwarded to a bus by its upstream bridge.  We've increased this size
      several times when the table overflowed.
      
      But there's no good limit on the number of resources because host bridges
      and subtractive decode bridges can forward any number of ranges to their
      secondary buses.
      
      This patch reduces the table to only PCI_BRIDGE_RESOURCE_NUM (4) entries,
      which corresponds to the number of windows a PCI-to-PCI (3) or CardBus (4)
      bridge can positively decode.  Any additional resources, e.g., PCI host
      bridge windows or subtractively-decoded regions, are kept in a list.
      
      I'd prefer a single list rather than this split table/list approach, but
      that requires simultaneous changes to every architecture.  This approach
      only requires immediate changes where we set up (a) host bridges with more
      than four windows and (b) subtractive-decode P2P bridges, and we can
      incrementally change other architectures to use the list.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2fe2abf8
    • B
      PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refs · 89a74ecc
      Bjorn Helgaas 提交于
      No functional change; this converts loops that iterate from 0 to
      PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the
      pci_bus_for_each_resource() iterator instead.
      
      This doesn't change the way resources are stored; it merely removes
      dependencies on the fact that they're in a table.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      89a74ecc
  11. 23 2月, 2010 2 次提交
  12. 05 11月, 2009 3 次提交
  13. 14 10月, 2009 1 次提交
  14. 01 7月, 2009 1 次提交
  15. 18 6月, 2009 2 次提交
  16. 16 1月, 2009 1 次提交
  17. 21 10月, 2008 1 次提交
  18. 19 8月, 2008 1 次提交
    • L
      [IA64] pci_acpi_scan_root cleanup · 8a20fd52
      Luck, Tony 提交于
      The code walks all the acpi _CRS methods to see how many windows
      to allocate.  It then scans them all again to insert_resource()
      for each *even if the first scan found that there were none*.
      
      Move the second scan inside the "if (windows)" clause.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8a20fd52
  19. 21 4月, 2008 1 次提交
  20. 16 4月, 2008 1 次提交
  21. 07 3月, 2008 1 次提交
  22. 11 2月, 2008 1 次提交
  23. 26 7月, 2007 1 次提交
  24. 12 7月, 2007 1 次提交
    • A
      [IA64] prevent MCA when performing MMIO mmap to PCI config space · 012b7105
      Alex Chiang 提交于
      Example memory map (HP rx7640 with 'default' acpiconfig setting, VGA disabled):
         0x00000000 - 0x3FFFBFFF  supports only WB (cacheable) access
      
      If a user attempts to perform an MMIO mmap (using the PCIIOC_MMAP_IS_MEM ioctl)
      to PCI config space (like mmap'ing and accessing memory at 0xA0000),
      we will MCA because the kernel will attempt to use a mapping with the UC
      attribute.
      
      So check the memory attribute in kern_mmap and the EFI memmap. If WC is
      requested, and WC or UC access is supported for the region, allow it.
      Otherwise, use the same attribute the kernel uses.
      
      Updates documentation and test cases as well.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      012b7105
  25. 23 5月, 2007 1 次提交
  26. 09 5月, 2007 1 次提交
  27. 31 3月, 2007 1 次提交
  28. 30 3月, 2007 1 次提交
  29. 29 3月, 2007 1 次提交
  30. 08 12月, 2006 1 次提交
  31. 07 12月, 2006 1 次提交