GitLab

This patch makes acpi_init() call acpi_wakeup_device_init() directly.
Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7).

acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which
is populated when ACPI devices are enumerated by acpi_init() ->
acpi_scan_init().  Using late_initcall is certainly enough to make
sure acpi_wakeup_device_list is populated, but it is more than
necessary.  We can just as easily call acpi_wakeup_device_init()
directly from acpi_init(), which avoids the initcall magic.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

A number of things that shouldn't be exposed outside the ACPI core
were declared in include/acpi/acpi_drivers.h, where anybody can
see them.  This patch moves those declarations to a new "internal.h"
inside drivers/acpi.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

also, delete sleep/ and delete ACPI_CFLAGS from Makefile
Signed-off-by: Len Brown <len.brown@intel.com>

External driver files should not include any private acpica headers.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI_FUNCTION_TRACE is an internal acpica function.
remove ACPI_FUNCTION_TRACE
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Disabling gpe might interfere with gpe detection/handling,
thus producing "interrupt not handled" errors.
Ironically, disabling of GPE from interrupt context is already
under spinlock, so only userspace needs to start using it.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

* Introduce function acpi_pm_device_sleep_wake() for enabling and
  disabling the system wake-up capability of devices that are power
  manageable by ACPI.

* Introduce function acpi_bus_can_wakeup() allowing other (dependent)
  subsystems to check if ACPI is able to enable the system wake-up
  capability of given device.

* Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
  for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().

* Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
  for the ACPI 'driver' make it use acpi_bus_can_wakeup().

* Move the PME# handlig code out of pci_enable_wake() and split it
  into two functions, pci_pme_capable() and pci_pme_active(),
  allowing the caller to check if given device is capable of
  generating PME# from given power state and to enable/disable the
  device's PME# functionality, respectively.

* Modify pci_enable_wake() to use the new ACPI callbacks and the new
  PME#-related functions.

* Drop the generic .platform_enable_wakeup() callback that is not
  used any more.

* Introduce device_set_wakeup_capable() that will set the
  power.can_wakeup flag of given device.

* Rework PCI device PM initialization so that, if given device is
  capable of generating wake-up events, either natively through the
  PME# mechanism, or with the help of the platform, its
  power.can_wakeup flag is set and its power.should_wakeup flag is
  unset as appropriate.

* Make ACPI set the power.can_wakeup flag for devices found to be
  wake-up capable by it.

* Make the ACPI wake-up code enable/disable GPEs for devices that
  have the wakeup.flags.prepared flag set (which means that their
  wake-up power has been enabled).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

The currect ACPI code attempts to execute _PSW at three different
places and in one of them only it tries to execute _DSW before _PSW,
which is inconsistent with the other two cases.

Move the execution of _DSW and _PSW into a separate function called
acpi_device_sleep_wake() and call it wherever appropriate instead of
executing _DSW and/or _PSW directly.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

S4 suspend to disk will disable GPE's permanently
because acpi_gpe_sleep_prepare() does not have
a counterpart at resume time.  Thus, those devices
became unavailable for wakeup from subsequent
S3 suspend-to-ram.

Here acpi_gpe_sleep_prepare() is removed, and upon suspend
acpi_enable_wakeup_device() gets its functionality.
Upon resume, acpi_disable_wakeup_device() restores the state.

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

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Len Brown <len.brown@intel.com>

As it was a synonym for (CONFIG_ACPI && CONFIG_X86),
the ifdefs for it were more clutter than they were worth.

For ia64, just add a few stubs in anticipation of future
S3 or S4 support.
Signed-off-by: Len Brown <len.brown@intel.com>

Fixing wrong description for acpi_gpe_sleep_prepare().

acpi_gpe_sleep_prepare() had only used on power off and was changed
to also used on entering some sleep state. However its description
isn't changed yet.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Internal BIOS names like these should be exposed
to the user as little as possible:

ACPI wakeup devices: C069 C0CE C1D1 C0DE C1D4

Eventually, the "wakeup" property of a device should be exported via the
device tree, not by a printk of an internal BIOS name.  For the hard-core,
these are still available in /proc/acpi/wakeup_devices, just not
printed to dmesg.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=4320

Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Len Brown <len.brown@intel.com>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!