The ->detach() callback for the PM domain has now been fully adopted,
thus there no users left of the acpi_dev_pm_detach() API. This allow us
to convert it into a static function.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As as preparation to simplify the detachment of devices from their PM
domains, we assign the ->detach() callback to genpd_dev_pm_detach().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a following AB-BA dependency between cpu_hotplug.lock and
cpuidle_lock:

1) cpu_hotplug.lock -> cpuidle_lock
enable_nonboot_cpus()
 _cpu_up()
  cpu_hotplug_begin()
   LOCK(cpu_hotplug.lock)
 cpu_notify()
  ...
  acpi_processor_hotplug()
   cpuidle_pause_and_lock()
    LOCK(cpuidle_lock)

2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue
 ...
 acpi_processor_cst_has_changed()
  cpuidle_pause_and_lock()
   LOCK(cpuidle_lock)
  get_online_cpus()
   LOCK(cpu_hotplug.lock)

Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).

Spotted by lockdep.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _SUN device indentification object is not guaranteed to return
the same value every time it is executed, so we should not cache its
return value, but rather execute it every time as needed.  If it is
cached, an incorrect stale value may be used in some situations.

This issue was exposed by commit 202317a5 (ACPI / scan: Add
acpi_device objects for all device nodes in the namespace).  Fix it
by avoiding to cache the return value of _SUN.

Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Clevo W350etq's EC will not produce GPE interrupt some time after
booting. The ACPI notify event won't trigger when the issue takes
place. After debugging, adding msi quirk for the machine can fix
the issue. This patch is to add msi quirk for the machine.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Reported-and-tested-by: qbanin@gmail.com
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515Reported-and-tested-by: NHohahiu <rakothedin@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some laptops have a working acpi_video backlight control, and using native
backlight on these causes a regression where backlight control does not work
when userspace is not handling brightness key events. Disable native_backlight
on these to fix this.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691Reported-and-tested-by: NAndre Müller <andre.muller@web.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 751109aa ("ACPI / video: Change the default for
video.use_native_backlight to 1") has changed the default for
use_native_backlight from 0 to 1, but instead of changing
use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1,
it has changed use_native_backlight_param to 1.

This causes acpi_video_use_native_backlight() to always think that a value was
specified through the param, making it impossible to add a dmi based quirk
to force 0 now that the default is 1.

This fixes this by restoring the use_native_backlight_param default to -1, and
instead setting the use_native_backlight_dmi default to true.

Fixes: 751109aa (ACPI / video: Change the default for video.use_native_backlight to 1)
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Adds ACPICA kernel runtime support to validate contents/format
of the _DSD package, similar to the iASL support. Ported by
Mika Westerberg.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
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>

Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
We need to keep IRQ assignment for PCI devices during runtime power
management, otherwise it may cause failure of device wakeups.

Commit 3eec5952 "x86, irq, PCI: Keep IRQ assignment for PCI
devices during suspend/hibernation" has fixed the issue for suspend/
hibernation, we also need the same fix for runtime device sleep too.

Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271Reported-and-Tested-by: NEmanueL Czirai <amanual@openmailbox.org>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: EmanueL Czirai <amanual@openmailbox.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Grant Likely <grant.likely@linaro.org>
Link: http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Enable more identifiers for the existing devices for Intel Braswell and
Cherryview.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.

By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.

Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by: NAlexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a platform refusing to respond QR_EC when SCI_EVT isn't set
(Acer Aspire V5-573G).

Currently, we rely on the behaviour that the EC firmware can respond
something (for example, 0x00 to indicate "no outstanding events") to
QR_EC even when SCI_EVT is not set, but the reporter has complained
about AC/battery pluging/unpluging and video brightness change delay
on that platform.

This is because the work item that has issued QR_EC has to wait until
timeout in this case, and the _Qxx method evaluation work item queued
after QR_EC one is delayed.

It sounds reasonable to fix this issue by:
 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
    driver's main state machine.
 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
    to a seperate IRQ handling thread.

This patch fixes this issue using solution 1.

By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
handle such platform in the EC driver's main state machine. This patch
enhances the state machine in this way to survive with such malfunctioning
EC firmware.

Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
on the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

Fixes: c0d65341 ACPI / EC: Fix race condition in ec_transaction_completed()
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by: NAlexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, notify callbacks for fixed button events are run from
interrupt context.  That is not necessary and after commit 0bf6368e
(ACPI / button: Add ACPI Button event via netlink routine) it causes
netlink routines to be called from interrupt context which is not
correct.

Also, that is different from non-fixed device events (including
non-fixed button events) whose notify callbacks are all executed from
process context.

For the above reasons, make fixed button device notify callbacks run
in process context which will avoid the deadlock when using netlink
to report button events to user space.

Fixes: 0bf6368e (ACPI / button: Add ACPI Button event via netlink routine)
Link: https://lkml.org/lkml/2014/8/21/606Reported-by: NBenjamin Block <bebl@mageta.org>
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
[rjw: Function names, subject and changelog.]
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We generally don't allow ACPI drivers to bind to ACPI device objects
that companion "physical" device objects are created for to avoid
situations in which two different drivers may attempt to handle one
device at the same time.  Recent ACPI device enumeration rework
extended that approach to ACPI PNP devices by starting to use a scan
handler for enumerating them.  However, we previously allowed ACPI
drivers to bind to ACPI device objects with existing PNP device
companions and changing that led to functional regressions on some
systems.

For this reason, add a special check for PNP devices in
acpi_device_probe() so that ACPI drivers can bind to ACPI device
objects having existing PNP device companions as before.

Fixes: eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971Reported-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: NDirk Griesbach <spamthis@freenet.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

capacity_now should be assigned after comparing it to design_capacity.

Otherwise warning is printed even when capacity_now before assignment is
equal to design_capacity, making the check useless and "current charge level"
wrong (it should be higher than, not equal to, "maximum charge level", which
is full_charge_capacity):

"battery: reported current charge level (56410) is higher than reported
maximum charge level (56410)."

Fixes: 232de514 (ACPI / battery: fix wrong value of capacity_now reported when fully charged)
Signed-off-by: NMariusz Ceier <mceier+kernel@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
[rjw: Subject]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
We need to keep IRQ assignment for PCI devices during suspend/hibernation,
otherwise it may cause failure of suspend/hibernation due to:
1) Device driver calls pci_enable_device() to allocate an IRQ number
   and register interrupt handler on the returned IRQ.
