The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid <-> nodeid mapping such as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid <-> apicid mapping.
3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
4. Establish all possible cpuid <-> nodeid mapping.

This patch finishes step 4.

This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.

[ tglx: Remove the unneeded exports ]
Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: NZhu Guihua <zhugh.fnst@cn.fujitsu.com>
Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Cc: mika.j.penttila@gmail.com
Cc: len.brown@intel.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: yasu.isimatu@gmail.com
Cc: linux-mm@kvack.org
Cc: linux-acpi@vger.kernel.org
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: gongzhaogang@inspur.com
Cc: tj@kernel.org
Cc: izumi.taku@jp.fujitsu.com
Cc: cl@linux.com
Cc: chen.tang@easystack.cn
Cc: akpm@linux-foundation.org
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1472114120-3281-6-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

ACPI 6.0 introduced an optional object _LPI that provides an alternate
method to describe Low Power Idle states. It defines the local power
states for each node in a hierarchical processor topology. The OSPM can
use _LPI object to select a local power state for each level of processor
hierarchy in the system. They used to produce a composite power state
request that is presented to the platform by the OSPM.

Since multiple processors affect the idle state for any non-leaf hierarchy
node, coordination of idle state requests between the processors is
required. ACPI supports two different coordination schemes: Platform
coordinated and  OS initiated.

This patch adds initial support for Platform coordination scheme of LPI.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add support for ACPI reconfiguration notifiers to allow subsystems
to react to changes in the ACPI tables that happen after the initial
enumeration. This is similar with the way dynamic device tree
notifications work.

The reconfigure notifications supported for now are device add and
device remove.

Since ACPICA allows only one table notification handler, this patch
makes the table notifier function generic and moves it out of the
sysfs specific code.
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds support for platform initited graceful shutdown as
described in sections 5.6.6(Table-143) and 6.3.5.1 of ACPI 6.1 spec

The OSPM will get a graceful shutdown request via a Notify operator
on \_SB device with a value of 0x81 per section 5.6.6. Following the
shutdown request from platform the OSPM needs to follow the
processing sequence as described in section 6.2.5.1.

v3
* Switched to regular work with delays from delayed work
* Dropped changes to actypes.h
* Small style changes

v2
* Switched from standalone driver to a simple notify handler

v1
* Initial

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In acpi_subsystem_init(), function acpi_enable_subsystem() is
called to do the real job. However with different flags passed to
acpi_enable_subsystem(), different code is executed.

In acpi_subsystem_init(), with "~ACPI_NO_ACPI_ENABLE" passed in, it
will only switch over the platform to the ACPI mode. The remaining
part of acpi_enable_subsystem() is done when acpi_bus_init() is
called.

So the comments above acpi_subsystem_init() is not exact, change it
here.
Signed-off-by: NBaoquan He <bhe@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_print_osc_error() basically duplicates the functionalit of
acpi_handle_debug(), so use that one in there.

While at it, convert the explicit KERN_DEBUG prints to pr_debug()
(and apply it to continuation messages too).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to the Windows probing result, during the table loading, the EC
device described in the ECDT should be used. And the ECDT EC is also
effective during the period the namespace objects are initialized (we can
see a separate process executing _STA/_INI on Windows before executing
other device specific control methods, for example, EC._REG). During the
device enumration, the EC device described in the DSDT should be used. But
there are differences between Linux and Windows around the device probing
order. Thus in Linux, we should enable the DSDT EC as early as possible
before enumerating devices in order not to trigger issues related to the
device enumeration order differences.

This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to
fix the gap. This also fixes a user reported regression triggered after we
switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant.

Fixes: 59f0aa94 (ACPI 2.0 / ECDT: Remove early namespace reference from EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261Reported-and-tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

With wrong ECDT fixes reverted, it is possible to put ECDT probing before
acpi_enable_subsystem().

But the ultimate purpose of ECDT re-enabling is to put the ECDT probing
before the namespace initialization (acpi_load_tables()). This patch
achieves this with protections so that we can enable it later when all
necessary corrections are upstreamed.

Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Tested-by: NChris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake-based systems by the Intel P-states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.

HWP interrupts use the thermal LVT which can be handled by Linux
natively, but on the affected Skylake-based systems SMM will respond
to it by default.  This is a problem for several reasons:
 - On the affected systems the SMM thermal LVT handler is broken (it
   will crash when invoked) and a BIOS update is necessary to fix it.
 - With thermal interrupt handled in SMM we lose all of the reporting
   features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
 - Some thermal drivers like x86-package-temp depend on the thermal
   threshold interrupts signaled via the thermal LVT.
 - The HWP interrupts are useful for debugging and tuning
   performance (if the kernel can handle them).
The native handling of thermal interrupts needs to be enabled
because of that.

This requires some way to tell SMM that the OS can handle thermal
interrupts.  That can be done by using _OSC/_PDC in processor
scope very early during ACPI initialization.

The meaning of _OSC/_PDC bit 12 in processor scope is whether or
not the OS supports native handling of interrupts for Collaborative
Processor Performance Control (CPPC) notifications.  Since on
HWP-capable systems CPPC is a firmware interface to HWP, setting
this bit effectively tells the firmware that the OS will handle
thermal interrupts natively going forward.

For details on _OSC/_PDC refer to:
http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html

To implement the _OSC/_PDC handshake as described, introduce a new
function, acpi_early_processor_osc(), that walks the ACPI
namespace looking for ACPI processor objects and invokes _OSC for
them with bit 12 in the capabilities buffer set and terminates the
namespace walk on the first success.

Also modify intel_thermal_interrupt() to clear HWP status bits in
the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
them from firing continuously).
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject & changelog, function rename ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Factor out the code that finds the first physical device
of a given ACPI device.  It is used in several places.
Signed-off-by: NAleksey Makarov <aleksey.makarov@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When _OSC fails and especially when it fails due to an invalid UUID,
it's helpful to show the UUID that we tried.
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The whitespace in _OSC error reports is weird.  Improve it.
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch converts AML debugger into a loadable module.

