1. 05 11月, 2014 3 次提交
  2. 21 10月, 2014 4 次提交
  3. 10 10月, 2014 1 次提交
  4. 01 10月, 2014 1 次提交
  5. 21 9月, 2014 1 次提交
    • R
      ACPI / hotplug: Generate online uevents for ACPI containers · 8ab17fc9
      Rafael J. Wysocki 提交于
      Commit 46394fd0 (ACPI / hotplug: Move container-specific code out of
      the core) removed the generation of "online" uevents for containers,
      because "add" uevents are now generated for them automatically when
      container system devices are registered.  However, there are user
      space tools that need to be notified when the container and all of
      its children have been enumerated, which doesn't happen any more.
      
      For this reason, add a mechanism allowing "online" uevents to be
      generated for ACPI containers after enumerating the container along
      with all of its children.
      
      Fixes: 46394fd0 (ACPI / hotplug: Move container-specific code out of the core)
      Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8ab17fc9
  6. 16 9月, 2014 1 次提交
  7. 04 9月, 2014 1 次提交
  8. 03 9月, 2014 4 次提交
  9. 31 7月, 2014 10 次提交
  10. 24 7月, 2014 1 次提交
  11. 23 7月, 2014 7 次提交
    • L
      ACPI: Add support to force header inclusion rules for <acpi/acpi.h>. · 417b4a73
      Lv Zheng 提交于
      As there is only CONFIG_ACPI=n processing in the <linux/acpi.h>, it is not
      safe to include <acpi/acpi.h> directly for source out of Linux ACPI
      subsystems.
      
      This patch adds error messaging to warn developers of such wrong
      inclusions.
      
      In order not to be bisected and reverted as a wrong commit, warning
      messages are carefully split into a seperate patch other than the wrong
      inclusion cleanups.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      417b4a73
    • L
      ACPICA: Linux: Add support to exclude <asm/acenv.h> inclusion. · d334c823
      Lv Zheng 提交于
      The forthcoming patch will make <acpi/acpi.h> to be visible to all kernel
      source code. Thus for the architectures that do not support ACPI and
      haven't implemented <asm/acenv.h>, we need to make it excluded.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d334c823
    • L
      ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics. · daba25d6
      Lv Zheng 提交于
      This patch adds default 64-bit mathematics in aclinux.h using do_div(). As
      do_div() can be used for all Linux architectures, this can also be used as
      stub macros for ACPICA 64-bit mathematics.
      
      These macros are required by drivers/acpi/utmath.c when ACPI_USE_NATIVE_DIVIDE
      is not defined.  It is used by ACPICA, so currently this is only meaningful to
      CONFIG_ACPI builds.  So the kernel will not use these macros unless CONFIG_ACPI
      is defined and ACPI_USE_DIVIDE is not defined.
      
      For 64-bit kernels:
      In include/acpi/actypes.h, for ACPI_MACHINE_WIDTH=64,
      ACPI_USE_NATIVE_DIVIDE will be defined, thus these macros are not used.
      In include/acpi/platform/aclinux.h, for __KERNEL__ surrounded code,
      ACPI_MACHINE_WIDTH is defined to be BITS_PER_LONG.
      So all 64-bit kernels do not use these macros.
      
      For 32-bit kernels:
      As mentioned above, these macros will be used when BITS_PER_LONG is 32.
      Thus currently the i328 kernels are the only users for these macros.
      But they won't use this default implementation provided by this patch,
      because in arch/x86/include/asm/acenv.h, there are already overrides
      implemented.  So these default macros are not used by 32-bit x86 (i386)
      kernels.
      
      These macros will only be used by future non x86 32-bit architectures
      that try to support ACPI in Linux kernel.
      
      During the period they do not have arch specific implementations of such
      macros, we can avoid build errors for them.
      
      And since they can see ACPICA functioning without implementing any arch
      specific environment tunings, we  can also avoid function errors for
      them.
      
      As this implementation is not performance friendly, those architectures
      still need to implement real support in the end.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      [rjw: Changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      daba25d6
    • R
      ACPI / PM: Always enable wakeup GPEs when enabling device wakeup · f35cec25
      Rafael J. Wysocki 提交于
      Wakeup GPEs are currently only enabled when setting up devices for
      remote wakeup at run time.  During system-wide transitions they are
      enabled by ACPICA at the very last stage of suspend (before asking
      the BIOS to take over).  Of course, that only works for system
      sleep states supported by ACPI, so in particular it doesn't work
      for the "freeze" sleep state.
      
      For this reason, modify the ACPI core device PM code to enable wakeup
      GPEs for devices when setting them up for wakeup regardless of whether
      that is remote wakeup at runtime or system wakeup.  That allows the
      same device wakeup setup routine to be used for both runtime PM and
      system-wide PM and makes it possible to reduce code size quite a bit.
      
      This make ACPI-based PCI Wake-on-LAN work with the "freeze" sleep
      state on my venerable Toshiba Portege R500 and should help other
      systems too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f35cec25
    • R
      ACPI / PM: Revork the handling of ACPI device wakeup notifications · c072530f
      Rafael J. Wysocki 提交于
      Since ACPI wakeup GPEs are going to be enabled during system suspend
      as well as for runtime wakeup by a subsequent patch and the same
      notify handlers will be used in both cases, rework the ACPI device
      wakeup notification framework so that the part specific to physical
      devices is always run asynchronously from the PM workqueue.  This
      prevents runtime resume callbacks for those devices from being
      run during system suspend and resume which may not be appropriate,
      among other things.
      
      Also make ACPI device wakeup notification handling a bit more robust
      agaist subsequent removal of ACPI device objects, whould that ever
      happen, and create a wakeup source object for each ACPI device
      configured for wakeup so that wakeup notifications for those
      devices can wake up the system from the "freeze" sleep state.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c072530f
    • T
      acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context. · 594c7255
      Tomasz Nowicki 提交于
      GHES currently maps two pages with atomic_ioremap.  From now
      on, NMI is architectural depended so there is no need to allocate
      an NMI page for platforms without NMI support.
      
      To make it possible to not use a second page, swap the existing
      page order so that the IRQ context page is first, and the optional
      NMI context page is second.  Then, use HAVE_ACPI_APEI_NMI to decide
      how many pages are to be allocated.
      Signed-off-by: NTomasz Nowicki <tomasz.nowicki@linaro.org>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      594c7255
    • T
      apei, mce: Factor out APEI architecture specific MCE calls. · 9dae3d0d
      Tomasz Nowicki 提交于
      This commit abstracts MCE calls and provides weak corresponding default
      implementation for those architectures which do not need arch specific
      actions. Each platform willing to do additional architectural actions
      should provides desired function definition. It allows us to avoid wrap
      code into #ifdef in generic code and prevent new platform from introducing
      dummy stub function too.
      
      Initially, there are two APEI arch-specific calls:
      - arch_apei_enable_cmcff()
      - arch_apei_report_mem_error()
      Both interact with MCE driver for X86 architecture.
      Signed-off-by: NTomasz Nowicki <tomasz.nowicki@linaro.org>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      9dae3d0d
  12. 20 7月, 2014 1 次提交
  13. 16 7月, 2014 1 次提交
  14. 08 7月, 2014 4 次提交