The functions for the original/legacy sleep/wake registers are in
hwsleep.c, and the functions for the new extended FADT V5 sleep
registers are in hwesleep.c
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Adds acpi_hw_execute_sleep_method to handle the various sleep methods
such as _GTS, _BFS, _WAK, and _SST. Removes the specialized
functions previously used for each of these methods.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This interface allows the host to override a table via a
physical address, instead of the logical address required by
acpi_os_table_override. This simplifies the host implementation.
Initial implementation by Thomas Renninger. ACPICA implementation
creates a single function for table overrides that attempts both
a logical and a physical override.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add new notify values, add support for "hardware specific" notifies.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This change expands acpi_os_read_memory and acpi_os_write_memory to a
full 64 bits. This allows 64 bit transfers via the acpi_read and
acpi_write interfaces. Note: The internal acpi_hw_read and acpi_hw_write
interfaces remain at 32 bits, because 64 bits is not needed to
access the standard ACPI registers.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add ACPI_REDUCED_HARDWARE flag that removes all hardware-related
code (about 10% code, 5% static data).
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

These prototypes were incorrectly declared in achware.h.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Adds sleep and wake support for systems with these registers.
One new file, hwxfsleep.c
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

_REV returns the supported ACPI revision level, which is now 5.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Those lines have two copies.

Not sure how it could happen, looks like git problem.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Those lines have two copies.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ioremap() has become more picky and is now spitting out console messages like:

 ioremap error for 0xbddbd000-0xbddbe000, requested 0x10, got 0x0

when loading the einj driver.  What we are trying to so here is map
a couple of data structures that the EINJ table points to. Perhaps
acpi_os_map_memory() is a better tool for this?
Most importantly it works, but as a side benefit it maps the structures
into kernel virtual space so we can access them with normal C memory
dereferences, so instead of using:
	writel(param1, &v5param->apicid);
we can use the more natural:
	v5param->apicid = param1;
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This function is returning pointers.  Sparse complains here:
drivers/acpi/apei/einj.c:262:32: warning:
	Using plain integer as NULL pointer
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

According to the ACPI spec [1] section 18.6.4 the TRIGGER_ERROR action
table can consists of zero elements.

[1] Advanced Configuration and Power Interface Specification
    Revision 5.0, December 6, 2011
	http://www.acpi.info/DOWNLOADS/ACPIspec50.pdfSigned-off-by: NNiklas Söderlund <niklas.soderlund@ericsson.com>
Acked-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Sony Vaio VPCCW29FX does not resume correctly without
acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.

https://bugzilla.kernel.org/show_bug.cgi?id=34722Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

With the conversion of atomicio's routines in place (see commits
6f68c91c and 700130b4), atomicio.[ch] can be removed, replacing
the APEI specific pre-mapping capabilities with the more generalized
versions that drivers/acpi/osl.c provides.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch adds support for RAM to ACPI's mapping capabilities in order
to support APEI error injection (EINJ) actions.

This patch re-factors similar functionality introduced in commit
76da3fb3, bringing it into osl.c in preparation for removing
./drivers/acpi/atomicio.[ch].
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Base ACPI (CA) currently does not support atomic 64-bit reads and writes
(acpi_read() and acpi_write() split 64-bit loads/stores into two
32-bit transfers) yet APEI expects 64-bit transfer capability, even
when running on 32-bit systems.

This patch implements 64-bit read and write routines for APEI usage.

This patch re-factors similar functionality introduced in commit
04c25997, bringing it into the ACPI subsystem in preparation for
removing ./drivers/acpi/atomicio.[ch].  In the implementation I have
replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
64-bit versions for APEI to utilize, as opposed to something more
elegant.  My thinking is that we should attempt to see if we can get
ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
interfaces are natively 64-bit capable and then subsequently remove the
replication.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Delay the setting up of features (cpuidle, throttling by calling
acpi_processor_start()) to the time when the hotplugged
core got onlined the first time and got fully
initialized.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

No functional change.

This is needed because:
When a CPU gets hotplugged, it's totally uninitialized
and offline. cpuinfo_x86 struct (cpu_data(cpu)) is mostly
zero (CPU feature flags, model, family,..).