Note that, it implements driver unloading at the level dependent on the
module reference count. Which means if ACPI debugger is being used by a
userspace program, "rmmod acpi_dbg" should result in failure.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by
userspace programs to access ACPICA debugger functionalities.

Known issue:
1. IO flush support
   acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can
   be used by acpi_dbg module to implement .flush() filesystem operation.
   While this patch doesn't go that far. It then becomes userspace tool's
   duty now to flush old commands before executing new batch mode commands.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This commit removes all CONFIG_.*{,_MODULE} in ACPI code, replacing it
with IS_ENABLED().
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After merging commit 712e960f (ACPI / PM: Attach ACPI power
domain only once) with commit 1dcc3d33 (ACPI / bus: Move ACPI
bus type registration) there is some duplicate code in
acpi_device_is_first_physical_node() and acpi_companion_match()
that can be moved to a separate routine and called from both
places.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>

Move the registration of the ACPI bus type to acpi_bus_init() and
avoid using ACPI going forward if it fails (too many things depend on
the presence of the ACPI bus type).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To reduce the size of scan.c and improve the readability of it, move
code related to device notification, the definitions of the ACPI bus
operations and the driver management code to drivers/acpi/bus.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To reduce the size of scan.c and improve the readability of it, move
code related device matching into drivers/acpi/bus.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 73f7d1ca "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early.  Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb "ACPI / init: Invoke early ACPI initialization later".

However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.

To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.

That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().

Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: NMarius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: NLee, Chun-Yi <jlee@suse.com>

Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.

acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.

We are going to implement stacked domains when GICv2m, GICv3, ITS
support are added.

CC: Marc Zyngier <marc.zyngier@arm.com>
Originally-by: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: NYijing Wang <wangyijing@huawei.com>
Tested-by: NMark Langsdorf <mlangsdo@redhat.com>
Tested-by: NJon Masters <jcm@redhat.com>
Tested-by: NTimur Tabi <timur@codeaurora.org>
Tested-by: NRobert Richter <rrichter@cavium.com>
Acked-by: NRobert Richter <rrichter@cavium.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Revert parts of f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA
switcheroo problem related to hotplug").