2) Device driver's suspend callback calls pci_disable_device() and
   release assigned IRQ in turn.
3) Device driver's resume callback calls pci_enable_device() to
   allocate IRQ number again. A different IRQ number may be assigned
   by IOAPIC driver this time.
4) Now the hardware delivers interrupt to the new IRQ but interrupt
   handler is still registered against the old IRQ, so it breaks
   suspend/hibernation.

To fix this issue, we keep IRQ assignment during suspend/hibernation.
Flag pci_dev.dev.power.is_prepared is used to detect that
pci_disable_device() is called during suspend/hibernation.
Reported-and-Tested-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1407478071-29399-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach
is not set.  In acpi_scan_attach_handler(), the acpi_device->handler will
not be initialized.

In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL.
If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel
will panic.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
 IP: [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
 PGD 0
 Oops: 0000 [#1] SMP
 Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E)
 CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G            E 3.16.0-rc7--3.16-rc7-tangchen+ #20
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
 Workqueue: kacpi_hotplug acpi_hotplug_work_fn
 task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000
 RIP: 0010:[<ffffffff813e318f>]  [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
 RSP: 0000:ffff880018257da8  EFLAGS: 00000246
 RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246
 RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0
 R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003
 R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
 Stack:
  00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58
  ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00
  0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480
 Call Trace:
  [<ffffffff813dc31d>] acpi_hotplug_work_fn+0x1e/0x29
  [<ffffffff8108eefb>] process_one_work+0x17b/0x460
  [<ffffffff8108f69d>] worker_thread+0x11d/0x5b0
  [<ffffffff8108f580>] ? rescuer_thread+0x3a0/0x3a0
  [<ffffffff81096811>] kthread+0xe1/0x100
  [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0
  [<ffffffff816cc6bc>] ret_from_fork+0x7c/0xb0
  [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0

This patch fixes this problem by checking if acpi_device->handler is NULL
in acpi_scan_hot_remove().

Fixes: d22ddcbc (ACPI / hotplug: Add demand_offline hotplug profile flag)
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[rjw: Subject]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CPU hotplug happens during S2RAM and CPU notify event will be CPU_XXX_FROZEN.
acpi_cpu_soft_notify() ignores to check these events. This also may make
acpi_cpu_soft_notify() fall into sleep during CPU_DYING/STARTING_FROZEN
events which don't allow callbacks to sleep. This patch is to fix it.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

INT3438 is the ADSP device on Wildcat Point platform
with 2 DW DMA engines built In. The DMA engines are
used for DSP FW loading and audio data transferring.
These DMA engine probing need the clock, without it,
probing may failed and can't go forward.

Add LPSS device "INT3438" for Wildcat Point PCH, to
provide clock for its ADSP DMA engine probing.
Signed-off-by: NJie Yang <yang.jie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

0 is ascii for NULL. Hex digit matching should be from '0'.
Faulty version returns true for #,$,%,& etc.
Signed-off-by: NArjun Sreedharan <arjun024@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Full support for _CCA.
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>

New value for the Notify() operator.
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>

Adds full support for _DSD. David Box.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
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>

Simplifies timing of things like control method execution.

[zetalog: fixing 64-bit division link error]
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>

This adds a -u option to acpi_help to display all known ACPI UUIDs.
Some existing files in the core code have been restructured.
Three new files.

[zetalog: changing drivers/acpi/acpica/Makefile accordingly]
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>

The bug can be reproduced by using a format that do not have the width.prec
specified after a format that have the width.prec specified. The second
formatted output will be wrong. The root cause is acpi_ut_vsnprintf()
doesn't reset the specifiers to the default values.

This patch fixes this issue. BZ 1094. Reported by Yizhe Wang, fixed by
Lv Zheng.

Since acpi_ut_vprintf() is only enabled for specific OSPM now, this patch
doesn't affect Linux kernel.

Link: https://bugs.acpica.org/show_bug.cgi?id=1094Reported-and-tested-by: NYizhe Wang <yizhe.wang@intel.com>
Signed-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>

Arguments that have no associated % format specifier.
Apparently these are not caught by any current compilers.
ACPICA BZ 1090. Sascha Wildner.

Currently, this patch only affects applications under the
toos/power/acpi folder.

Link: https://bugs.acpica.org/show_bug.cgi?id=1090Signed-off-by: NSascha Wildner <swildner@gmail.com>
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>

Fix some issues detected by acpisrc utility.
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>

This change adds support to disassemble a UUID back to the original
ToUUID operator. It will detect a UUID within a standard AML Buffer.
Also, a description of the UUID is emitted for "known" UUIDs, defined
as UUIDs that are defined in the ACPI specification.

Since this is a change for disassembler which is not shipped in the
Linux kernel, the Linux kernel is not affected.
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>

warning: cast from function call of type 'char *' to non-matching type 'long unsigned int'

Since acpi_ut_format_number() hasn't been enabled for the Linux kernel,
this patch doesn't affect the Linux kernel.
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>

Logical processors with APIC ID values of 255 and greater are
required to have a Processor Device object and must convey the
processor's APIC information to OSPM using the Processor Local
X2APIC structure, but not until ACPI 5.1, X2APIC structure was
not supported in _MAT method.

_MAT is needed for CPU hotplug and system with more than 255
CPUs will definitely need X2APIC structure, so add its support
in map_mat_entry() to make it possible to get local x2apic id
via _MAT based on ACPI 5.1.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123565Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

NVS region is saved and restored unconditionally for machines without
nvs_nosave quirk during S3. Tested some new machines and the operation
is not necessary. Saving NVS region also affects S2RAM speed. The time of
NVS saving and restoring depends on the size of NVS region and it consumes
7~10ms normally.

This patch is to make machines produced from 2012 to now not saving NVS region
to accelerate S3.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI device enumeration code in Linux assumes that buttons always
are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them
which leads to undesirable side effects.  Namely, that function sets
up implicit device wake notification mechanism for a given GPE if
there is no handler method in the ACPI namespace, which from the
ACPICA's perspective means that there always is a way to handle
that GPE if enabled.  However, we don't handle wake notify events
for buttons, so if there are no handler methods for their GPEs in
the namespace, enabling a button GPE at run time leads to a GPE
storm in some cases (the GPE triggers, ACPICA carries out the
implicit wake notification for it which isn't handled, so the
GPE triggers again and so on).

To prevent that from happening use acpi_mark_gpe_for_wake()
instead of acpi_setup_gpe_for_wake() for buttons which will cause
ACPICA to only enable button GPEs if there are handler methods for
the in the namespace.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit c49dbfed2bc069d0038ea7e1294409bfde7c2c8c

Some potential callers of acpi_setup_gpe_for_wake may know in advance that
there won't be any notify handlers installed for device wake notifications
from the given GPE (one example is a button GPE in Linux). For these cases,
acpi_mark_gpe_for_wake should be used instead of acpi_setup_gpe_for_wake.
This will set the ACPI_GPE_CAN_WAKE flag for the GPE without trying to
setup implicit wake notification for it (since there's no handler method).
Rafael Wysocki.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>

ACPICA commit 23b5a8542283af28c3a3a4e3f81096d6e2569faa

There is no point in enabling a GPE that has no handler or
GPE method. At worst, it can cause GPE floods.
Rafael Wysocki.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>

As there is only CONFIG_ACPI=n processing in the <linux/acpi.h>, it is not
safe to include <acpi/acpi.h> directly for source out of Linux ACPI
subsystems.

This patch adds error messaging to warn developers of such wrong
inclusions.

In order not to be bisected and reverted as a wrong commit, warning
messages are carefully split into a seperate patch other than the wrong
inclusion cleanups.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.

Do that in three places in the ACPI device PM code.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>