When a CPU gets hotplugged, struct processor is alloc'd,
some sysfs files are set up but acpi_processor_add()
must not try to access a MSR on this CPU or try to read
out CPU feature,family, etc.

This must be done in acpi_processor_start().
The next patch will delay the call of acpi_processor_start()
for physically hotpluggedcores, to the time when they are onlined
the first time. There it is safe then to access cpu_data(cpu)
cpuinfo_x86 struct or access MSRs which is needed to
set up cpuidle, throttling and other features.

Tested and
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI 5.0 provides extensions to the EINJ mechanism to specify the
target for the error injection - by APICID for cpu related errors,
by address for memory related errors, and by segment/bus/device/function
for PCIe related errors. Also extensions for vendor specific error
injections.
Tested-by: NChen Gong <gong.chen@linux.intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

V2: Fix typo: pr->handle -> pr, here: acpi_processor_hotadd_init(pr)

This is a very small part taken from patches which afaik
are coming from Yunhong Jiang (for a Xen not a Linus repo?).

Cleanup only: no functional change.

Advantage (beside cleanup) is that other data of the pr (acpi_processor) struct
in the acpi_processor_hotadd_init() is needed later, for example a newly
introduced flag:
pr->flags.need_hotplug_init
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Since commit 46bcfad7 registering
and unregistering cpuidle is done in processor_idle.c.
Unregistering via:
acpi_bus_unregister_driver(&acpi_processor_driver)
   -> acpi_processor_remove()
      -> acpi_processor_power_exit()

Remove not needed cpuidle_unregister_driver() call from
acpi_processor_exit
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

For UP processor, it is likely that no _MAT method or MADT table defined.
So currently acpi_get_cpuid(...) always return -1 for UP processor.
This is wrong. It should return valid value for CPU0.

In the other hand, BIOS may define multiple CPU handles even for UP
processor, for example

        Scope (_PR)
        {
            Processor (CPU0, 0x00, 0x00000410, 0x06) {}
            Processor (CPU1, 0x01, 0x00000410, 0x06) {}
            Processor (CPU2, 0x02, 0x00000410, 0x06) {}
            Processor (CPU3, 0x03, 0x00000410, 0x06) {}
        }

We should only return valid value for CPU0's acpi handle.
And return invalid value for others.

http://marc.info/?t=132329819900003&r=1&w=2

Cc: stable@vger.kernel.org
Reported-and-tested-by: wallak@free.fr
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

APEI needs memory access in interrupt context.  The obvious choice is
acpi_read(), but originally it couldn't be used in interrupt context
because it makes temporary mappings with ioremap().  Therefore, we added
drivers/acpi/atomicio.c, which provides:
    acpi_pre_map_gar()     -- ioremap in process context
	acpi_atomic_read()     -- memory access in interrupt context
	acpi_post_unmap_gar()  -- iounmap

Later we added acpi_os_map_generic_address() (29718521) and enhanced
acpi_read() so it works in interrupt context as long as the address has
been previously mapped (620242ae).  Now this sequence:
    acpi_os_map_generic_address()    -- ioremap in process context
    acpi_read()/apei_read()          -- now OK in interrupt context
    acpi_os_unmap_generic_address()
is equivalent to what atomicio.c provides.

This patch introduces apei_read() and apei_write(), which currently are
functional equivalents of acpi_read() and acpi_write().  This is mainly
proactive, to prevent APEI breakages if acpi_read() and acpi_write()
are ever augmented to support the 'bit_offset' field of GAS, as APEI's
__apei_exec_write_register() precludes splitting up functionality
related to 'bit_offset' and APEI's 'mask' (see its
APEI_EXEC_PRESERVE_REGISTER block).

With apei_read() and apei_write() in place, usages of atomicio routines
are converted to apei_read()/apei_write() and existing calls within
osl.c and the CA, based on the re-factoring that was done in an earlier
patch series - http://marc.info/?l=linux-acpi&m=128769263327206&w=2:
    acpi_pre_map_gar()     -->  acpi_os_map_generic_address()
    acpi_post_unmap_gar()  -->  acpi_os_unmap_generic_address()
    acpi_atomic_read()     -->  apei_read()
    acpi_atomic_write()    -->  apei_write()

