1. 10 12月, 2013 1 次提交
  2. 15 11月, 2013 1 次提交
    • R
      ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node · 7b199811
      Rafael J. Wysocki 提交于
      Modify struct acpi_dev_node to contain a pointer to struct acpi_device
      associated with the given device object (that is, its ACPI companion
      device) instead of an ACPI handle corresponding to it.  Introduce two
      new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
      ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
      ACPI_HANDLE() macro to take the above changes into account.
      Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
      use ACPI_COMPANION_SET() instead.  For some of them who used to
      pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
      introduce a helper routine acpi_preset_companion() doing an
      equivalent thing.
      
      The main motivation for doing this is that there are things
      represented by struct acpi_device objects that don't have valid
      ACPI handles (so called fixed ACPI hardware features, such as
      power and sleep buttons) and we would like to create platform
      device objects for them and "glue" them to their ACPI companions
      in the usual way (which currently is impossible due to the
      lack of valid ACPI handles).  However, there are more reasons
      why it may be useful.
      
      First, struct acpi_device pointers allow of much better type checking
      than void pointers which are ACPI handles, so it should be more
      difficult to write buggy code using modified struct acpi_dev_node
      and the new macros.  Second, the change should help to reduce (over
      time) the number of places in which the result of ACPI_HANDLE() is
      passed to acpi_bus_get_device() in order to obtain a pointer to the
      struct acpi_device associated with the given "physical" device,
      because now that pointer is returned by ACPI_COMPANION() directly.
      Finally, the change should make it easier to write generic code that
      will build both for CONFIG_ACPI set and unset without adding explicit
      compiler directives to it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
      7b199811
  3. 20 6月, 2013 1 次提交
    • R
      ACPI / ia64 / sba_iommu: Use ACPI scan handler for device discovery · 66345d5f
      Rafael J. Wysocki 提交于
      The IA64 System Bus Adapter (SBA) I/O MMU driver uses an ACPI driver
      object to look for device objects it needs in the ACPI namespace, but
      that leads to an ordering issue between that driver and the container
      scan handler on ia64 HP rx2600.
      
      Namely, on that machine the SBA I/O MMU device object in the ACPI
      namespace has a _HID returning its own specific device ID and a
      _CID returning a generic container device ID.  According to Toshi
      Kani, the idea is that if a _HID is not mached by an I/O MMU driver,
      the _CID should be matched by a generic container driver, so those
      device IDs should be used mutually exclusively.
      
      That is not what happens, however, because the container driver uses
      an ACPI scan handler which is matched against the device object in
      question before registering the SBA I/O MMU driver object.  As a
      result, that scan handler claims the device object first.  The driver
      binds to the same device object later, however, and they both happily
      use it simultaneously going forward (fortunately, that doesn't cause
      any real breakage to happen).
      
      To avoid that ordering issue, make the SBA I/O MMU code use an ACPI
      scan handler instead of an ACPI driver, so that it can claim the SBA
      I/O MMU device object before the container driver (thanks to an
      improved algorithm of matching ACPI device IDs used for ACPI scan
      handlers, which matches device _HIDs against the registered scan
      handlers before _CIDs).
      
      This also reduces the kernel's memory footprint slightly by
      avoiding to register a driver object that's not used after system
      initialization, so having it registered (and present in sysfs)
      throughout the system's life time isn't particularly useful.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NTony Luck <tony.luck@gmail.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      66345d5f
  4. 29 3月, 2012 1 次提交
  5. 28 3月, 2012 1 次提交
  6. 28 9月, 2011 1 次提交
    • P
      doc: fix broken references · 395cf969
      Paul Bolle 提交于
      There are numerous broken references to Documentation files (in other
      Documentation files, in comments, etc.). These broken references are
      caused by typo's in the references, and by renames or removals of the
      Documentation files. Some broken references are simply odd.
      
      Fix these broken references, sometimes by dropping the irrelevant text
      they were part of.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      395cf969
  7. 21 5月, 2011 1 次提交
    • L
      sanitize <linux/prefetch.h> usage · 268bb0ce
      Linus Torvalds 提交于
      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: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      268bb0ce
  8. 10 5月, 2011 1 次提交
  9. 19 5月, 2010 1 次提交
  10. 15 12月, 2009 1 次提交
  11. 04 12月, 2009 1 次提交
  12. 27 8月, 2009 1 次提交
    • B
      ACPICA: Major update for acpi_get_object_info external interface · 15b8dd53
      Bob Moore 提交于
      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: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      15b8dd53
  13. 18 6月, 2009 1 次提交
    • M
      [IA64] Convert ia64 to use int-ll64.h · e088a4ad
      Matthew Wilcox 提交于
      It is generally agreed that it would be beneficial for u64 to be an
      unsigned long long on all architectures.  ia64 (in common with several
      other 64-bit architectures) currently uses unsigned long.  Migrating
      piecemeal is too painful; this giant patch fixes all compilation warnings
      and errors that come as a result of switching to use int-ll64.h.
      
      Note that userspace will still see __u64 defined as unsigned long.  This
      is important as it affects C++ name mangling.
      
      [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
       u64 for start/end rather than unsigned long]
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e088a4ad
  14. 17 6月, 2009 1 次提交
  15. 30 1月, 2009 1 次提交
  16. 06 1月, 2009 4 次提交
  17. 20 10月, 2008 1 次提交
  18. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      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: NFUJITA 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  19. 29 4月, 2008 2 次提交
  20. 10 4月, 2008 1 次提交
  21. 07 3月, 2008 1 次提交
  22. 06 2月, 2008 1 次提交
  23. 05 2月, 2008 1 次提交
  24. 20 12月, 2007 1 次提交
  25. 23 10月, 2007 1 次提交
  26. 17 10月, 2007 1 次提交
  27. 16 10月, 2007 1 次提交
  28. 28 7月, 2007 1 次提交
  29. 14 7月, 2007 1 次提交
    • T
      [IA64] use machvec=dig on hpzx1 platforms · 51b58e3e
      Terry Loftin 提交于
      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: NTerry Loftin <terry.loftin@hp.com>
      Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      51b58e3e
  30. 13 2月, 2007 1 次提交
  31. 08 12月, 2006 1 次提交
  32. 30 11月, 2006 1 次提交
  33. 01 7月, 2006 1 次提交
  34. 23 6月, 2006 1 次提交
  35. 02 4月, 2006 1 次提交
    • L
      ACPI: ia64 buildfix · 144c87b4
      Len Brown 提交于
      arch/ia64/hp/common/sba_iommu.c used ACPI_MEM_FREE instead of kfree()
      
      Signed-off-by: Len Brown <len.brown@intel.com
      144c87b4
  36. 28 10月, 2005 1 次提交