It is reported that when acpi_gbl_disable_ssdt_table_load is specified, user
still can see it installed into /sys/firmware/acpi/tables on Linux boxes.
This is because the option only stops table "loading", but doesn't stop
table "installing", thus it is still in the acpi_gbl_root_table_list. With
previous cleanups, it is possible to prevent SSDT installations to make
it not such confusing.  The global variable is also renamed.  Lv Zheng.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
[rjw: Subject]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use acpi_os_allocate_zeroed instead of acpi_os_allocate + memset.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The previous commit "ACPICA: Add auto-serialization support for ill-behaved
control methods" introduced the auto-serialization facility as a workaround
that can be enabled by "acpi_auto_serialize":

This feature marks control methods that create named objects as "serialized"
to avoid unwanted AE_ALREADY_EXISTS control method evaluation failures.

Enable method auto-serialization as the default kernel behavior.  The new kernel
parameter is also changed from "acpi_auto_serialize" to "acpi_no_auto_serialize"
to reflect the default behavior.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52191
References: http://www.spinics.net/lists/linux-acpi/msg49496.htmlSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change adds support to automatically mark a control method as
"serialized" if the method creates any named objects. This will
positively prevent the method from being entered by more than one
thread and thus preventing a possible abort when an attempt is
made to create an object twice.

Implemented by parsing all non-serialize control methods at table
load time.

This feature is disabled by default and this patch also adds a new
Linux kernel parameter "acpi_auto_serialize" to allow this feature
to be turned on for a specific boot.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52191Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to the reports, the "acpi_serialize" mechanism is broken as:

 A. The parallel method calls can still happen when the interpreter lock is
    released under the following conditions:
    1. External callbacks are invoked, for example, by the region handlers,
       the exception handlers, etc.;
    2. Module level execution is performed when Load/LoadTable opcodes are
       executed, and
    3. The _REG control methods are invoked to complete the region
       registrations.
 B. For the following situations, the interpreter lock need to be released
    even for a serialized method while currently, the lock-releasing
    operation is marked as a no-op by
    acpi_ex_relinquish/reacquire_interpreter() when this mechanism is
    enabled:
    1. Wait opcode is executed,
    2. Acquire opcode is executed, and
    3. Sleep opcode is executed.

This patch removes this mechanism and the internal
acpi_ex_relinquish/reacquire_interpreter() APIs.  Lv Zheng.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52191Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We already have a macro for PREFIX of "ACPI: " in
drivers/acpi/internal.h, so remove the duplicate ones
in ACPI drivers when internal.h is included.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since the only function executed by acpi_hotplug_execute() is
acpi_device_hotplug() and it only is called by the ACPI core,
simplify its definition so that it only takes two arguments, the
ACPI device object pointer and event code, rename it to
acpi_hotplug_schedule() and move its header from acpi_bus.h to
the ACPI core's internal header file internal.h.  Modify the
definition of acpi_device_hotplug() so that its first argument is
an ACPI device object pointer and modify the definition of
struct acpi_hp_work accordingly.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Sometimes, there might be bugs caused by unexpected AML which is compliant
to the Windows but not compliant to the Linux implementation.

There is a predefined validation mechanism implemented in ACPICA to repair
the unexpected AML evaluation results that are caused by the unexpected
AMLs.  For example, BIOS may return misorder _CST result and the repair
mechanism can make an ascending order on the returned _CST package object
based on the C-state type.
This mechanism is quite useful to implement an AML interpreter with better
compliance with the real world where Windows is the de-facto standard and
BIOS codes are only tested on one platform thus not compliant to the
ACPI specification.

But if a compliance issue hasn't been figured out yet, it will be
difficult for developers to identify if the unexpected evaluation result
is caused by this mechanism or by the AML interpreter.
For example, _PR0 is expected to be a control method, but BIOS may use
Package: "Name(_PR0, Package(1) {P1PR})".
This boot option can disable the predefined validation mechanism so that
developers can make sure the root cause comes from the parser/executer.

This patch adds a new kernel parameter to disable this feature.

A build test has been made on a Dell Inspiron mini 1100 (i386 z530)
machine when this patch is applied and the corresponding boot test is
performed w/ or w/o the new kernel parameter specified.

