1. 05 2月, 2015 9 次提交
  2. 26 1月, 2015 2 次提交
  3. 22 1月, 2015 1 次提交
  4. 03 12月, 2014 1 次提交
  5. 02 12月, 2014 1 次提交
    • R
      ACPICA: Save current masks of enabled GPEs after enable register writes · c50f13c6
      Rafael J. Wysocki 提交于
      There is a race condition between acpi_hw_disable_all_gpes() or
      acpi_enable_all_wakeup_gpes() and acpi_ev_asynch_enable_gpe() such
      that if the latter wins the race, it may mistakenly enable a GPE
      disabled by the former.  This may lead to premature system wakeups
      during system suspend and potentially to more serious consequences.
      
      The source of the problem is how acpi_hw_low_set_gpe() works when
      passed ACPI_GPE_CONDITIONAL_ENABLE as the second argument.  In that
      case, the GPE will be enabled if the corresponding bit is set in the
      enable_for_run mask of the GPE enable register containing that bit.
      However, acpi_hw_disable_all_gpes() and acpi_enable_all_wakeup_gpes()
      don't modify the enable_for_run masks of GPE registers when writing
      to them.  In consequence, if acpi_ev_asynch_enable_gpe(), which
      eventually calls acpi_hw_low_set_gpe() with the second argument
      equal to ACPI_GPE_CONDITIONAL_ENABLE, is executed in parallel with
      one of these functions, it may reverse changes made by them.
      
      To fix the problem, introduce a new enable_mask field in struct
      acpi_gpe_register_info in which to store the current mask of
      enabled GPEs and modify acpi_hw_low_set_gpe() to take this
      mask into account instead of enable_for_run when its second
      argument is equal to ACPI_GPE_CONDITIONAL_ENABLE.  Also modify
      the low-level routines called by acpi_hw_disable_all_gpes(),
      acpi_enable_all_wakeup_gpes() and acpi_enable_all_runtime_gpes()
      to update the enable_mask masks of GPE registers after all
      (successful) writes to those registers.
      Acked-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c50f13c6
  6. 28 11月, 2014 5 次提交
  7. 21 10月, 2014 7 次提交
  8. 01 10月, 2014 2 次提交
  9. 25 9月, 2014 1 次提交
    • B
      ACPICA: Update to GPIO region handler interface. · 75ec6e55
      Bob Moore 提交于
      Changes to correct several GPIO issues:
      
      1) The update_rule in a GPIO field definition is now ignored;
      a read-modify-write operation is never performed for GPIO fields.
      (Internally, this means that the field assembly/disassembly
      code is completely bypassed for GPIO.)
      
      2) The Address parameter passed to a GPIO region handler is
      now the bit offset of the field from a previous Connection()
      operator. Thus, it becomes a "Pin Number Index" into the
      Connection() resource descriptor.
      
      3) The bit_width parameter passed to a GPIO region handler is
      now the exact bit width of the GPIO field. Thus, it can be
      interpreted as "number of pins".
      
      Overall, we can now say that the region handler interface
      to GPIO handlers is a raw "bit/pin" addressed interface, not
      a byte-addressed interface like the system_memory handler interface.
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75ec6e55
  10. 03 9月, 2014 1 次提交
  11. 02 9月, 2014 1 次提交
  12. 31 7月, 2014 9 次提交