Randconfig build by Fengguang's robot army reported:

   drivers/built-in.o: In function `extlog_print':
   >> acpi_extlog.c:(.text+0xcc719): undefined reference to `boot_cpu_physical_apicid'

The config had CONFIG_SMP=n so we picked up this definition from:

  <asm/cpu.h>: #define cpu_physical_id(cpu) boot_cpu_physical_apicid

But boot_cpu_physical_apicid is defined in arch/x86/kernel/apic/apic.c
which is only built if CONFIG_X86_LOCAL_APIC=y.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Cc: Chen Gong <gong.chen@linux.intel.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Link: http://lkml.kernel.org/r/6be3afdcad7968f7fb7c0b681e547b3e872e44dd.1383947368.git.tony.luck@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

cper.c contains code to decode and print "Common Platform Error Records".
Originally added under drivers/acpi/apei because the only user was in that
same directory - but now we have another consumer, and we shouldn't have
to force CONFIG_ACPI_APEI get access to this code.

Since CPER is defined in the UEFI specification - the logical home for
this code is under drivers/firmware/efi/
Acked-by: NMatt Fleming <matt.fleming@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Memory error reporting is much too verbose.  Most users do not care about
the DIMM internal bank/row/column information. Downgrade the fine details
to "pr_debug" status so that those few who do care can get them if they
really want to.  The detail information will be later be provided by
perf/trace interface.
Since things are still a bit scary, and users are sometimes overly
nervous, provide a reassuring message that corrected errors do not
generally require any further action.
Suggested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

After H/W error happens under FFM enabled mode, lots of information
are shown but new fields added by UEFI 2.4 (e.g. DIMM location) need to
be added.

Original-author: Tony Luck <tony.luck@intel.com>
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Acked-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

In latest UEFI spec(by now it is 2.4) memory error definition
for CPER (UEFI 2.4 Appendix N Common Platform Error Record)
adds some new fields. These fields help people to locate
memory error to an actual DIMM location.

Original-author: Tony Luck <tony.luck@intel.com>
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: NTony Luck <tony.luck@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>

We have a lot of confusing names of functions and data structures in
amongs the the error reporting code.  In particular the "apei" prefix
has been applied to many objects that are not part of APEI.  Since we
will be using these routines for extended error log reporting it will
be clearer if we fix up the names first.
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Commit aaf9d93b:
	ACPI / APEI: fix error status check condition for CPER
only catches condition check before print, but a similar check is
needed during printing CPER error sections.
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Two functions defined in device_pm.c, acpi_dev_pm_add_dependent()
and acpi_dev_pm_remove_dependent(), have no callers and may be
dropped, so drop them.

Moreover, they are the only functions adding entries to and removing
entries from the power_dependent list in struct acpi_device, so drop
that list too.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The mechanism causing devices depending on a given power resource
(that is, devices that can be in D0 only if that power resource is
on) to be resumed automatically when the power resource is turned
on (and their "inferred" power state becomes D0 as a result) is
inherently racy and in fact unnecessary.

It is racy, because if the power resource is turned on and then
immediately off, the device resume triggered by the first transition
to "on" may still happen, causing the power resource to be turned
on again.  That again will trigger the "resume of dependent devices"
mechanism, but if the devices in question are not in use, they will
be suspended in the meantime causing the power resource to be turned
off.  However, the "resume of dependent devices" will next resume
them again and so on.  In some cases (USB port PM in particular) that
leads to an endless busy loop of flipping the resource on and off
continuously.

It is needless, because whoever turns a power resource on will most
likely turn it off at some point and the devices that go into "D0"
as a result of turning it on will then go back into D3cold
(generally, the state they were in before).

Moreover, turning on all power resources a device needs to go into
D0 is not sufficient for a full transition into D0 in general.
Namely, _PS0 may need to be executed in addition to that in some
cases.  This means that the whole rationale of the "resume of
dependent devices" mechanism was incorrect to begin with and it's
best to remove it entirely.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 1696d9dc (ACPI: Remove the old /proc/acpi/event interface)
left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so
remove it from there.

[rjw: Changelog]
Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In acpi_resume_power_resources() resource_lock should be released
when acpi_power_get_state() fails and before passing to next power
resource on the list.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some links to projects web pages and e-mail addresses in ACPI/PM
documentation and Kconfig are outdated, so update them.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit caf5c03f (ACPI: Move acpi_bus_get_device() from bus.c to
scan.c) caused acpi_bus_get_device() to be exported using
EXPORT_SYMBOL_GPL(), but that broke some binary drivers in
existence, so revert that change.
Reported-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

"APIC" should be "ACPI" here.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes the issues indicated by the test results that
ipmi_msg_handler() is invoked in atomic context.

