1. 25 6月, 2009 1 次提交
  2. 18 6月, 2009 1 次提交
  3. 17 6月, 2009 1 次提交
    • G
      x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded · f9cde5ff
      Gary Hade 提交于
      Issue a warning if _CRS returns too many resource descriptors to be
      accommodated by the fixed size resource array instances.  If there is no
      transparent bridge on the root bus "too many" is the
      PCI_BUS_NUM_RESOURCES size of the resource array.  Otherwise, the last 3
      slots of the resource array must be excluded making the maximum
      (PCI_BUS_NUM_RESOURCES - 3).
      
      The current code:
       - is silent when _CRS returns too many resource descriptors and
       - incorrectly allows use of the last 3 slots of the resource array
         for a root bus with a transparent bridge
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f9cde5ff
  4. 13 6月, 2009 1 次提交
  5. 12 6月, 2009 1 次提交
  6. 04 6月, 2009 1 次提交
  7. 18 5月, 2009 1 次提交
    • Y
      x86, apic: introduce io_apic_irq_attr · e5198075
      Yinghai Lu 提交于
      according to Ingo, io_apic irq-setup related functions have too many
      parameters with a repetitive signature.
      
      So reduce related funcs to get less params by passing a pointer
      to a newly defined io_apic_irq_attr structure.
      
      v2: io_apic_irq ==> irq_attr
          triggering ==> trigger
      
      v3: add set_io_apic_irq_attr
      
      [ Impact: cleanup ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A08ACD3.2070401@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e5198075
  8. 11 5月, 2009 2 次提交
  9. 23 4月, 2009 4 次提交
  10. 04 4月, 2009 1 次提交
    • S
      x86, PAT: Remove duplicate memtype reserve in pci mmap · 5a3ae276
      Suresh Siddha 提交于
      pci mmap code was doing memtype reserve for a while now. Recently we
      added memtype tracking in remap_pfn_range, and pci code indirectly calls
      remap_pfn_range. So, we don't need seperate tracking in pci code
      anymore. Which means a patch that removes ~50 lines of code :-).
      
      Also, recently we found out that the pci tracking is not working as we expect
      it to work in some cases. Specifically, userlevel X mmap of pci, with some
      recent version of X, is having a problem with vm_page_prot getting reset.
      The pci tracking uses vm_page_prot to pass on the protection type from parent
      to child during fork.
      a) Parent does a pci mmap
      b) We look at PAT and get either UC_MINUS or WC mapping for parent
      c) Store that mapping type in vma vm_page_prot for future use
      d) This thread does a fork
      e) Fork results in mmap_ops ->open for the child process
      f) We get the vm_page_prot from vma and reserve that type for the child process
      
      But, between c) and e) above, the vma vm_page_prot is getting reset to zero.
      This results in PAT reserve failing at the time of fork as in here.
      http://marc.info/?l=linux-kernel&m=123858163103240&w=2
      
      This cleanup makes the above problem go away as we do not depend on
      vm_page_prot in our PAT code anymore.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a3ae276
  11. 27 3月, 2009 1 次提交
  12. 24 3月, 2009 1 次提交
  13. 21 3月, 2009 3 次提交
  14. 20 3月, 2009 2 次提交
  15. 12 3月, 2009 1 次提交
  16. 18 2月, 2009 1 次提交
  17. 06 2月, 2009 1 次提交
  18. 29 1月, 2009 2 次提交
  19. 28 1月, 2009 1 次提交
  20. 14 1月, 2009 1 次提交
  21. 08 1月, 2009 11 次提交
  22. 30 12月, 2008 1 次提交