1. 20 May, 2011 1 commit
    • Linus Torvalds's avatar
      sanitize <linux/prefetch.h> usage · 268bb0ce
      Linus Torvalds authored
      Commit e66eed65
      
       ("list: remove prefetching from regular list
      iterators") removed the include of prefetch.h from list.h, which
      uncovered several cases that had apparently relied on that rather
      obscure header file dependency.
      
      So this fixes things up a bit, using
      
         grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
         grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')
      
      to guide us in finding files that either need <linux/prefetch.h>
      inclusion, or have it despite not needing it.
      
      There are more of them around (mostly network drivers), but this gets
      many core ones.
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      268bb0ce
  2. 18 May, 2010 1 commit
  3. 15 Dec, 2009 1 commit
  4. 04 Dec, 2009 1 commit
  5. 27 Aug, 2009 1 commit
    • Bob Moore's avatar
      ACPICA: Major update for acpi_get_object_info external interface · 15b8dd53
      Bob Moore authored
      
      
      Completed a major update for the acpi_get_object_info external interface.
      Changes include:
       - Support for variable, unlimited length HID, UID, and CID strings
       - Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.)
       - Call the _SxW power methods on behalf of a device object
       - Determine if a device is a PCI root bridge
       - Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO.
      These changes will require an update to all callers of this interface.
      See the ACPICA Programmer Reference for details.
      
      Also, update all invocations of acpi_get_object_info interface
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLin Ming <ming.m.lin@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      15b8dd53
  6. 17 Jun, 2009 2 commits
  7. 30 Jan, 2009 1 commit
  8. 06 Jan, 2009 4 commits
  9. 20 Oct, 2008 1 commit
  10. 26 Jul, 2008 1 commit
    • FUJITA Tomonori's avatar
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori authored
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423
      
      ).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  11. 29 Apr, 2008 2 commits
  12. 09 Apr, 2008 1 commit
  13. 06 Mar, 2008 1 commit
  14. 05 Feb, 2008 1 commit
  15. 04 Feb, 2008 1 commit
  16. 19 Dec, 2007 1 commit
  17. 22 Oct, 2007 1 commit
  18. 17 Oct, 2007 1 commit
  19. 16 Oct, 2007 1 commit
  20. 27 Jul, 2007 1 commit
  21. 13 Jul, 2007 1 commit
    • Terry Loftin's avatar
      [IA64] use machvec=dig on hpzx1 platforms · 51b58e3e
      Terry Loftin authored
      
      
      On HP zx1 machines, the 'machvec=dig' parameter is needed for the
      kdump kernel to avoid problems with the HP sba iommu.  The problem
      is that during the boot of the kdump kernel, the iommu is re-initialized,
      so in-flight DMA from improperly shutdown drivers causes an IOTLB
      miss which leads to an MCA.  With kdump, the idea is to get into the
      kdump kernel with as little code as we can, so shutting down drivers
      properly is not an option.
      
      The workaround is to add 'machvec=dig' to the kdump kernel boot
      parameters.  This makes the kdump kernel avoid using the sba iommu
      altogether, leaving the IOTLB intact.  Any ongoing DMA falls
      harmlessly outside the kdump kernel.  After the kdump kernel reboots,
      all devices will have been shutdown properly and DMA stopped.
      
      This patch pushes that functionality into the sba iommu
      initialization code, so that users won't have to find the obscure
      documentation telling them about 'machvec=dig'.
      
      This patch only affects HP platforms.  It still includes one
      extern declaration in the file, because no applicable header file
      exists.
      Signed-off-by: default avatarTerry Loftin <terry.loftin@hp.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      51b58e3e
  22. 12 Feb, 2007 1 commit
  23. 07 Dec, 2006 1 commit
  24. 30 Nov, 2006 1 commit
  25. 30 Jun, 2006 1 commit
  26. 23 Jun, 2006 1 commit
  27. 02 Apr, 2006 1 commit
    • Len Brown's avatar
      ACPI: ia64 buildfix · 144c87b4
      Len Brown authored
      arch/ia64/hp/common/sba_iommu.c used ACPI_MEM_FREE instead of kfree()
      
      Signed-off-by: Len Brown <len.brown@intel.com
      144c87b4
  28. 28 Oct, 2005 1 commit
  29. 14 Sep, 2005 1 commit
    • Alex Williamson's avatar
      [IA64] more robust zx1/sx1000 machvec support · 0b9afede
      Alex Williamson authored
      
      
      Machine vector selection has always been a bit of a hack given how
      early in system boot it needs to be done.  Services like ACPI namespace
      are not available and there are non-trivial problems to moving them to
      early boot.  However, there's no reason we can't change to a different
      machvec later in boot when the services we need are available.  By
      adding a entry point for later initialization of the swiotlb, we can add
      an error path for the hpzx1 machevec initialization and fall back to the
      DIG machine vector if IOMMU hardware isn't found in the system.  Since
      ia64 uses 4GB for zone DMA (no ISA support), it's trivial to allocate a
      contiguous range from the slab for bounce buffer usage.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      0b9afede
  30. 28 Jun, 2005 1 commit
  31. 03 May, 2005 1 commit
  32. 25 Apr, 2005 1 commit
    • Alex Williamson's avatar
      [IA64] sba_iommu bug fixes · 5f6602a1
      Alex Williamson authored
      
      
         This fixes a couple of bugs in the zx1/sx1000 sba_iommu.  These are
      all pretty low likelihood of hitting.  The first problem is a simple off
      by one, deep in the sba_alloc_range() error path.  Surrounding that was
      a lock ordering problem that could have potentially deadlocked with the
      order the locks are grabbed in sba_unmap_single().  I moved the resource
      locking into sba_search_bitmap() to prevent this.  Finally, there's a
      potential race between unmapping pdir entries and marking incoming DMA
      pages clean.  If you see any oddities, please let me know, but I've
      tested it pretty thoroughly here.  Tony, please apply.  Thanks,
      
      BTW, many of the options in this driver not on by default are becoming
      more and more broken.  I'll be working on some patches to clean them
      out, but I wanted to get this bug fix out first.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      5f6602a1
  33. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4