A previous commit 5493b31f0b55 ("PCI: Add pci_ignore_hotplug() to ignore
hotplug events for a device") added equivalent functionality implemented in
a different way for both acpiphp and pciehp.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>

There are global variables and functions not upstreamed to the ACPICA code
base.  Such symbols still can be referenced by external users as they are
listed in the acpixf.h.  This patch uses ACPI_GLOBAL and
ACPI_EXTERNAL_RETURN_STATUS mechanism to add stub support for such symbols.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The following warning message is triggered:
 WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2()
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298
 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011
  0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000
  ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563
  00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88
 Call Trace:
  [<ffffffff817c627b>] dump_stack+0x45/0x56
  [<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0
  [<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20
  [<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2
  [<ffffffff81d4bc5b>] early_ioremap+0x13/0x15
  [<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18
  [<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e
  [<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70
  [<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37
  [<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8
  [<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9
  [<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59
  [<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99
  [<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85
  [<ffffffff81d23043>] setup_arch+0x99d/0xcc6
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d1bbbe>] start_kernel+0x8b/0x415
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c
  [<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d
 ---[ end trace 11ae599a1898f4e7 ]---
when installing the following table during early stage:
 ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
The regression is caused by the size limitation of the x86 early IO mapping.

The root cause is:
 1. ACPICA doesn't split IO memory mapping and table mapping;
 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
    mechanism during early boot stage, which is more suitable for only IO
    mappings.

This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to
disable the table mapping during early stage and enabling it again for the
late stage. In this way, the normal code path is not affected. Then after
the code related to the root cause is cleaned up, the early checksum
verification can be easily re-enabled.

A new boot parameter - acpi_force_table_verification is introduced for
the platforms that require the checksum verification to stop loading bad
tables.

This fix also covers the checksum verification for the table overrides. Now
large tables can also be overridden using the initrd override mechanism.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is already acpi_bus_get_private_data() to get ACPI handle data
which is associated with acpi_bus_private_data_handler(). This patch
is to add acpi_bus_attach_private_data() to make a pair and facilitate
to attach and get data to/from ACPI handle.
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes the following issue:
If DSDT is customized, no local DSDT copy is needed.

References: https://bugzilla.kernel.org/show_bug.cgi?id=69711Signed-off-by: NEnrico Etxe Arte <goitizena.generoa@gmail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 2.6.35+ <stable@vger.kernel.org> # 2.6.35+
[rjw: Subject]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Make the handling of hotplug events in acpi_bus_notify() slightly
cleaner by using an extra local variable to indicate when
acpi_hotplug_schedule() should be called.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 1a699476 "ACPI / hotplug / PCI: Hotplug notifications from
acpi_bus_notify()" changed the root notify handler, acpi_bus_notify(),
to block unknown type norifications, but it overlooked the fact that
they might be propagated to drivers via the ->notify() callback.

Fix the problem by allowing drivers to receive unknown type
notifications via ->notify() as before.

Fixes: 1a699476 (ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify())
Reported-and-tested-by: NMantas Mikulėnas <grawity@gmail.com>
Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
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>

Replace acpi_evaluate_hotplug_ost() with acpi_evaluate_ost()
everywhere and drop the ACPI_HOTPLUG_OST symbol so that hotplug
_OST is supported unconditionally.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Since acpi_bus_notify() is executed on all notifications for all
devices anyway, make it execute acpi_device_hotplug() for all
hotplug events instead of installing notify handlers pointing to
the same function for all hotplug devices.

This change reduces both the size and complexity of ACPI-based device
hotplug code.  Moreover, since acpi_device_hotplug() only does
significant things for devices that have either an ACPI scan handler,
or a hotplug context with .eject() defined, and those devices
had notify handlers pointing to acpi_hotplug_notify_cb() installed
before anyway, this modification shouldn't change functionality.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a slight possibility for the ACPI device object pointed to
by adev in acpi_hotplug_notify_cb() to become invalid between the
acpi_bus_get_device() that it comes from and the subsequent dereference
of that pointer under get_device().  Namely, if acpi_scan_drop_device()
runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
queued up by it may delete the device object in question right after
a successful execution of acpi_bus_get_device() in acpi_bus_notify().

An analogous problem is present in acpi_bus_notify() where the device
pointer coming from acpi_bus_get_device() may become invalid before
it subsequent dereference in the "if" block.

To prevent that from happening, introduce a new function,
acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
except that it will grab a reference to the ACPI device object returned
by it and it will do that under the ACPICA's namespace mutex.  Then,
make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
ensure that the pointers used by them will not become stale at one
point.

In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
around put_device() to be used along with acpi_bus_get_acpi_device()
and make the (new) users of the latter use acpi_bus_put_acpi_device()
too.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

There is currently no facility in ACPI to express the hookup of voltage
regulators, the expectation is that the regulators that exist in the
system will be handled transparently by firmware if they need software
control at all. This means that if for some reason the regulator API is
enabled on such a system it should assume that any supplies that devices
need are provided by the system at all relevant times without any software
intervention.

Tell the regulator core to make this assumption by calling
regulator_has_full_constraints(). Do this as soon as we know we are using
ACPI so that the information is available to the regulator core as early
as possible. This will cause the regulator core to pretend that there is
an always on regulator supplying any supply that is requested but that has
not otherwise been mapped which is the behaviour expected on a system with
ACPI.

Should the ability to specify regulators be added in future revisions of
ACPI then once we have support for ACPI mappings in the kernel the same
assumptions will apply. It is also likely that systems will default to a
mode of operation which does not require any interpretation of these
mappings in order to be compatible with existing operating system releases
so it should remain safe to make these assumptions even if the mappings
exist but are not supported by the kernel.
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcd (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891Reported-and-tested-by: NMike Lothian <mike@fireburn.co.uk>
Reported-and-tested-by: <madcatx@atlas.cz>
Reported-and-tested-by: NJoaquín Aramendía <samsagax@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+

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>

Introduce a static inline function for setting the status field
of struct acpi_device on the basis of a supplied u32 number,
acpi_set_device_status(), and use it instead of the horrible
horrible STRUCT_TO_INT() macro wherever applicable.  Having done
that, drop STRUCT_TO_INT() (and pretend that it has never existed).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

There are two global hotplug notification handling routines in bus.c,
acpi_bus_check_device() and acpi_bus_check_scope(), that have never
been finished and don't do anything useful, so drop them.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This H/W error log driver (a.k.a eMCA driver) is implemented based on
http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html

After errors are captured, more detailed platform specific information
can be got via this new enhanced H/W error log driver. Most notably we
can track memory errors back to the DIMM slot silk screen label.
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

OSC_QUERY_TYPE isn't a "type"; it's an index into the _OSC Capabilities
Buffer of DWORDs.  Rename OSC_QUERY_TYPE, OSC_SUPPORT_TYPE, and
OSC_CONTROL_TYPE to OSC_QUERY_DWORD, etc., to make this clear.
No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>