1. 27 5月, 2014 1 次提交
  2. 20 5月, 2014 1 次提交
  3. 07 5月, 2014 1 次提交
  4. 26 3月, 2014 2 次提交
  5. 20 3月, 2014 1 次提交
  6. 18 3月, 2014 2 次提交
  7. 05 3月, 2014 1 次提交
  8. 27 2月, 2014 1 次提交
  9. 22 2月, 2014 3 次提交
  10. 21 2月, 2014 4 次提交
  11. 16 2月, 2014 1 次提交
    • R
      ACPI / dock: Dispatch dock notifications from the global notify handler · 1e2380cd
      Rafael J. Wysocki 提交于
      The ACPI dock station code carries out an extra namespace scan
      before the main one in order to find and register all of the dock
      device objects.  Then, it registers a notify handler for each of
      them for handling dock events.
      
      However, dock device objects need not be scanned for upfront.  They
      very well can be enumerated and registered during the first phase
      of the main namespace scan, before attaching scan handlers and ACPI
      drivers to ACPI device objects.  Then, the dependent devices can be
      added to the in the second phase.  That makes it possible to drop
      the extra namespace scan, so do it.
      
      Moreover, it is not necessary to register notify handlers for all
      of the dock stations' namespace nodes, becuase notifications may
      be dispatched from the global notify handler for them.  Do that and
      drop two functions used for dock notify handling, acpi_dock_deferred_cb()
      and dock_notify_handler(), that aren't necessary any more.
      
      Finally, some dock station objects have _HID objects matching the
      ACPI container scan handler which causes it to claim those objects
      and try to handle their hotplug, but that is not a good idea,
      because those objects have their own special hotplug handling anyway.
      For this reason, the hotplug_notify flag should not be set for ACPI
      device objects representing dock stations and the container scan
      handler should be made ignore those objects, so make that happen.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e2380cd
  12. 13 2月, 2014 2 次提交
    • L
      ACPICA: acpidump: Remove integer types translation protection. · e252652f
      Lv Zheng 提交于
      Remove translation protection for applications as Linux tools folder will
      start to use such types.
      
      In Linux kernel source tree, after removing this translation protection,
      the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds
      and !__KERNEL__ builds (tools/power/acpi) and the original definitions of
      ACPI_UINT8/16/32/64_MAX are changed.
      
      For !__KERNEL__ builds, this kind of defintions should already been tested
      by the distribution vendors that are distributing binary ACPICA package and
      we've achieved the successful built/run test result in the kernel source
      tree.
      
      For __KERNEL__ builds, there are 2 things affected:
      1. u8/u16/u32/u64/s32/s64 type definitions:
         Since Linux has already type defined u8/u16/u32/u64/s32/s64 in
         include/uapi/asm-generic/int-ll64.h for __KERNEL__.  In order not to
         introduce build regressions where the 2 typedefs are differed,
         ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs.
         It must be defined for Linux __KERNEL__ builds.
      2. ACPI_UINT8/16/32/64_MAX definitions:
         Before applying this change:
           ACPI_UINT8_MAX: sizeof (UINT8)
            UINT8: unsigned char
           ACPI_UINT16_MAX: sizeof (UINT16)
            UINT16: unsigned short
           ACPI_UINT32_MAX: sizeof (UINT32)
            INT32: int
            UINT32: unsigned int
           ACPI_UINT64_MAX: sizeof (UINT64)
            INT64: COMPILER_DEPENDENT_INT64
             COMPILER_DEPENDENT_INT64: signed long (IA64) or
                                       signed long long (IA32)
            UINT64: COMPILER_DEPENDENT_UINT64
             COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or
                                        unsigned long long (IA32)
         After applying this change:
           ACPI_UINT8_MAX: sizeof (u8)
            u8: unsigned char
            UINT8: (removed from actypes.h)
           ACPI_UINT16_MAX: sizeof (u16)
            u16: unsigned short
            UINT16: (removed from actypes.h)
           ACPI_UINT32_MAX: sizeof (u32)
            INT32/UINT32: (removed from actypes.h)
            s32: signed int
            u32: unsigned int
           ACPI_UINT64_MAX: sizeof (u64)
            INT64/UINT64: (removed from actypes.h)
            u64: unsigned long long
            s64: signed long long
            COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more)
                                      signed long long (IA32) (not used any more)
            COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more)
                                       unsigned long long (IA32) (not used any more)
         All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64.  It
         is changed from sizeof(unsigned long) to sizeof(unsigned long long).
         By investigation, 64bit Linux kernel build is LP64 compliant, i.e.,
         sizeof(long) and (pointer) are 64.  As sizeof(unsigned long) equals to
         sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be
         disabled, this change actually will not affect the value of
         ACPI_UINT64_MAX on IA64 platforms.
      
      This patch is necessary for the ACPICA's acpidump tool to build
      correctly.  Lv Zheng.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e252652f
    • L
      ACPICA: acpidump: Add sparse declarators support. · 7e66b46b
      Lv Zheng 提交于
      Linux kernel resident ACPICA headers include some sparse declarators for
      kernel static checkers.  This patch adds code to disable them for non
      __KERNEL__ defined code so that it is possible for the ACPICA user space
      tool's source files to be built with Linux kernel ACPICA header files
      included.  Lv Zheng.
      
      Linux kernel build is not affected by this commit.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7e66b46b
  13. 11 2月, 2014 4 次提交
  14. 07 2月, 2014 3 次提交
    • R
      ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify() · 1a699476
      Rafael J. Wysocki 提交于
      Since acpi_bus_notify() is executed on all notifications for all
      devices anyway, make it execute acpi_device_hotplug() for all
      hotplug events instead of installing notify handlers pointing to
      the same function for all hotplug devices.
      
      This change reduces both the size and complexity of ACPI-based device
      hotplug code.  Moreover, since acpi_device_hotplug() only does
      significant things for devices that have either an ACPI scan handler,
      or a hotplug context with .eject() defined, and those devices
      had notify handlers pointing to acpi_hotplug_notify_cb() installed
      before anyway, this modification shouldn't change functionality.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1a699476
    • R
      ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler() · 5e6f236c
      Rafael J. Wysocki 提交于
      Since acpi_hotplug_notify_cb() does not use its data argument any
      more, the second argument of acpi_install_hotplug_notify_handler()
      can be dropped, so do that and update its callers accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5e6f236c
    • R
      ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug · 3c2cc7ff
      Rafael J. Wysocki 提交于
      The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
      hotplug context objects directly to ACPI namespace nodes representing
      hotplug devices.  However, after recent changes causing struct
      acpi_device to be created for every namespace node representing a
      device (regardless of its status), that is not necessary any more.
      Moreover, it's vulnerable to the theoretical issue that the ACPI
      handle passed in the context between handle_hotplug_event() and
      hotplug_event_work() may become invalid in the meantime (as a
      result of a concurrent table unload).
      
      In principle, this issue might be addressed by adding a non-empty
      release handler for ACPIPHP hotplug context objects analogous to
      acpi_scan_drop_device(), but that would duplicate the code in that
      function and in acpi_device_del_work_fn().  For this reason, it's
      better to modify ACPIPHP to attach its device hotplug contexts to
      struct device objects representing hotplug devices and make it
      use acpi_hotplug_notify_cb() as its notify handler.  At the same
      time, acpi_device_hotplug() can be modified to dispatch the new
      .hp.event() callback pointing to acpiphp_hotplug_event() from ACPI
      device objects associated with PCI devices or use the generic
      ACPI device hotplug code for device objects with matching scan
      handlers.
      
      This allows the existing code duplication between ACPIPHP and the
      ACPI core to be reduced too and makes further ACPI-based device
      hotplug consolidation possible.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3c2cc7ff
  15. 06 2月, 2014 3 次提交
    • R
      ACPI / hotplug / PCI: Define hotplug context lock in the core · e525506f
      Rafael J. Wysocki 提交于
      Subsequent changes will require the ACPI core to acquire the lock
      protecting the ACPIPHP hotplug contexts, so move the definition of
      the lock to the core and change its name to be more generic.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      e525506f
    • R
      ACPI / hotplug: Fix potential race in acpi_bus_notify() · 78ea4639
      Rafael J. Wysocki 提交于
      There is a slight possibility for the ACPI device object pointed to
      by adev in acpi_hotplug_notify_cb() to become invalid between the
      acpi_bus_get_device() that it comes from and the subsequent dereference
      of that pointer under get_device().  Namely, if acpi_scan_drop_device()
      runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
      queued up by it may delete the device object in question right after
      a successful execution of acpi_bus_get_device() in acpi_bus_notify().
      
      An analogous problem is present in acpi_bus_notify() where the device
      pointer coming from acpi_bus_get_device() may become invalid before
      it subsequent dereference in the "if" block.
      
      To prevent that from happening, introduce a new function,
      acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
      except that it will grab a reference to the ACPI device object returned
      by it and it will do that under the ACPICA's namespace mutex.  Then,
      make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
      acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
      ensure that the pointers used by them will not become stale at one
      point.
      
      In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
      around put_device() to be used along with acpi_bus_get_acpi_device()
      and make the (new) users of the latter use acpi_bus_put_acpi_device()
      too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      78ea4639
    • R
      ACPICA: Introduce acpi_get_data_full() and rework acpi_get_data() · 7c2e1771
      Rafael J. Wysocki 提交于
      Introduce a new function, acpi_get_data_full(), working in analogy
      with acpi_get_data() except that it can execute a callback provided
      as its 4th argument right after acpi_ns_get_attached_data() has
      returned a success.
      
      That will allow Linux to reference count the object pointed to by
      *data before the namespace mutex is released so as to ensure that it
      will not be freed going forward until the reference to it acquired
      by acpi_get_data_full() is dropped.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      7c2e1771
  16. 05 2月, 2014 1 次提交
    • A
      ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY · af1ae78a
      Al Stone 提交于
      ACPI hardware reduced mode exists to allow newer platforms to use a
      simpler form of ACPI that does not require supporting legacy versions
      of the specification and their associated hardware.  This mode was
      introduced in the ACPI 5.0 specification.
      
      The ACPI hardware reduced mode is supposed to be used on systems
      having the HW_REDUCED_ACPI flag set in the FADT.  ACPICA checks
      that flag to determine whether or not it should work in the HW
      reduced mode and there are pieces of code in it that will never
      be used in that case.
      
      Since some architecutres will always use the ACPI HW reduced mode,
      it doesn't make sense for them to ever compile support for anything
      else.  Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE
      in the ACPICA source.  To enable them to do that, introduce a new
      kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that
      will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when
      set.
      
      Introducing this configuration item is based on suggestions from Lv
      Zheng saying that this does not belong in ACPICA, but rather to the
      Linux kernel itself.
      
      References: http://www.spinics.net/lists/linux-acpi/msg46369.htmlSigned-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NAl Stone <al.stone@linaro.org>
      [rjw: Subject and changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af1ae78a
  17. 04 2月, 2014 1 次提交
  18. 28 1月, 2014 1 次提交
  19. 14 1月, 2014 1 次提交
  20. 08 1月, 2014 6 次提交