commit a606dac3 adds support to link
devices which have _PRx, if a device does not have _PRx, a warning
message will be printed.

This commit is for ZPODD on Intel ZPODD capable platforms, on other
platforms, it has no problem if there is no power resource for this
device, so a warning here is not appropriate, change it to debug.
Reported-by: NBorislav Petkov <bp@amd64.org>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Commit 0090def6("ACPI: Add interface to register/unregister device
to/from power resources") used resource_lock to protect the devices list
that relies on power resource. It caused a mutex dead lock, as below

    acpi_power_on ---> lock resource_lock
      __acpi_power_on
        acpi_power_on_device
          acpi_power_get_inferred_state
            acpi_power_get_list_state ---> lock resource_lock

This patch adds a new mutex "devices_lock" to protect the devices list
and calls acpi_power_on_device in acpi_power_on, instead of
__acpi_power_on, after the resource_lock is released.

[rjw: Changed data type of a boolean variable to bool.]
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

It turns out that there are ACPI BIOSes defining device objects with
_PSx and without either _PSC or _PRx.  For devices corresponding to
those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
and their initial power states are regarded as unknown as a result.
If such a device is a parent of another power-manageable device, the
child cannot be put into a low-power state through ACPI, because
__acpi_bus_set_power() refuses to change power states of devices
whose parents' power states are unknown.

To work around this problem, observe that the ACPI power state of
a device cannot be higher-power (lower-number) than the power state
of its parent.  Thus, if the device's _PSC method or the
configuration of its power resources indicates that the device is
in D0, the device's parent has to be in D0 as well.  Consequently,
if the parent's power state is unknown when we've just learned that
its child's power state is D0, we can safely set the parent's
power.state field to ACPI_STATE_D0.
Tested-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

We need it in the radeon drm module to fetch
and verify the vbios image on UEFI systems.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

According to compiler warnings, several suspend/resume functions
in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add
#ifdefs to prevent them from being built in that case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

In commit 99b72508 "ACPI processor hotplug: Delay acpi_processor_start()
call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
patch will restore it back, fixing the tick_broadcast_mask regression:
	https://lkml.org/lkml/2012/7/30/169Signed-off-by: NFeng Tang <feng.tang@intel.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: <stable@vger.kernel.org> # 3.3+
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Otherwise you could run into:
WARN_ON in numa_register_memblks(), because node_possible_map is zero

References: https://bugzilla.novell.com/show_bug.cgi?id=757888

On this machine (ProLiant ML570 G3) the SRAT table contains:
  - No processor affinities
  - One memory affinity structure (which is set disabled)

CC: Per Jessen <per@opensuse.org>
CC: Andi Kleen <andi@firstfloor.org>
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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

If acpi_pci_osc_support() fails for the given flags, it doesn't make
sense to call acpi_pci_osc_control_set() down the road for the same
flags, because it will certainly fail too.  Moreover, problem
diagnostics is then harder, because it is not too easy to identify
the reason of the _OSC failure in those cases.

For this reason, check the status returned by acpi_pci_osc_support()
for PCIe support flags and do not attempt to execute
acpi_pci_osc_control_set() for those flags and print a message if
it's "failure".  For compatibility with the existing code, disable
ASPM in that case too.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

_GTS and _BFS were added to the suspend/resume flow
in the ACPI 2.0 specification.

Linux dutifully implemented _GTS and _BFS.
We discovered that it was rarely seen in systems
in the field.  Further, some of those systems had
AML so bogus that it could never work -- proof that
no other operating system supports _GTS and _BFS.
So we made _GTS and _BFS optional via modparam,
and disabled them by default.

But we've had to complicate some code to keep
this support in the kernel, as these methods are defined
to be evaluated very close to sleep entry and exit.
Indeed, no other AML is ever evaluated with interrupts off.

We have submitted a proposal for _GTS and _BFS
to be officially removed from the ACPI specification
on the next revision.  Here we remove it from Linux.
Signed-off-by: NLen Brown <len.brown@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

On Samsung X360, the BIOS will set a flag (VDRV) if the generic
ACPI backlight device is used. This flag will definitively break
the backlight interface (even the vendor interface) untill next
reboot. It's why we should prevent video.ko from being used here
and we can't rely on a later call to acpi_video_unregister().
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Instead of adding a big blacklist in video_detect.c to set
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR correctly, let external modules
promote or demote themselves when they know the generic video
module won't work.

Currently drivers where using acpi_video_unregister() directly
but:
- That didn't respect any acpi_backlight=[video|vendor] parameter
  provided by the user.
- Any later call to acpi_video_register() would still re-load the
  generic video module (and some gpu drivers are doing that).

This patch fix those two issues.
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Pavel Vasilyev <pavel@pavlinux.ru>
Signed-off-by: NLen Brown <len.brown@intel.com>

If CONFIG_ACPI_SLEEP is unset, the compiler complains that
pwr_btn_event_pending is defined but not used.  To silence the
warning, move the definition of pwr_btn_event_pending under an
appropriate #ifdef.
Reported-by: NPaul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NPaul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 6b66d958 should not have changed
EXPORT_SYMBOL_GPL to EXPORT_SYMBOL.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

With commit 6503e5df,
the value of /sys/class/thermal/thermal_zoneX/mode has been changed
from user/kernel to enabled/disabled.
Update the documentation so that users won't be confused.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some of the thermal drivers using the Generic Thermal Framework
require (all/some) trip points to be writeable. This patch makes
the trip point temperatures writeable on a per-trip point basis,
and modifies the required function call in thermal.c. This patch
also updates the Documentation to reflect the new change.
Signed-off-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

In the ac.c, power_supply_register()'s return value is not checked.

As a result, the driver's add() ops may return success
even though the device failed to initialize.

For example, some BIOS may describe two ACADs in the same DSDT.
The second ACAD device will fail to register,
but ACPI driver's add() ops returns sucessfully.
The ACPI device will receive ACPI notification and cause OOPS.

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

Remove the time field as it is not used.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Remove the usage field as it is not used.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Remove the latency_ticks field as it is not used.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Fixes issues like this:

i_aSL -> iASL
00-7_f -> 00-7F
local_fADT -> local_FADT
execute_oSI -> execute_OSI

Also, in function headers, the parameters are now translated to
lower case (with underscores if necessary.)
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_load_table and acpi_unload_parent_table to support
host-directed dynamic table load/unload. Intended to support
hotplug addition and removal of SSDTs.
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>

Split out the table load functions in preparation for addition
of new interfaces.
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>

ACPI 5.0 added PCC space ID.
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>

No functional change. Fixes some typos and linux divergences.
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>

Emit firmware error/warning messages where appropriate for table
and FADT errors.
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 new interfaces will be deployed across ACPICA in order to
point a finger directly at any detected BIOS issues -- such as
issues with ACPI tables, etc.

https://www.acpica.org/bugzilla/show_bug.cgi?id=843Signed-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>

Simplifies sharing of these functions.
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>

In an effort to be fair to bound processes,
acpi_pad periodically moves its forced-idle threads.

The default interval for moving the threads is 10 seconds.
Measurements show that reducing this to 1 second has no
power or performance impact, so reduce default to 1 second.
Signed-off-by: NLen Brown <len.brown@intel.com>

Fixes a problem that can occur when a lone package object is
wrapped with an outer package object in order to conform to
the ACPI specification. Can affect these predefined names:
_ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD

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

This problem was introduced in 3.4-rc1 by commit
6a99b1c9
(ACPICA: Object repair code: Support to add Package wrappers)
Reported-by: NVlastimil Babka <caster@gentoo.org>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Cc: <stable@vger.kernel.org> # 3.4
Signed-off-by: NLen Brown <len.brown@intel.com>

Adds basic support to allow multiple devices to be implicitly
notified.

This change is partially derived from original commit 981858bd("ACPI /
ACPICA: Implicit notify for multiple devices") by Rafael.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJung-uk Kim <jkim@freebsd.org>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Cleanup a couple of comments.
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>

Only used for iASL and AcpiExec.
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>

For each predefined name, emit a short description within
a comment.

https://www.acpica.org/bugzilla/show_bug.cgi?id=959Signed-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>

Many firmwares have a common register definition bug where 8-bit
access width is specified for a 32-bit register. Ideally this should
be fixed in the BIOS, but earlier versions of the kernel did not
complain, so fix that up silently.

This closes kernel bug #43282:
https://bugzilla.kernel.org/show_bug.cgi?id=43282Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NHuang Ying <ying.huang@intel.com>
Acked-by: NGary Hade <garyhade@us.ibm.com>
Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit d640113f introduced a regression on SMP
systems where the processor core with ACPI id zero is disabled
(typically should be the case because of hyperthreading).
The regression got spread through stable kernels.
On 3.0.X it got introduced via 3.0.18.

Such platforms may be rare, but do exist.
Look out for a disabled processor with acpi_id 0 in dmesg:
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)

This problem has been observed on a:
HP Proliant BL280c G6 blade

This patch restricts the introduced workaround to platforms
with nr_cpu_ids <= 1.
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This is an old suspend/resume lockup fix:

	commit 2780cc4660e1
	Author: Len Brown <len.brown@intel.com>
	Date:   Thu Dec 23 13:43:30 2004 -0500

	    [ACPI] Fix suspend/resume lockup issue
	    by leaving Bus Master Arbitration enabled.
	    The ACPI spec mandates it be disabled only for C3.

	    http://bugzilla.kernel.org/show_bug.cgi?id=3599Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The bug snuck back in in commit 2feec47d (ACPICA: ACPI 5: Support
for new FADT SleepStatus, SleepControl registers, 2012-02-14),
presumably by copy/pasting a copy of the code without that fix for the
legacy case.

