ACPI spec states that the OS evaluates _STA after calling _EJ0
in order to verify if eject was successful. Added a check to
verify if the enabled bit of the status value is cleared after
_EJ0.
Note, the present bit is not checked since some FW implementations
do not clear the present bit until the hardware is physically
removed.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use the resource_size() function instead of explicit computation.
[rjw: Subject and changelog]
Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes following compiler warning when build via make W=1:
drivers/acpi/container.c:183:116: warning: no previous prototype for ‘acpi_container_init’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes following compiler warning when build via make W=1:
drivers/acpi/battery.c:149:52: warning: no previous prototype for ‘acpi_battery_present’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes following compiler warnings when build via make W=1:
drivers/acpi/processor_throttling.c: In function ‘acpi_processor_throttling_init’:
drivers/acpi/processor_throttling.c:216:40: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes following compiler warnings when build via make W=1:
drivers/acpi/button.c:220:5: warning: no previous prototype for ‘acpi_lid_notifier_register’ [-Wmissing-prototypes]
drivers/acpi/button.c:226:5: warning: no previous prototype for ‘acpi_lid_notifier_unregister’ [-Wmissing-prototypes]
drivers/acpi/button.c:232:5: warning: no previous prototype for ‘acpi_lid_open’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Kconfig entry for ACPI Container and Module Devices got
added in v2.6.11. Its default value has always been set to
(ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU || ACPI_HOTPLUG_IO)
But the Kconfig symbol ACPI_HOTPLUG_IO has never existed. So it's
pointless to use it to set this default value.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the kernel calls _OSC with OSC_SB_HOTPLUG_OST_SUPPORT bit
set at boot-time, the OS is responsible for calling _OST for
ACPI hotplug events. However, when hotplug.enabled attribute
is unset for ACPI scan drivers, their notify handlers are removed
and _OST is not called for ACPI hotplug events as a result.
This patch keeps the notify handler of ACPI scan drivers,
acpi_hotplug_notify_cb(), installed regardless of the state of
hotplug.enabled. The notify handler then checks if hotplug.enabled
is set for the associated scan handler. If unset, the notify
handler calls _OST with a proper error code. The patch also
eliminates ACPI namespace walk when hotplug.enabled is changed
via sysfs.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When installing/removing a notify handler to/from an ACPI device
object, ACPI core tries to match its associated scan handler to
see if it supports hotplug. However, the matching logic of the
notify handler is different from the matching logic of attaching
a scan handler to an ACPI device object. This patch updates the
matching logic of the notify handlers to be consistent with the
attach handling.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch introduces acpi_set_pnp_ids() and acpi_free_pnp_ids(),
which are updated from acpi_device_set_id() and acpi_free_ids(),
to setup and free acpi_device_pnp for a given acpi_handle. They
can be called without acpi_device.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch updates the internal operations of acpi_device_set_id()
to setup acpi_device_pnp without using acpi_device. There is no
functional change to acpi_device_set_id() in this patch.
acpi_pnp_type is added to acpi_device_pnp, so that PNPID type is
self-contained within acpi_device_pnp. acpi_add_id(), acpi_bay_match(),
acpi_dock_match(), acpi_ibm_smbus_match() and acpi_is_video_device()
are changed to take acpi_handle as an argument, instead of acpi_device.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Replace the combination of kmalloc() and memcpy() in acpi_run_osc()
with a single call to kmemdup().
[rjw: Changelog]
Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot,
completely dimming the screen. Ignore this initial value for this
machine.
Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Found with a network device in QEMU/KVM guest not working anymore.
Bisected to commit c13085e5
ACPICA: Resource Mgr: Prevent infinite loops in resource walks
That commit will check acpi_resource length strictly which causes
acpi_set_current_resources to return failure and IRQ for PCI
devices is not set properly.
Set length for all those TYPE_END_TAG acpi_resources.
[rjw: Changelog]
Bisected-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have
registers providing access to LTR (Latency Tolerance Reporting)
functionality that allows software to monitor and possibly influence
the aggressiveness of the platform's active-state power management.
For each LPSS device, there are two modes of operation related to LTR,
the auto mode and the software mode. In the auto mode the LTR is
set up by the platform firmware and managed by hardware. Software
can only read the LTR register values to monitor the platform's
behavior. In the software mode it is possible to use LTR to control
the extent to which the platform will use its built-in power
management features.
This changeset adds support for reading the LPSS devices' LTR
registers and exposing their values to user space for monitoring and
diagnostics purposes. It re-uses the MMIO mappings created to access
the LPSS devices' clock registers for reading the values of the LTR
registers and exposes them to user space through sysfs device
attributes. Namely, a new atrribute group, lpss_ltr, is created for
each LPSS device. It contains three new attributes: ltr_mode,
auto_ltr, sw_ltr. The value of the ltr_mode attribute reflects the
LTR mode being used at the moment (software vs auto) and the other
two contain the actual register values (raw) whose meaning depends
on the LTR mode. All of these attributes are read-only.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some
common features that aren't shared with any other platform devices,
including the clock and LTR (Latency Tolerance Reporting) registers.
It is better to handle those features in common code than to bother
device drivers with doing that (I/O functionality-wise the LPSS
devices are generally compatible with other devices that don't
have those special registers and may be handled by the same drivers).
The clock registers of the LPSS devices are now taken care of by
the special clk-x86-lpss driver, but the MMIO mappings used for
accessing those registers can also be used for accessing the LTR
registers on those devices (LTR support for the Lynxpoint LPSS is
going to be added by a subsequent patch). Thus it is convenient
to add a special ACPI scan handler for the Lynxpoint LPSS devices
that will create the MMIO mappings for accessing the clock (and
LTR in the future) registers and will register the LPSS devices'
clocks, so the clk-x86-lpss driver will only need to take care of
the main Lynxpoint LPSS clock.
Introduce a special ACPI scan handler for Intel Lynxpoint LPSS
devices as described above. This also reduces overhead related to
browsing the ACPI namespace in search of the LPSS devices before the
registration of their clocks, removes some LPSS-specific (and
somewhat ugly) code from acpi_platform.c and shrinks the overall code
size slightly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
The acpi_hotplug_profile_ktype object should be static, so make that
be the case.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull Xen fixes from Konrad Rzeszutek Wilk:
- Compile warnings and errors (one on x86, two on ARM)
- WARNING in xen-pciback
- Use the acpi_processor_get_performance_info instead of the 'register'
version
* tag 'stable/for-linus-3.9-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/acpi: remove redundant acpi/acpi_drivers.h include
xen: arm: mandate EABI and use generic atomic operations.
acpi: Export the acpi_processor_get_performance_info
xen/pciback: Don't disable a PCI device that is already disabled.
For the predefined names that return fully variable-length
packages, allow a zero-length package with no warning, since it
is technically a legal construct (and BIOS writers use it.)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Flags the case where external control methods are unresolved,
meaning that the disassembler had no idea how many arguments to
parse for the method invocation.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fixes several possible problems with resource templates returned
by _CRS/_PRS/_DMA predefined names. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
New file, nsconvert.c, for return object conversion functions.
Created in preparation for new conversion functions forthcoming.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Adds the framework to allow object repairs very early in the
return object analysis. Enables repairs like string->unicode,
etc. Bob Moore, Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since 20060317, the pointer to next object is the first element in
its common header. Remove bogus LinkOffset from ACPI_MEMORY_LIST
and directly use NextObject.
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add checks for zero-length resource descriptors in all code that
loops through a resource descriptor list. This prevents possible
infinite loops because the length is used to increment the traveral
pointer and detect the end-of-descriptor.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The git commit d5aaffa9dd
(cpufreq: handle cpufreq being disabled for all exported function)
tightens the cpufreq API by returning errors when disable_cpufreq()
had been called.
The problem we are hitting is that the module xen-acpi-processor which
uses the ACPI's functions: acpi_processor_register_performance,
acpi_processor_preregister_performance, and acpi_processor_notify_smm
fails at acpi_processor_register_performance with -22.
Note that earlier during bootup in arch/x86/xen/setup.c there is also
an call to cpufreq's API: disable_cpufreq().
This is b/c we want the Linux kernel to parse the ACPI data, but leave
the cpufreq decisions to the hypervisor.
In v3.9 all the checks that d5aaffa9dd
added are now hit and the calls to cpufreq_register_notifier will now
fail. This means that acpi_processor_ppc_init ends up printing:
"Warning: Processor Platform Limit not supported"
and the acpi_processor_ppc_status is not set.
The repercussions of that is that the call to
acpi_processor_register_performance fails right away at:
if (!(acpi_processor_ppc_status & PPC_REGISTERED))
and we don't progress any further on parsing and extracting the _P*
objects.
The only reason the Xen code called that function was b/c it was
exported and the only way to gather the P-states. But we can also
just make acpi_processor_get_performance_info be exported and not
use acpi_processor_register_performance. This patch does so.
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Make the ACPI memory hotplug driver use struct acpi_scan_handler
for representing the object used to set up ACPI memory hotplug
functionality and to remove hotplug memory ranges and data
structures used by the driver before unregistering ACPI device
nodes representing memory. Register the new struct acpi_scan_handler
object with the help of acpi_scan_add_handler_with_hotplug() to allow
user space to manipulate the attributes of the memory hotplug
profile.
This results in a significant reduction of the drvier's code size
and removes some ACPI hotplug code duplication.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Make the ACPI container driver register its ACPI scan handler object
using acpi_scan_add_handler_with_hotplug() to allow user space to
manipulate its hotplug profile attributes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Introduce user space interface for manipulating hotplug profiles
associated with ACPI scan handlers.
The interface consists of sysfs directories under
/sys/firmware/acpi/hotplug/, one for each hotplug profile, containing
an attribute allowing user space to manipulate the enabled field of
the corresponding profile. Namely, switching the enabled attribute
from '0' to '1' will cause the common hotplug notify handler to be
installed for all ACPI namespace objects representing devices matching
the scan handler associated with the given hotplug profile (and
analogously for the converse switch).
Drivers willing to use the new user space interface should add their
ACPI scan handlers with the help of new funtion
acpi_scan_add_handler_with_hotplug().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Introduce new helper routine acpi_scan_handler_matching() for
checking if the given ACPI scan handler matches a given device ID
and rework acpi_scan_match_handler() to use the new routine (that
routine will also be useful for other purposes in the future).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Switch the ACPI container driver to using common device hotplug code
introduced previously. This reduces the driver down to a trivial
definition and registration of a struct acpi_scan_handler object.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Multiple drivers handling hotplug-capable ACPI device nodes install
notify handlers covering the same types of events in a very similar
way. Moreover, those handlers are installed in separate namespace
walks, although that really should be done during namespace scans
carried out by acpi_bus_scan(). This leads to substantial code
duplication, unnecessary overhead and behavior that is hard to
follow.
For this reason, introduce common code in drivers/acpi/scan.c for
handling hotplug-related notification and carrying out device
insertion and eject operations in a generic fashion, such that it
may be used by all of the relevant drivers in the future. To cover
the existing differences between those drivers introduce struct
acpi_hotplug_profile for representing collections of hotplug
settings associated with different ACPI scan handlers that can be
used by the drivers to make the common code reflect their current
behavior.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Introduce helper routine acpi_scan_match_handler() that will find the
ACPI scan handler matching a given device ID, if there is one, and
rework acpi_scan_attach_handler() to use the new routine (that
routine will also be useful for other purposes going forward).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
After PCI and USB have stopped using the .find_bridge() callback in
struct acpi_bus_type, the only remaining user of it is SATA, but SATA
only pretends to be a user, because it points that callback to a stub
always returning -ENODEV.
For this reason, drop the SATA's dummy .find_bridge() callback and
remove .find_bridge(), which is not used any more, from struct
acpi_bus_type entirely.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection.
What USB actually needs, though, is to call usb_acpi_find_device()
for USB ports that don't have a bus type defined, but have
usb_port_device_type as their device type, as well as for USB
devices.
To fix that replace the struct bus_type pointer in struct
acpi_bus_type used for matching devices to specific subsystems
with a .match() callback to be used for this purpose and update
the users of struct acpi_bus_type, including USB, accordingly.
Define the .match() callback routine for USB, usb_acpi_bus_match(),
in such a way that it will cover both USB devices and USB ports
and remove the now redundant .find_bridge() callback pointer from
usb_acpi_bus.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
pr->id is u32 which never < 0, so remove the redundant pr->id < 0
check from acpi_processor_add().
[rjw: Changelog]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
kfree() on a NULL pointer is a no-op, so remove a redundant NULL
pointer check in map_mat_entry().
[rjw: Changelog]
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Got this dmesg log on an Acer Aspire 725.
[ 0.256351] ACPI: (supports S0ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568)
[ 0.256373] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568)
[ 0.256391] S3 S4 S5)
Avoid this interleaving error messages.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 e8d1955258 ("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:
f7210e6c4a ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
protect movablecore_map in memblock_overlaps_region().")
01a178a94e ("acpi, memory-hotplug: support getting hotplug info from
SRAT")
27168d38fa ("acpi, memory-hotplug: extend movablemem_map ranges to
the end of node")
e8d1955258 ("acpi, memory-hotplug: parse SRAT before memblock is
ready")
fb06bc8e5f ("page_alloc: bootmem limit with movablecore_map")
42f47e27e7 ("page_alloc: make movablemem_map have higher priority")
6981ec3114 ("page_alloc: introduce zone_movable_limit[] to keep
movable limit for nodes")
34b71f1e04 ("page_alloc: add movable_memmap kernel parameter")
4d59a75125 ("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: Tim Gardner <tim.gardner@canonical.com>
Reported-by: Don Morris <don.morris@hp.com>
Bisected-by: Don Morris <don.morris@hp.com>
Tested-by: Don Morris <don.morris@hp.com>
Signed-off-by: Yinghai 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: Linus Torvalds <torvalds@linux-foundation.org>
Pull EDAC fixes and ghes-edac from Mauro Carvalho Chehab:
"For:
- Some fixes at edac drivers (i7core_edac, sb_edac, i3200_edac);
- error injection support for i5100, when EDAC debug is enabled;
- fix edac when it is loaded builtin (early init for the subsystem);
- a "Firmware First" EDAC driver, allowing ghes to report errors via
EDAC (ghes-edac).
With regards to ghes-edac, this fixes a longstanding BZ at Red Hat
that happens with Nehalem and Sandy Bridge CPUs: when both GHES and
i7core_edac or sb_edac are running, the error reports are
unpredictable, as both BIOS and OS race to access the registers. With
ghes-edac, the EDAC core will refuse to register any other concurrent
memory error driver.
This patchset moves the ghes struct definitions to a separate header
file (include/acpi/ghes.h) and adds 3 hooks at apei/ghes.c to
register/unregister and to report errors via ghes-edac. Those changes
were acked by ghes driver maintainer (Huang)."
* 'linux_next' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac: (30 commits)
i5100_edac: convert to use simple_open()
ghes_edac: fix to use list_for_each_entry_safe() when delete list items
ghes_edac: Fix RAS tracing
ghes_edac: Make it compliant with UEFI spec 2.3.1
ghes_edac: Improve driver's printk messages
ghes_edac: Don't credit the same memory dimm twice
ghes_edac: do a better job of filling EDAC DIMM info
ghes_edac: add support for reporting errors via EDAC
ghes_edac: Register at EDAC core the BIOS report
ghes: add the needed hooks for EDAC error report
ghes: move structures/enum to a header file
edac: add support for error type "Info"
edac: add support for raw error reports
edac: reduce stack pressure by using a pre-allocated buffer
edac: lock module owner to avoid error report conflicts
edac: remove proc_name from mci structure
edac: add a new memory layer type
edac: initialize the core earlier
edac: better report error conditions in debug mode
i5100_edac: Remove two checkpatch warnings
...
Pull more x86 fixes from Peter Anvin:
"Additional x86 fixes. Three of these patches are pure documentation,
two are pretty trivial; the remaining one fixes boot problems on some
non-BIOS machines."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Make sure we can boot in the case the BDA contains pure garbage
x86, efi: Mark disable_runtime as __initdata
x86, doc: Fix incorrect comment about 64-bit code segment descriptors
doc, kernel-parameters: Document 'console=hvc<n>'
doc, xen: Mention 'earlyprintk=xen' in the documentation.
ACPI: Overriding ACPI tables via initrd only works with an initrd and on X86