References: https://bugzilla.kernel.org/show_bug.cgi?id=67901Tested-by: NFabian Wehning <fabian.wehning@googlemail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Marks the function acpi_table_checksum() as static in osl.c
because it is not used outside this file.

This eliminates the following warning in osl.c:
drivers/acpi/osl.c:547:11: warning: no previous prototype for
‘acpi_table_checksum’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Minor cleanup: remove some extra trailing white space.
Signed-off-by: NAl Stone <al.stone@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To avoid build problems and breaking dependencies between ACPI header
files, <acpi/acpi.h> should not be included directly by code outside
of the ACPI core subsystem.  However, that is possible if
<linux/acpi_io.h> is included, because that file contains
a direct inclusion of <acpi/acpi.h>.

For this reason, remove the direct <acpi/acpi.h> inclusion from
<linux/acpi_io.h>, move that file from include/linux/ to include/acpi/
and make <linux/acpi.h> include it for CONFIG_ACPI set along with the
other ACPI header files.  Accordingly, Remove the inclusions of
<linux/acpi_io.h> from everywhere.

Of course, that causes the contents of the new <acpi/acpi_io.h> file
to be available for CONFIG_ACPI set only, so intel_opregion.o that
depends on it should also depend on CONFIG_ACPI (and it really should
not be compiled for CONFIG_ACPI unset anyway).

References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there.  And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If an ACPI namespace node is removed (usually, as a result of a
table unload), and there is a data object attached to that node,
acpi_ns_delete_node() executes the removal handler submitted to
acpi_attach_data() for that object.  That handler is currently empty
for struct acpi_device objects, so it is necessary to detach those
objects from the corresponding ACPI namespace nodes in advance every
time a table unload may happen.  That is cumbersome and inefficient
and leads to some design constraints that turn out to be quite
inconvenient (in particular, struct acpi_device objects cannot be
registered for namespace nodes representing devices that are not
reported as present or functional by _STA).

For this reason, introduce a non-empty removal handler for ACPI
device objects that will unregister them when their ACPI namespace
nodes go away.

This code modification alone should not change functionality except
for the ordering of the ACPI hotplug workqueue which should not
matter (without subsequent code changes).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations.  They both are somewhat
cumbersome to use and work slightly differently.

The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.

The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().

Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute().  Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar.  That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.

For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

"str" is never NULL here so I have removed the check.  There are static
checkers which complain about superfluous NULL checks because it may
indicate confusion or a bug.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, acpi_os_sleep() uses schedule_timeout_interruptible()
which can be interrupted by a signal, and that causes the real sleep
time to be shorter.

According to the ACPI spec:

 The Sleep term is used to implement long-term timing requirements.
 Execution is delayed for at least the required number of milliseconds.

The sleeping time should be at least the required number msecs, so use
msleep() which guarantees that to implement it.
Signed-off-by: NLiu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Current ACPI tables in initrd is limited to 10, that is too small.
64 should be good enough as we have 35 sigs and could have several
SSDT.

Two problems in current code prevent us from increasing limit:
 1. The cpio file info array is put in stack, as every element is 32
    bytes, could run out of stack if we have that array size to 64.
    We can move it out from stack, make it global and put it into the
    __initdata section.
 2. early_ioremap() only can remap 256k one time. Current code maps
    10 tables at a time. If we increased that limit, the whole size
    could be more than 256k, so early_ioremap() would fail with that.
    We can map chunks one by one during copying, instead of mapping
    all of them together.
Signed-off-by: NYinghai <yinghai@kernel.org>
Acked-by: NTejun Heo <tj@kernel.org>
Tested-by: NThomas Renninger <trenn@suse.de>
Reviewed-by: NTang Chen <tangchen@cn.fujitsu.com>
Tested-by: NTang Chen <tangchen@cn.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The macro INVALID_TABLE() is defined like this:

 #define INVALID_TABLE(x, path, name)                                    \
         { pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }

And it is used like this:

	for (...) {
		...
		if (...)
			INVALID_TABLE()
		...
	}

The "continue" in the macro makes the code hard to understand.

And also, this macro is only used several times in a single file.
As suggested by Joe Perches <joe@perches.com>, we can remote it and
use pr_err directly.