Note that acpi_read() and acpi_write() currently use 'bit_width'
for accessing GARs which seems incorrect.  'bit_width' is the size of
the register, while 'access_width' is the size of the access the
processor must generate on the bus.  The 'access_width' may be larger,
for example, if the hardware only supports 32-bit or 64-bit reads.  I
wanted to minimize any possible impacts with this patch series so I
did *not* change this behavior.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Export remapping and unmapping interfaces - acpi_os_map_generic_address()
and acpi_os_unmap_generic_address() - for ACPI generic registers that are
backed by memory mapped I/O (MMIO).

The acpi_os_map_generic_address() and acpi_os_unmap_generic_address()
declarations may more properly belong in include/acpi/acpiosxf.h next to
acpi_os_read_memory() but I believe that would require the ACPI CA making
them an official part of the ACPI CA - OS interface.

ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure"
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Generic Address Structures (GAS) may reside within ACPI tables which
are byte aligned.  This patch copies GAS 'address' references to a local
variable, which will be naturally aligned, to be used going forward.

ACPI Generic Address Structure (GAS) reference:
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure"
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
In order to know whether or not, we must know what version the SRAT
table has.

This patch stores the SRAT table revision for later consumption
by arch specific __init functions.
Signed-off-by: NKurt Garloff <kurt@garloff.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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
mech.  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 excludes ACPI NVS regions when APEI components
request resources.  So that they will not conflict with ACPI NVS
regions.
Reported-and-tested-by: NPavel Ivanov <paivanof@gmail.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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>

Current fix for resource conflict is to remove the address region <param1 &
param2, ~param2+1> from trigger resource, which is highly relies on valid user
input. This patch is trying to avoid such potential issues by fetching the
exact address region from trigger action table entry.
Signed-off-by: NXiao, Hui <hui.xiao@linux.intel.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some APEI firmware implementation will access injected address
specified in param1 to trigger the error when injecting memory error.
This will cause resource conflict with RAM.

On one of our testing machine, if injecting at memory address
0x10000000, the following error will be reported in dmesg:

  APEI: Can not request iomem region <0000000010000000-0000000010000008> for GARs.

This patch removes the injecting memory address range from trigger
table resources to avoid conflict.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

On one of our testing machine, the following EINJ command lines:

  # echo 0x10000000 > param1
  # echo 0xfffffffffffff000 > param2
  # echo 0x8 > error_type
  # echo 1 > error_inject

Will get:

  echo: write error: Input/output error

The EIO comes from:

    rc = apei_exec_pre_map_gars(&trigger_ctx);

The root cause is as follow.  Normally, ACPI atomic IO support is used
to access IO memory.  But in EINJ of that machine, it is used to
access RAM to trigger the injected error.  And the ioremap() called by
apei_exec_pre_map_gars() can not map the RAM.

This patch add RAM mapping support to ACPI atomic IO support to
satisfy EINJ requirement.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Because printk is not safe inside NMI handler, the recoverable error
records received in NMI handler will be queued to be printked in a
delayed IRQ context via irq_work.  If a fatal error occurs after the
recoverable error and before the irq_work processed, we lost a error
report.

To solve the issue, the queued error records are printked in NMI
handler if system will go panic.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

In most cases, printk only guarantees messages from different printk
calling will not be interleaved between each other.  But, one APEI
GHES hardware error report will involve multiple printk calling,
normally each for one line.  So it is possible that the hardware error
report comes from different generic hardware error source will be
interleaved.

In this patch, a sequence number is prefixed to each line of error
report.  So that, even if they are interleaved, they still can be
distinguished by the prefixed sequence number.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Because APEI tables are optional, these message may confuse users, for
example,

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/599715Reported-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use the normal %pR-like format for MMIO and I/O port ranges.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

aer_recover_queue() is called when recoverable PCIe AER errors are
notified by firmware to do the recovery work.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is no 64bit read/write support in ACPI atomicio because
readq/writeq is used to implement 64bit read/write, but readq/writeq
is not available on i386.  This patch implement 64bit read/write
support in atomicio via two readl/writel.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>