On affected machines, after that commit, the machine locks up hard on
resume from suspend.  The same fix as seven years ago still works.

Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.
Reported-bisected-and-tested-by: NOctavio Alvarez <alvarezp@alvarezp.com>
Reported-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

On certain bios, resume hangs if cpus are allowed to enter idle states
during suspend [1].

This was fixed in apci idle driver [2].But intel_idle driver does not
have this fix. Thus instead of replicating the fix in both the idle
drivers, or in more platform specific idle drivers if needed, the
more general cpuidle infrastructure could handle this.

A suspend callback in cpuidle_driver could handle this fix. But
a cpuidle_driver provides only basic functionalities like platform idle
state detection capability and mechanisms to support entry and exit
into CPU idle states. All other cpuidle functions are found in the
cpuidle generic infrastructure for good reason that all cpuidle
drivers, irrepective of their platforms will support these functions.

One option therefore would be to register a suspend callback in cpuidle
which handles this fix. This could be called through a PM_SUSPEND_PREPARE
notifier. But this is too generic a notfier for a driver to handle.

Also, ideally the job of cpuidle is not to handle side effects of suspend.
It should expose the interfaces which "handle cpuidle 'during' suspend"
or any other operation, which the subsystems call during that respective
operation.

The fix demands that during suspend, no cpus should be allowed to enter
deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
ensures that. Not just that it also kicks all the cpus which are already
in idle out of their idle states which was being done during cpu hotplug
through a CPU_DYING_FROZEN callbacks.

Now the question arises about when during suspend should
cpuidle_uninstall_idle_handler() be called. Since we are dealing with
drivers it seems best to call this function during dpm_suspend().
Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
operations. In dpm_suspend_noirq(), it would be wise to place this call
before suspend_device_irqs() to avoid ugly interactions with the same.

Ananlogously, during resume.

References:
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
[2] http://marc.info/?l=linux-pm&m=133958534231884&w=2Reported-and-tested-by: NDave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

When the system is booted with some cpus offline, the idle
driver is not initialized. When a cpu is set online, the
acpi code call the intel idle init function. Unfortunately
this code introduce a dependency between intel_idle and acpi.

This patch is intended to remove this dependency by using the
notifier of intel_idle. This patch has the benefit of
encapsulating the intel_idle driver and remove some exported
functions.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>