1. 10 10月, 2014 1 次提交
  2. 31 7月, 2014 10 次提交
  3. 24 7月, 2014 1 次提交
  4. 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
  5. 20 7月, 2014 1 次提交
  6. 16 7月, 2014 1 次提交
  7. 08 7月, 2014 9 次提交
  8. 07 7月, 2014 1 次提交
    • Z
      ACPI / PNP: do ACPI binding directly · f1b1dc84
      Zhang Rui 提交于
      PNPACPI uses acpi_bus_type to do ACPI binding for the PNPACPI devices.
      
      This is overkill because PNPACPI code already knows which ACPI
      device object to bind during PNPACPI device enumeration.
      
      This patch removes acpi_pnp_bus and does the binding by invoking
      acpi_bind_one() directly after device enumerated.
      
      This also fixes a bug in the previous code that some PNPACPI devices failed
      to be bound because
       1. the ACPI device _HID is not pnpid, e.g. "MSFT0001", but its _CID is,
          e.g. "PNP0303", thus ACPI _CID is used as the pnp device device id.
       2. device is bound only if the pnp device id matches the ACPI device _HID.
      Tested-by: NPrigent Christophe <christophe.prigent@intel.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f1b1dc84
  9. 17 6月, 2014 2 次提交
  10. 03 6月, 2014 1 次提交
  11. 01 6月, 2014 1 次提交
    • L
      ACPICA: Tables: Add mechanism to control early table checksum verification. · 47d68c7f
      Lv Zheng 提交于
      It is reported that Linux x86 kernel cannot map large tables. The following
      large SSDT table on such platform fails to pass checksum verification and
      cannot be installed:
       ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
      
      It sounds strange that in the 64-bit virtual memory address space, we
      cannot map a single ACPI table to do checksum verification. The root cause
      is:
       1. ACPICA doesn't split IO memory mapping and table mapping;
       2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
          mechanism during early boot stage, which is more suitable for only IO
          mappings.
      
      ACPICA originally only mapped table header for signature validation, and
      this header mapping is required by OSL override mechanism. There was no
      checksum verification because we could not map the whole table using this
      OSL. While the following ACPICA commit enforces checksum verification by
      mapping the whole table during Linux boot stage and it finally triggers
      this issue on some platforms:
       Commit: 86dfc6f3
       Subject: ACPICA: Tables: Fix table checksums verification before installation.
      
      Before doing further cleanups for the OSL table mapping and override
      implementation, this patch introduces an option for such OSPMs to
      temporarily discard the checksum verification feature. It then can be
      re-enabled easily when the ACPICA and the underlying OSL is ready.
      
      This patch also deletes a comment around the limitation of mappings because
      it is not correct. The limitation is not how many times we can map in the
      early stage, but the OSL mapping facility may not be suitable for mapping
      the ACPI tables and thus may complain us the size limitation.
      
      The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the
      work around added, it now only applies to the table descriptor that hasn't
      been installed and cannot be used in other cases. Lv Zheng.
      Tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      47d68c7f
  12. 30 5月, 2014 2 次提交
  13. 28 5月, 2014 3 次提交
    • L
      ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem. · a238317c
      Lv Zheng 提交于
      ACPICA doesn't include protections around address space checking, Linux
      build tests always complain increased sparse warnings around ACPICA
      internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
      this issue permanently.
      
      There are 2 choices left for us to solve this issue:
       1. Add __iomem address space awareness into ACPICA.
       2. Remove sparse checker of __iomem from ACPICA source code.
      
      This patch chooses solution 2, because:
       1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
           table mappings, which in fact are not IO addresses.
       2.  The only IO addresses usage is for "system memory space" mapping code in:
            drivers/acpi/acpica/exregion.c
            drivers/acpi/acpica/evrgnini.c
            drivers/acpi/acpica/exregion.c
          The mapped address is accessed in the handler of "system memory space"
          - acpi_ex_system_memory_space_handler().  This function in fact can be
          changed to invoke acpi_os_read/write_memory() so that __iomem can
          always be type-casted in the OSL layer.
      
      According to the above investigation, we drew the following conclusion:
      It is not a good idea to introduce __iomem address space awareness into
      ACPICA mostly in order to protect non-IO addresses.
      
      We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
      __iomem checker for ACPICA code. Then we need to enforce external usages
      to invoke other APIs that are aware of __iomem address space.
      The external usages are:
       drivers/acpi/apei/einj.c
       drivers/acpi/acpi_extlog.c
       drivers/char/tpm/tpm_acpi.c
       drivers/acpi/nvs.c
      
      This patch thus performs cleanups in this way:
       1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
       2. Remove __iomem from acpi_os_map/unmap_memory().
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a238317c
    • L
      ACPICA: Clean up redudant definitions already defined elsewhere · 92985ef1
      Lv Zheng 提交于
      Since mis-order issues have been solved, we can cleanup redundant
      definitions that already have defaults in <acpi/platform/acenv.h>.
      
      This patch removes redudant environments for __KERNEL__ surrounded code.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      92985ef1
    • L
      ACPICA: Linux headers: Add <asm/acenv.h> to remove mis-ordered inclusion of <asm/acpi.h> · 07d83914
      Lv Zheng 提交于
      There is a mis-order inclusion for <asm/acpi.h>.
      
      As we will enforce including <linux/acpi.h> for all Linux ACPI users, we
      can find the inclusion order is as follows:
      
      <linux/acpi.h>
        <acpi/acpi.h>
         <acpi/platform/acenv.h>
          (acenv.h before including aclinux.h)
          <acpi/platform/aclinux.h>
      ...........................................................................
           (aclinux.h before including asm/acpi.h)
           <asm/acpi.h>                             @Redundant@
            (ACPICA specific stuff)
      ...........................................................................
      ...........................................................................
            (Linux ACPI specific stuff) ? - - - - - - - - - - - - +
           (aclinux.h after including asm/acpi.h)   @Invisible@   |
          (acenv.h after including aclinux.h)       @Invisible@   |
         other ACPICA headers                       @Invisible@   |
      ............................................................|..............
        <acpi/acpi_bus.h>                                         |
        <acpi/acpi_drivers.h>                                     |
        <asm/acpi.h> (Excluded)                                   |
         (Linux ACPI specific stuff) ! <- - - - - - - - - - - - - +
      
      NOTE that, in ACPICA, <acpi/platform/acenv.h> is more like Kconfig
      generated <generated/autoconf.h> for Linux, it is meant to be included
      before including any ACPICA code.
      
      In the above figure, there is a question mark for "Linux ACPI specific
      stuff" in <asm/acpi.h> which should be included after including all other
      ACPICA header files.  Thus they really need to be moved to the position
      marked with exclaimation mark or the definitions in the blocks marked with
      "@Invisible@" will be invisible to such architecture specific "Linux ACPI
      specific stuff" header blocks.  This leaves 2 issues:
      1. All environmental definitions in these blocks should have a copy in the
         area marked with "@Redundant@" if they are required by the "Linux ACPI
         specific stuff".
      2. We cannot use any ACPICA defined types in <asm/acpi.h>.
      
      This patch splits architecture specific ACPICA stuff from <asm/acpi.h> to
      fix this issue.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      07d83914