So after this patch, this macro is removed, and pr_err() is used
like this:

	for (...) {
		...
		if (...) {
			pr_err("ACPI OVERRIDE: ......");
			continue;
		}
		...
	}
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Suggested-by: NJoe Perches <joe@perches.com>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__initdata should come after the variable name being declared and
nowhere else, in this way the variable will be placed in the
intended section.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Like acpi_os_prepare_sleep(), register a callback for use in systems
like tboot, and xen, which have system specific requirements outside
of ACPICA.  This mirrors the functionality in acpi_os_prepare_sleep(),
called from acpi_hw_sleep()
Signed-off-by: NBen Guthro <benjamin.guthro@citrix.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch cleans up the following sparse warning:

# make C=2 drivers/acpi/osl.o
...
drivers/acpi/osl.c:1775:20: warning: symbol 'acpi_os_initialize1' was not declared. Should it be static?
...
  CC      drivers/acpi/osl.o
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch changes the "acpi_osi=" boot parameter implementation so
that:
1. "acpi_osi=!" can be used to disable all _OSI OS vendor strings by
   default.  It is meaningless to specify "acpi_osi=!" multiple
   times as it can only affect the default state of the target _OSI
   strings.
2. "acpi_osi=!*" can be used to remove all _OSI OS vendor strings
   and all _OSI feature group strings.  It is useful to specify
   "acpi_osi=!*" multiple times through kernel command line to
   override the current state of the target _OSI strings.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch introduces "acpi_osi=!" command line to force Linux replying
"UNSUPPORTED" to all of the _OSI strings.  This patch is based on an
ACPICA enhancement - the new API acpi_update_interfaces().

The _OSI object provides the platform with the ability to query OSPM
to determine the set of ACPI related interfaces, behaviors, or
features that the operating system supports.  The argument passed to
the _OSI is a string like the followings:
1. Feature Group String, examples include
   Module Device
   Processor Device
   3.0 _SCP Extensions
   Processor Aggregator Device
   ...
2. OS Vendor String, examples include
   Linux
   FreeBSD
   Windows
   ...

There are AML codes provided in the ACPI namespace written in the
following style to determine OSPM interfaces / features:
    Method(OSCK)
    {
        if (CondRefOf(_OSI, Local0))
        {
            if (\_OSI("Windows"))
            {
                Return (One)
            }
            if (\_OSI("Windows 2006"))
            {
                Return (Ones)
            }
            Return (Zero)
        }
        Return (Zero)
    }

There is a debugging facility implemented in Linux.  Users can pass
"acpi_osi=" boot parameters to the kernel to tune the _OSI evaluation
result so that certain AML codes can be executed.  Current
implementation includes:
1. 'acpi_osi=' - this makes CondRefOf(_OSI, Local0) TRUE
2. 'acpi_osi="Windows"' - this makes \_OSI("Windows") TRUE
3. 'acpi_osi="!Windows"' - this makes \_OSI("Windows") FALSE
The function to implement this feature is also used as a quirk mechanism
in the Linux ACPI subystem.

When _OSI is evaluatated by the AML codes, ACPICA replies "SUPPORTED"
to all Windows operating system vendor strings.  This is because
Windows operating systems return "SUPPORTED" if the argument to the
_OSI method specifies an earlier version of Windows.  Please refer to
the following MSDN document:

How to Identify the Windows Version in ACPI by Using _OSI
http://msdn.microsoft.com/en-us/library/hardware/gg463275.aspx

This adds difficulties when developers want to feed specific Windows
operating system vendor string to the BIOS codes for debugging
purpose, multiple acpi_osi="!xxx" have to be specified in the command
line to force Linux replying "UNSUPPORTED" to the Windows OS vendor
strings listed in the AML codes.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI Timer() opcode should return monotonically increasing clock with 100ns
granularity according the ACPI 5.0 spec.

Testing the current Timer() implementation with following ASL code (and an
additional debug print in acpi_os_sleep() to get the sleep times dumped out
to dmesg):

	// Test: 10ms
	Store(Timer, Local1)
	Sleep(10)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

	// Test: 200ms
	Store(Timer, Local1)
	Sleep(200)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

	// Test 1300ms
	Store(Timer, Local1)
	Sleep(1300)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