BUG: scheduling while atomic: kipmi0/18933/0x10000100
Modules linked in: ipmi_si acpi_ipmi ...
CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
Call Trace:
 <IRQ>  [<ffffffff814c4a1e>] dump_stack+0x19/0x1b
 [<ffffffff814bfbab>] __schedule_bug+0x46/0x54
 [<ffffffff814c73e0>] __schedule+0x83/0x59c
 [<ffffffff81058853>] __cond_resched+0x22/0x2d
 [<ffffffff814c794b>] _cond_resched+0x14/0x1d
 [<ffffffff814c6d82>] mutex_lock+0x11/0x32
 [<ffffffff8101e1e9>] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
 [<ffffffffa09e3f9c>] ipmi_msg_handler+0x23/0x166 [ipmi_si]
 [<ffffffff812bf6e4>] deliver_response+0x55/0x5a
 [<ffffffff812c0fd4>] handle_new_recv_msgs+0xb67/0xc65
 [<ffffffff81007ad1>] ? read_tsc+0x9/0x19
 [<ffffffff814c8620>] ? _raw_spin_lock_irq+0xa/0xc
 [<ffffffffa09e1128>] ipmi_thread+0x5c/0x146 [ipmi_si]
 ...

Also Tony Camuso says:

 We were getting occasional "Scheduling while atomic" call traces
 during boot on some systems. Problem was first seen on a Cisco C210
 but we were able to reproduce it on a Cisco c220m3. Setting
 CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
 tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.

 =================================
 [ INFO: inconsistent lock state ]
 2.6.32-415.el6.x86_64-debug-splck #1
 ---------------------------------
 inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
 ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&ipmi_device->tx_msg_lock){+.?...}, at: [<ffffffff81337a27>] ipmi_msg_handler+0x71/0x126
 {SOFTIRQ-ON-W} state was registered at:
   [<ffffffff810ba11c>] __lock_acquire+0x63c/0x1570
   [<ffffffff810bb0f4>] lock_acquire+0xa4/0x120
   [<ffffffff815581cc>] __mutex_lock_common+0x4c/0x400
   [<ffffffff815586ea>] mutex_lock_nested+0x4a/0x60
   [<ffffffff8133789d>] acpi_ipmi_space_handler+0x11b/0x234
   [<ffffffff81321c62>] acpi_ev_address_space_dispatch+0x170/0x1be

The fix implemented by this change has been tested by Tony:

 Tested the patch in a boot loop with lockdep debug enabled and never
 saw the problem in over 400 reboots.
Reported-and-tested-by: NTony Camuso <tcamuso@redhat.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As reported at https://bugzilla.kernel.org/show_bug.cgi?id=60829,
there still are cases in which do_find_child() doesn't choose the
ACPI device object it is "expected" to choose if there are more such
objects matching one PCI device present.  This particular problem may
be worked around by making do_find_child() return device obejcts witn
_STA whose result indicates that the device is enabled before device
objects without _STA if there's more than one device object to choose
from.

This change doesn't affect the case in which there's only one
matching ACPI device object per PCI device.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60829Reported-by: NPeter Wu <lekensteyn@gmail.com>
Tested-by: NFelix Lisczyk <felix.lisczyk@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ
resources returned in their _CRS method. However, Apple Macbook Air with
Haswell has LPSS devices enumerated from PCI bus instead and _CRS method
returns only an interrupt number (but the device has _HID set that causes
the scan handler to match it).

The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource
is found for the device and in case of Macbook Air it is never found. That
leads to a NULL pointer dereference in register_device_clock().

Correct this by always setting the pdata->dev_desc.
Reported-and-tested-by: NImre Kaloz <kaloz@openwrt.org>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Change the ordering of device hotplug locks in scan.c so that
acpi_scan_lock is always acquired after device_hotplug_lock.

This will make it possible to use device_hotplug_lock around some
code paths that acquire acpi_scan_lock safely (most importantly
system suspend and hibernation).  Apart from that, acpi_scan_lock
is platform-specific and device_hotplug_lock is general, so the
new ordering appears to be more appropriate from the overall
design viewpoint.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.

The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC.  Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.

But after 3b63aaa7 ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.

Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.

This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.

To avoid reintroducing the ASPM issue fixed by b8178f13 ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.

Tested successfully by myself.

