1. 24 9月, 2013 4 次提交
  2. 31 7月, 2013 1 次提交
  3. 26 7月, 2013 1 次提交
  4. 18 7月, 2013 1 次提交
    • R
      ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 · 8c5bd7ad
      Rafael J. Wysocki 提交于
      According to Matthew Garrett, "Windows 8 leaves backlight control up
      to individual graphics drivers rather than making ACPI calls itself.
      There's plenty of evidence to suggest that the Intel driver for
      Windows [8] doesn't use the ACPI interface, including the fact that
      it's broken on a bunch of machines when the OS claims to support
      Windows 8.  The simplest thing to do appears to be to disable the
      ACPI backlight interface on these systems".
      
      There's a problem with that approach, however, because simply
      avoiding to register the ACPI backlight interface if the firmware
      calls _OSI for Windows 8 may not work in the following situations:
       (1) The ACPI backlight interface actually works on the given system
           and the i915 driver is not loaded (e.g. another graphics driver
           is used).
       (2) The ACPI backlight interface doesn't work on the given system,
           but there is a vendor platform driver that will register its
           own, equally broken, backlight interface if not prevented from
           doing so by the ACPI subsystem.
      Therefore we need to allow the ACPI backlight interface to be
      registered until the i915 driver is loaded which then will unregister
      it if the firmware has called _OSI for Windows 8 (or will register
      the ACPI video driver without backlight support if not already
      present).
      
      For this reason, introduce an alternative function for registering
      ACPI video, acpi_video_register_with_quirks(), that will check
      whether or not the ACPI video driver has already been registered
      and whether or not the backlight Windows 8 quirk has to be applied.
      If the quirk has to be applied, it will block the ACPI backlight
      support and either unregister the backlight interface if the ACPI
      video driver has already been registered, or register the ACPI
      video driver without the backlight interface otherwise.  Make
      the i915 driver use acpi_video_register_with_quirks() instead of
      acpi_video_register() in i915_driver_load().
      
      This change is based on earlier patches from Matthew Garrett,
      Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51231Tested-by: NAaron Lu <aaron.lu@intel.com>
      Tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Tested-by: NYves-Alexis Perez <corsac@debian.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
      8c5bd7ad
  5. 19 6月, 2013 1 次提交
  6. 17 4月, 2013 1 次提交
  7. 25 3月, 2013 1 次提交
  8. 03 3月, 2013 1 次提交
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  9. 24 2月, 2013 1 次提交
    • T
      acpi, memory-hotplug: parse SRAT before memblock is ready · e8d19552
      Tang Chen 提交于
      On linux, the pages used by kernel could not be migrated.  As a result,
      if a memory range is used by kernel, it cannot be hot-removed.  So if we
      want to hot-remove memory, we should prevent kernel from using it.
      
      The way now used to prevent this is specify a memory range by
      movablemem_map boot option and set it as ZONE_MOVABLE.
      
      But when the system is booting, memblock will allocate memory, and
      reserve the memory for kernel.  And before we parse SRAT, and know the
      node memory ranges, memblock is working.  And it may allocate memory in
      ranges to be set as ZONE_MOVABLE.  This memory can be used by kernel,
      and never be freed.
      
      So, let's parse SRAT before memblock is called first.  And it is early
      enough.
      
      The first call of memblock_find_in_range_node() is in:
      
        setup_arch()
          |-->setup_real_mode()
      
      so, this patch add a function early_parse_srat() to parse SRAT, and call
      it before setup_real_mode() is called.
      
      NOTE:
      
      1) early_parse_srat() is called before numa_init(), and has initialized
         numa_meminfo.  So DO NOT clear numa_nodes_parsed in numa_init() and DO
         NOT zero numa_meminfo in numa_init(), otherwise we will lose memory
         numa info.
      
      2) I don't know why using count of memory affinities parsed from SRAT
         as a return value in original acpi_numa_init().  So I add a static
         variable srat_mem_cnt to remember this count and use it as the return
         value of the new acpi_numa_init()
      
      [mhocko@suse.cz: parse SRAT before memblock is ready fix]
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: NWen Congyang <wency@cn.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Wu Jianguo <wujianguo@huawei.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Brown, Len" <len.brown@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8d19552
  10. 13 2月, 2013 1 次提交
  11. 20 1月, 2013 1 次提交
  12. 11 1月, 2013 1 次提交
  13. 03 1月, 2013 1 次提交
  14. 05 12月, 2012 1 次提交
  15. 26 11月, 2012 1 次提交
  16. 22 11月, 2012 1 次提交
    • T
      ACPI: Add acpi_handle_<level>() interfaces · fbfddae6
      Toshi Kani 提交于
      This patch introduces acpi_handle_<level>(), where <level> is
      a kernel message level such as err/warn/info, to support improved
      logging messages for ACPI, esp. hot-plug operations.
      acpi_handle_<level>() appends "ACPI" prefix and ACPI object path
      to the messages.  This improves diagnosis of hotplug operations
      since an error message in a log file identifies an object that
      caused an issue.  This interface acquires the global namespace
      mutex to obtain an object path.  In interrupt context, it shows
      the object path as <n/a>.
      
      acpi_handle_<level>() takes acpi_handle as an argument, which is
      passed to ACPI hotplug notify handlers from the ACPICA.  Therefore,
      it is always available unlike other kernel objects, such as device.
      
      For example:
        acpi_handle_err(handle, "Device don't exist, dropping EJECT\n");
      logs an error message like this at KERN_ERR.
        ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT
      
      ACPI hot-plug drivers can use acpi_handle_<level>() when they need
      to identify a target ACPI object path in their messages, such as
      error cases.  The usage model is similar to dev_<level>().
      acpi_handle_<level>() can be used when a device is not created or
      is invalid during hot-plug operations.  ACPI object path is also
      consistent on the platform, unlike device name that gets incremented
      over hotplug operations.
      
      ACPI drivers should use dev_<level>() when a device object is valid.
      Device name provides more user friendly information, and avoids
      acquiring the global ACPI namespace mutex.  ACPI drivers also
      continue to use pr_<level>() when they do not need to specify device
      information, such as boot-up messages.
      
      Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and
      are not associated with the kernel message level.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Tested-by: NVijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fbfddae6
  17. 15 11月, 2012 7 次提交
    • R
      ACPI / PM: Fix build problem when CONFIG_ACPI or CONFIG_PM is not set · 5133375b
      Rafael J. Wysocki 提交于
      Commit e5cc8ef3 (ACPI / PM: Provide ACPI PM callback routines for
      subsystems) introduced a build problem occuring if CONFIG_ACPI is
      unset or CONFIG_PM is unset and errno.h is not included before
      acpi.h, because in that case ENODEV used in acpi.h is undefined.
      
      Fix the issue by making acpi.h include errno.h.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5133375b
    • R
      ACPI: Centralized processing of ACPI device resources · 8e345c99
      Rafael J. Wysocki 提交于
      Currently, whoever wants to use ACPI device resources has to call
      acpi_walk_resources() to browse the buffer returned by the _CRS
      method for the given device and create filters passed to that
      routine to apply to the individual resource items.  This generally
      is cumbersome, time-consuming and inefficient.  Moreover, it may
      be problematic if resource conflicts need to be resolved, because
      the different users of _CRS will need to do that in a consistent
      way.  However, if there are resource conflicts, the ACPI core
      should be able to resolve them centrally instead of relying on
      various users of acpi_walk_resources() to handle them correctly
      together.
      
      For this reason, introduce a new function, acpi_dev_get_resources(),
      that can be used by subsystems to obtain a list of struct resource
      objects corresponding to the ACPI device resources returned by
      _CRS and, if necessary, to apply additional preprocessing routine
      to the ACPI resources before converting them to the struct resource
      format.
      
      Make the ACPI code that creates platform device objects use
      acpi_dev_get_resources() for resource processing instead of executing
      acpi_walk_resources() twice by itself, which causes it to be much
      more straightforward and easier to follow.
      
      In the future, acpi_dev_get_resources() can be extended to meet
      the needs of the ACPI PNP subsystem and other users of _CRS in
      the kernel.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      8e345c99
    • R
      ACPI: Move device resources interpretation code from PNP to ACPI core · 046d9ce6
      Rafael J. Wysocki 提交于
      Move some code used for parsing ACPI device resources from the PNP
      subsystem to the ACPI core, so that other bus types (platform, SPI,
      I2C) can use the same routines for parsing resources in a consistent
      way, without duplicating code.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      046d9ce6
    • M
      ACPI: Provide generic functions for matching ACPI device nodes · cf761af9
      Mika Westerberg 提交于
      Introduce function acpi_match_device() allowing callers to match
      struct device objects with populated acpi_handle fields against
      arrays of ACPI device IDs.  Also introduce function
      acpi_driver_match_device() using acpi_match_device() internally and
      allowing callers to match a struct device object against an array of
      ACPI device IDs provided by a device driver.
      
      Additionally, introduce macro ACPI_PTR() that may be used by device
      drivers to escape pointers to data structures whose definitions
      depend on CONFIG_ACPI.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cf761af9
    • Y
      ACPI: move acpi_no_s4_hw_signature() declaration into #ifdef CONFIG_HIBERNATION · 9743fdea
      Yuanhan Liu 提交于
      acpi_no_s4_hw_signature is defined in #ifdef CONFIG_HIBERNATION block,
      but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block.
      
      I happened to meet this issue when I turned off PM_SLEEP config manually:
      arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function ‘acpi_no_s4_hw_signature’ [-Werror=implicit-function-declaration]
      Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      Reviewed-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9743fdea
    • K
      ACPI / Sleep: add acpi_sleep=nonvs_s3 parameter · 1bad2f19
      Kristen Carlson Accardi 提交于
      The ACPI specificiation would like us to save NVS at hibernation time,
      but makes no mention of saving NVS over S3.  Not all versions of
      Windows do this either, and it is clear that not all machines need NVS
      saved/restored over S3.  Allow the user to improve their suspend/resume
      time by disabling the NVS save/restore at S3 time, but continue to do
      the NVS save/restore for S4 as specified.
      Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1bad2f19
    • R
      ACPI / PM: Provide ACPI PM callback routines for subsystems · e5cc8ef3
      Rafael J. Wysocki 提交于
      Some bus types don't support power management natively, but generally
      there may be device nodes in ACPI tables corresponding to the devices
      whose bus types they are (under ACPI 5 those bus types may be SPI,
      I2C and platform).  If that is the case, standard ACPI power
      management may be applied to those devices, although currently the
      kernel has no means for that.
      
      For this reason, provide a set of routines that may be used as power
      management callbacks for such devices.  This may be done in three
      different ways.
      
       (1) Device drivers handling the devices in question may run
           acpi_dev_pm_attach() in their .probe() routines, which (on
           success) will cause the devices to be added to the general ACPI
           PM domain and ACPI power management will be used for them going
           forward.  Then, acpi_dev_pm_detach() may be used to remove the
           devices from the general ACPI PM domain if ACPI power management
           is not necessary for them any more.
      
       (2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
           acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
           acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
           power management callbacks in the same way as the general ACPI
           PM domain does that.
      
       (3) The devices' drivers may execute acpi_dev_suspend_late(),
           acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
           acpi_dev_runtime_resume() from their power management callbacks
           as appropriate, if that's absolutely necessary, but it is not
           recommended to do that, because such drivers may not work
           without ACPI support as a result.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e5cc8ef3
  18. 06 10月, 2012 1 次提交
  19. 01 10月, 2012 2 次提交
  20. 25 9月, 2012 2 次提交
  21. 03 8月, 2012 1 次提交
  22. 28 7月, 2012 1 次提交
    • C
      acpi: add a way to promote/demote vendor backlight drivers · f838eb5b
      Corentin Chary 提交于
      Instead of adding a big blacklist in video_detect.c to set
      ACPI_VIDEO_BACKLIGHT_DMI_VENDOR correctly, let external modules
      promote or demote themselves when they know the generic video
      module won't work.
      
      Currently drivers where using acpi_video_unregister() directly
      but:
      - That didn't respect any acpi_backlight=[video|vendor] parameter
        provided by the user.
      - Any later call to acpi_video_register() would still re-load the
        generic video module (and some gpu drivers are doing that).
      
      This patch fix those two issues.
      Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      f838eb5b
  23. 04 6月, 2012 1 次提交
    • T
      ACPI: Add an interface to evaluate _OST · 275c58d7
      Toshi Kani 提交于
      Added acpi_evaluate_hotplug_opt(). All ACPI hotplug handlers must call
      this function when evaluating _OST for hotplug operations. If the
      platform does not support _OST, this function returns AE_NOT_FOUND and
      has no effect on the platform.
      
      ACPI_HOTPLUG_OST is defined when all relevant ACPI hotplug operations,
      such as CPU, memory and container hotplug, are enabled. This assures
      consistent behavior among the hotplug operations with regarding the
      _OST support. When ACPI_HOTPLUG_OST is not defined, this function is
      a no-op.
      
      ACPI PCI hotplug is not enhanced to support _OST at this time since it
      is a legacy method being replaced by PCIe native hotplug. _OST support
      for ACPI PCI hotplug may be added in future if necessary.
      
      Some platforms may require the OS to support _OST in order to support
      ACPI hotplug operations. For example, if a platform has the management
      console where user can request a hotplug operation from, this _OST
      support would be required for the management console to show the result
      of the hotplug request to user.
      
      Added macro definitions of _OST source events and status codes.
      Also renamed OSC_SB_CPUHP_OST_SUPPORT to OSC_SB_HOTPLUG_OST_SUPPORT
      since this _OSC bit is not specific to CPU hotplug. This bit is
      defined in Table 6-147 of ACPI 5.0 as follows.
      
        Bits:       3
        Field Name: Insertion / Ejection _OST Processing Support
        Definition: This bit is set if OSPM will evaluate the _OST
                    object defined under a device when processing
                    insertion and ejection source event codes.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      275c58d7
  24. 21 3月, 2012 1 次提交
  25. 14 3月, 2012 1 次提交
  26. 17 1月, 2012 1 次提交
    • H
      ACPI, Record ACPI NVS regions · b54ac6d2
      Huang Ying 提交于
      Some firmware will access memory in ACPI NVS region via APEI.  That
      is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
      region.  The original resource conflict checking in APEI code will
      check memory/ioport accessed by APEI via general resource management
      mechanism.  But ACPI NVS region is marked as busy already, so that the
      false resource conflict will prevent APEI ERST/EINJ to work.
      
      To fix this, this patch record ACPI NVS regions, so that we can avoid
      request resources for memory region inside it.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b54ac6d2
  27. 06 12月, 2011 1 次提交
    • R
      PCI/ACPI: Make acpiphp ignore root bridges using SHPC native hotplug · d90116ea
      Rafael J. Wysocki 提交于
      If the kernel has requested control of the SHPC native hotplug
      feature for a given root bridge, the acpiphp driver should not try
      to handle that root bridge and it should leave it to shpchp.
      Failing to do so causes problems to happen if shpchp is loaded
      and unloaded before loading acpiphp (ACPI-based hotplug won't work
      in that case anyway).
      
      To address this issue make find_root_bridges() ignore PCI root
      bridges with SHPC native hotplug enabled and make add_bridge()
      return error code if SHPC native hotplug is enabled for the given
      root bridge.  This causes acpiphp to refuse to load if SHPC native
      hotplug is enabled for all root bridges and to refuse binding to
      the root bridges with SHPC native hotplug enabled.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d90116ea
  28. 03 8月, 2011 1 次提交
  29. 14 7月, 2011 1 次提交
    • H
      ACPI, APEI, Add APEI bit support in generic _OSC call · eccddd32
      Huang Ying 提交于
      In APEI firmware first mode, hardware error is reported by hardware to
      firmware firstly, then firmware reports the error to Linux in a GHES
      error record via POLL/SCI/IRQ/NMI etc.
      
      This may result in some issues if OS has no full APEI support.  So
      some firmware implementation will work in a back-compatible mode by
      default.  Where firmware will only notify OS in old-fashion, without
      GHES record.  For example, for a fatal hardware error, only NMI is
      signaled, no GHES record.
      
      To gain full APEI power on these machines, APEI bit in generic _OSC
      call can be specified to tell firmware that Linux has full APEI
      support.  This patch adds the APEI bit support in generic _OSC call.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      eccddd32