The second sleep value is calculated using Timer(). If the implementation
is good enough we should be able to get the second value pretty close to
the first.

However, the current Timer() gives pretty bad sleep times:

	[   11.488100] ACPI: acpi_os_get_timer() TBD
	[   11.492150] ACPI: Sleep(10)
	[   11.502993] ACPI: Sleep(0)
	[   11.506315] ACPI: Sleep(200)
	[   11.706237] ACPI: Sleep(0)
	[   11.709550] ACPI: Sleep(1300)
	[   13.008929] ACPI: Sleep(0)

Fix this with the help of ktime_get(). Once the fix is applied and run
against the same ASL code we get:

	[   11.486786] ACPI: Sleep(10)
	[   11.499029] ACPI: Sleep(12)
	[   11.512350] ACPI: Sleep(200)
	[   11.712282] ACPI: Sleep(200)
	[   11.912170] ACPI: Sleep(1300)
	[   13.211577] ACPI: Sleep(1300)

That is much more closer to the values we expected.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Optionally do not load any SSDTs from the RSDT/XSDT during
initialization.  This can be useful for overriding SSDTs
using DSDT overriding, thus useful for debugging ACPI
problems on some machines.  Lv Zheng. ACPICA BZ 1005.

References: https://bugs.acpica.org/show_bug.cgi?id=1005Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 53aac44c (ACPI: Store valid ACPI tables passed via early initrd
in reserved memblock areas) introduced acpi_initrd_override() that
passes a wrong value as the second argument to memblock_reserve().

Namely, the second argument of memblock_reserve() is the size of the
region, not the address of the top of it, so make
acpi_initrd_override() pass the size in there as appropriate.

[rjw: Changelog]
Signed-off-by: NWang YanQing <udknight@gmail.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Cc: 3.8+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use the resource_size() function instead of explicit computation.

[rjw: Subject and changelog]
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Enable ACPI SCI during suspend so that SCI can be used
as wake events for PM_SUSPEND_FREEZE.

For S3/S4 transition,
We disable all GPEs in suspend_ops->prepare_late() to
fix a problem that GPEs may trigger SCI  before
arch_suspend_disable_irqs() is run.
So it is safe to leave the SCI enabled until
arch_suspend_irq_disable() is run.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Will need to use it for PCI root bridge hotplug support, so rename
*acpiphp* to *acpi* and move to osc.c.  Also make kacpi_hotplug_wq static
after that.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: linux-acpi@vger.kernel.org

Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675b (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints.  Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Exported acpi_os_hotplug_execute() and acpi_bus_hot_remove_device()
so that they can be called from modules for hot-remove operations.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are two ways of overriding ACPI tables now, both need to taint the
the kernel.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-6-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Previous patches stored ACPI tables provided via initrd in a memblock reserved
area.
If a table is loaded and the table type of an initrd provided one matches,
the one from initrd is prefered.
In case of a SSDT table, the OEM table id also has to match.

ACPI tables can be loaded at boot time (static table pointers in XSDT),
but also dynamically any time later via ASL commands load() or loadTable().
The override mechanism always works.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-5-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

A later patch will compare them with ACPI tables that get loaded at boot or
runtime and if criteria match, a stored one is loaded.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Remove the unused argument of acpi_os_wait_events_complete.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 6fe0d062.

Paul bisected this regression.

The conversion was done blindly and is wrong, as it does not provide a
primary handler to disable the level type irq on the device level.
Neither does it set the IRQF_ONESHOT flag which handles that at the irq
line level.  This can't be done as the interrupt might be shared, though
we might extend the core to force it.

So an interrupt on this line will wake up the thread, but immediately
unmask the irq after that.  Due to the interrupt being level type the
hardware interrupt is raised over and over and prevents the irq thread
from handling it.  Fail.

request_irq() unfortunately does not refuse such a request and the patch
was obviously never tested with real interrupts.
Bisected-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make sure the removal of mappings uses the same logic that put the
mappings in place.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

... so that acpi_unmap()'s behavior gets in sync with acpi_map()'s.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NLen Brown <len.brown@intel.com>