[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org	# v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>

The current protocol for handling hot remove of containers is very
fragile and causes acpi_eject_store() to acquire acpi_scan_lock
which may deadlock with the removal of the device that it is called
for (the reason is that device sysfs attributes cannot be removed
while their callbacks are being executed and ACPI device objects
are removed under acpi_scan_lock).

The problem is related to the fact that containers are handled by
acpi_bus_device_eject() in a special way, which is to emit an
offline uevent instead of just removing the container.  Then, user
space is expected to handle that uevent and use the container's
"eject" attribute to actually remove it.  That is fragile, because
user space may fail to complete the ejection (for example, by not
using the container's "eject" attribute at all) leaving the BIOS
kind of in a limbo.  Moreover, if the eject event is not signaled
for a container itself, but for its parent device object (or
generally, for an ancestor above it in the ACPI namespace), the
container will be removed straight away without doing that whole
dance.

For this reason, modify acpi_bus_device_eject() to remove containers
synchronously like any other objects (user space will get its uevent
anyway in case it does some other things in response to it) and
remove the eject_pending ACPI device flag that is not used any more.
This way acpi_eject_store() doesn't have a reason to acquire
acpi_scan_lock any more and one possible deadlock scenario goes
away (plus the code is simplified a bit).
Reported-and-tested-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765Reported-and-tested-by: NDaniele Esposti <expo@expobrain.net>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some machines don't provide _TZD, so check the availability of it
before carrying out futher operations.

If _TZD is present, also check the result of its evaluation.

[rjw: Changelog]
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since v3.7 the acpi backlight driver doesn't work correctly in several
machines because ACPI code has different code for Windows 8, and the
rest.

The commit ea45ea70 (in v3.11-rc2) tried to fix this problem by using the
intel backlight driver, however it introduced several other issues in
different machines.

This patch fixes both regressions by blacklisting the win8 OSI, so we
are back to v3.6 behavior, and it should remain that way until the intel
backlight driver is fixed.

Since v3.7, users have been forced to fix the initial regression by
modifying the boot arguments (acpi_osi="!Windows 2012").

Once the Intel backlight driver works correctly for all machines, this
blacklist can be removed and that driver can be used instead.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60682Reported-by: NDanny Baumann <dannybaumann@web.de>
Reported-by: NPhilipp Richter <richterphilipp.pops@gmail.com>
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This follows what has already been done for the DeviceTree helpers. Move
the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update
documentation accordingly.

This also solves a problem reported by Jerry Snitselaar that we can't build
the ACPI I2C helpers as a module.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Revert commit c04c697c (ACPI / video: Always call acpi_video_init_brightness()
on init), because it breaks eDP backlight at 1920x1080 on Acer Aspire S3
for Trevor Bortins.

References: https://bugs.freedesktop.org/show_bug.cgi?id=68355Reported-and-bisected-by: NTrevor Bortins <enabfluw@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

No need to call sysfs_bin_attr_init, as the attribute is not dynamically
created.  Also, we renamed the attribute, so this one isn't even valid
anymore.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Attribute groups now can handle binary sysfs attributes, so clean up the
code here by using a binary attribute array.  This saves us the extra
call to create the binary attribute at saves 6 lines overall.

Cc: Len Brown <lenb@kernel.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

--
 I can take this in my driver-core tree if someone from ACPI acks it,
 otherwise, feel free to take it through the ACPI trees instead, just
 let me know.

 drivers/acpi/bgrt.c |   26 ++++++++++----------------
 1 file changed, 10 insertions(+), 16 deletions(-)

Bad things happen if ACPI hotplug events are handled during system
PM transitions, especially if devices are removed as a result.
To prevent those bad things from happening, acquire acpi_scan_lock
when a PM transition is started and release it when that transition
is complete or has been aborted.

This fixes resume lockup on my test-bed Acer Aspire S5 that happens
when Thunderbolt devices are disconnected from the machine while
suspended.

Also fixes the analogous problem for Mika Westerberg on an
Intel DZ77RE-75K board.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

In pstore write, set the section type to CPER_SECTION_TYPE_DMESG_COMPR
if the data is compressed. In pstore read, read the section type and
update the 'compressed' flag accordingly.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Backends will set the flag 'compressed' after reading the log from
persistent store to indicate the data being returned to pstore is
compressed or not.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Addition of new argument 'compressed' in the write call back will
help the backend to know if the data passed from pstore is compressed
or not (In case where compression fails.). If compressed, the backend
can add a tag indicating the data is compressed while writing to
persistent store.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add the missing iounmap() before return from erst_exec_move_data()
in the error handling case.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTony Luck <tony.luck@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>

It's unreadable to pass "-1" as trip parameter directly to
thermal_zone_bind_cooling_device().  Use THERMAL_TRIPS_NONE instead.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_THERMAL_FILE* macros are not used now, so remove them.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The acpi_thermal->lock now just is initialized when a thermal zone
device is added and destroyed when the thermal zone is removed.
It is never used in any other places, so remove it.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use of "preorder" and "postorder" was incorrect. The callbacks are
simply invoked during tree ascent and descent during the
depth-first walk.
Signed-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>

Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.

References: https://bugs.acpica.org/show_bug.cgi?id=431Signed-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>