Commit Graph

193 Commits

Author SHA1 Message Date
Linus Torvalds 476525004a Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
Pull ACPI & power management update from Len Brown:
 "Re-write of the turbostat tool.
     lower overhead was necessary for measuring very large system when
     they are very idle.

  IVB support in intel_idle
     It's what I run on my IVB, others should be able to also:-)

  ACPICA core update
     We have found some bugs due to divergence between Linux and the
     upstream ACPICA base.  Most of these patches are to reduce that
     divergence to reduce the risk of future bugs.

  Some cpuidle updates, mostly for non-Intel
     More will be coming, as they depend on this part.

  Some thermal management changes needed by non-ACPI systems.

  Some _OST (OS Status Indication) updates for hot ACPI hot-plug."

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (51 commits)
  Thermal: Documentation update
  Thermal: Add Hysteresis attributes
  Thermal: Make Thermal trip points writeable
  ACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register() return value check
  tools/power: turbostat: fix large c1% issue
  tools/power: turbostat v2 - re-write for efficiency
  ACPICA: Update to version 20120711
  ACPICA: AcpiSrc: Fix some translation issues for Linux conversion
  ACPICA: Update header files copyrights to 2012
  ACPICA: Add new ACPI table load/unload external interfaces
  ACPICA: Split file: tbxface.c -> tbxfload.c
  ACPICA: Add PCC address space to space ID decode function
  ACPICA: Fix some comment fields
  ACPICA: Table manager: deploy new firmware error/warning interfaces
  ACPICA: Add new interfaces for BIOS(firmware) errors and warnings
  ACPICA: Split exception code utilities to a new file, utexcep.c
  ACPI: acpi_pad: tune round_robin_time
  ACPICA: Update to version 20120620
  ACPICA: Add support for implicit notify on multiple devices
  ACPICA: Update comments; no functional change
  ...
2012-07-26 14:28:55 -07:00
Len Brown ec033d0a02 Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', 'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release 2012-07-26 00:03:58 -04:00
Rafael J. Wysocki d91ee328c1 ACPI / PM: Drop PM callbacks from the ACPI bus type
Since the ACPI bus type's PM callbacks only execute the driver ones
without doing anything else, they can be dropped, because the driver
callbacks will be executed by the PM core directly if bus type
(or other subsystem) callbacks are not present.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-01 13:31:06 +02:00
Rafael J. Wysocki 13db85528f ACPI / PM: Do not execute legacy driver PM callbacks
Since all ACPI drivers in the tree should have been switched
to power management handling based on struct dev_pm_ops,
modify the ACPI bus type driver so that is doesn't execute
legacy driver power management callbacks from the functions
pointed to by the members of the acpi_bus_pm structure.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-01 13:31:06 +02:00
Rafael J. Wysocki 67699c5f0c ACPI / PM: Make acpi_bus_type use driver struct dev_pm_ops callbacks
Modify acpi_bus_type so that it executes PM callbacks provided
by drivers through their struct dev_pm_ops objects, if present,
while still allowing the legacy ACPI PM callbacks to take precedence.
This will make it possible to convert ACPI drivers one by one to
handling PM through struct dev_pm_ops instead of the legacy way.

The code added by this change is temporary and will be removed
when all of the drivers in question have been switched over to
the PM handling based on struct dev_pm_ops.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-01 13:30:59 +02:00
Rafael J. Wysocki 707156e600 ACPI / PM: Make acpi_bus_type use struct dev_pm_ops for PM handling
Make the acpi_bus_type bus type define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct bus_type.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-01 13:30:58 +02:00
Rafael J. Wysocki 17621e11fd ACPI / PM: Drop pm_message_t argument from device suspend callback
None of the drivers implementing the ACPI device suspend callback
uses the pm_message_t argument of it, so this argument may be dropped
entirely from that callback.  This will simplify switching the ACPI
bus type to PM handling based on struct dev_pm_ops.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-01 13:30:58 +02:00
Toshi Kani c4753e57b7 ACPI: Add _OST support for sysfs eject
Changed acpi_bus_hot_remove_device() to support _OST. This function is
also changed to global so that it can be called from hotplug notify
handlers to perform hot-remove operation.

Changed acpi_eject_store(), which is the sysfs eject handler. It checks
eject_pending to see if the request was originated from ACPI eject
notification. If not, it calls _OST(0x103,84,) per Figure 6-37 in ACPI
5.0 spec.

Added eject_pending bit to acpi_device_flags. This bit is set when the
kernel has received an ACPI eject notification, but does not initiate
its hot-remove operation by itself.

Added struct acpi_eject_event. This structure is used to pass extended
information to acpi_bus_hot_remove_device(), which has a single argument
to support asynchronous call

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2012-06-04 01:09:19 -04:00
Daniel Drake c10d7a1384 ACPI / PM: Generate wakeup events on fixed power button
When the system is woken up by the ACPI fixed power button, currently there
is no way of userspace becoming aware that the power button was pressed.

OLPC would like to know this, so that we can respond appropriately.
For example, if the system was woken up by a network packet, we know
we can go back to sleep very quickly. But if the user explicitly woke the
system with the power button, we're going to want to stay awake for a
while.

The wakeup count mechanism seems like a good fit for communicating this.
Mark the fixed power button as wakeup-enabled, and increment its wakeup
counter when the system is woken with the power button. (The wakeup counter
is also incremented when the power button is pressed during system
operation; this is already handled by an existing acpi-button codepath).

Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-29 21:20:23 +02:00
Rafael J. Wysocki 5c7dd710f6 ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
Commit 1cc0c998fd ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.

First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.

Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power().  Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.

Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3.  However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare.  This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now.  In particular, some unused graphics adapters are not turned
off as a result.

To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.

This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.

References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-17 16:16:16 -07:00
Lin Ming 1cc0c998fd ACPI: Fix D3hot v D3cold confusion
Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
in some places, but D3cold in other places.

After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
and all references to D3hot use ACPI_STATE_D3_HOT.

ACPI's _PR3 method is used to enter both D3hot and D3cold states.
What distinguishes D3hot from D3cold is the presence _PR3
(Power Resources for D3hot)  If these resources are all ON,
then the state is D3hot.  If _PR3 is not present,
or all _PR0 resources for the devices are OFF,
then the state is D3cold.

This patch applies after Linux-3.4-rc1.
A future syntax cleanup may remove ACPI_STATE_D3
to emphasize that it always means ACPI_STATE_D3_COLD.

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-05 01:19:52 -04:00
Len Brown ec612fcf43 Merge branch 'd3' into release
Conflicts:
	drivers/acpi/sleep.c

This was a text conflict between
a2ef5c4fd4
(ACPI: Move module parameter gts and bfs to sleep.c)

which added #include <linux/module.h>

and

b24e509885
(ACPI, PCI: Move acpi_dev_run_wake() to ACPI core)

which added #include <linux/pm_runtime.h>

The resolution was to take them both.

Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30 16:21:26 -04:00
Alex He 3723997877 ACPI: Clean redundant codes in scan.c
Clean the redundant codes of apci_bus_get_power_flags().

Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30 04:00:16 -04:00
Zhang Rui 3ebc81b893 ACPI: Introduce ACPI D3_COLD state support
If a device has _PR3, it means the device supports D3_COLD.
Add the ability to validate and enter D3_COLD state in ACPI.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30 01:47:00 -04:00
Thomas Meyer 581de59e8d ACPI: use kstrdup()
Use kstrdup rather than duplicating its implementation

 The semantic patch that makes this output is available
 in scripts/coccinelle/api/kstrdup.cocci.

 More information about semantic patching is available at
 http://coccinelle.lip6.fr/

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-11-06 19:13:44 -05:00
Rafael J. Wysocki 7bed50c5ed ACPI / PM: Avoid infinite recurrence while registering power resources
There is at least one BIOS with a DSDT containing a power resource
object with a _PR0 entry pointing back to that power resource.  In
consequence, while registering that power resource
acpi_bus_get_power_flags() sees that it depends on itself and tries
to register it again, which leads to an infinitely deep recurrence.
This problem was introduced by commit bf325f9538
(ACPI / PM: Register power resource devices as soon as they are
needed).

To fix this problem use the observation that power resources cannot
be power manageable and prevent acpi_bus_get_power_flags() from
being called for power resource objects.

References: https://bugzilla.kernel.org/show_bug.cgi?id=31872
Reported-and-tested-by: Pascal Dormeau <pdormeau@free.fr>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Len Brown <lenb@kernel.org>
Cc: stable@kernel.org
2011-04-26 11:33:18 +02:00
Rafael J. Wysocki 5190726765 ACPI: Remove the wakeup.run_wake_count device field
The wakeup.run_wake_count ACPI device field is only used by the PCI
runtime PM code to "protect" devices from being prepared for
generating wakeup signals more than once in a row.  However, it
really doesn't provide any protection, because (1) all of the
functions it is supposed to protect use their own reference counters
effectively ensuring that the device will be set up for generating
wakeup signals just once and (2) the PCI runtime PM code uses
wakeup.run_wake_count in a racy way, since nothing prevents
acpi_dev_run_wake() from being called concurrently from two different
threads for the same device.

Remove the wakeup.run_wake_count ACPI device field which is
unnecessary, confusing and used in a wrong way.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-02-24 19:58:53 +01:00
Rafael J. Wysocki d57d09a480 ACPI: Drop device flag wake_capable
The wake_capable ACPI device flag is not necessary, because it is
only used in scan.c for recording the information that _PRW is
present for the given device.  That information is only used by
acpi_add_single_object() to decide whether or not to call
acpi_bus_get_wakeup_device_flags(), so the flag may be dropped
if the _PRW check is moved to acpi_bus_get_wakeup_device_flags().
Moreover, acpi_bus_get_wakeup_device_flags() always returns 0,
so it really should be void.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 05:06:01 -05:00
Rafael J. Wysocki 86e4e20e8a ACPI: Always check if _PRW is present before trying to evaluate it
Before evaluating _PRW for devices that are reported as inactive or
not present by their _STA control methods we should check if those
methods are actually present (otherwise the evaulation of _PRW will
obviously fail and a scary message will be printed unnecessarily).

Reported-by: Andreas Mohr <andi@lisas.de>
Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 05:05:50 -05:00
Len Brown fb4af417cc Merge branch 'wakeup-etc-rafael' into release 2011-01-12 04:55:46 -05:00
Len Brown 07bf280521 Merge branch 'power-resource' into release 2011-01-12 04:55:28 -05:00
Rafael J. Wysocki bf325f9538 ACPI / PM: Register power resource devices as soon as they are needed
Depending on the organization of the ACPI namespace, power resource
device objects may generally be scanned after the "regular" device
objects that they are referred from through _PRn.  This, in turn, may
cause acpi_bus_get_power_flags() to attempt to access them through
acpi_bus_init_power() before they are registered (and initialized by
acpi_power_driver).  [This is not a theoretical issue, it actually
happens for one PnP device on my testbed HP nx6325.]

To fix this problem, make acpi_bus_get_power_flags() attempt to
register power resource devices as soon as they have been found in
the _PRn output for any other devices.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 04:48:45 -05:00
Rafael J. Wysocki 97d9a9e9f5 ACPI / PM: Register acpi_power_driver early
The ACPI device driver used for handling power resources,
acpi_power_driver, creates a struct acpi_power_resource object for
each ACPI device representing a power resource.  These objects are
then used when setting and reading the power states of devices using
the corresponding power resources.  Unfortunately, acpi_power_driver
is registered after acpi_scan_init() that may add devices using the
power resources before acpi_power_driver has a chance to create
struct acpi_power_resource objects for them (specifically, the power
resources may be referred to during the scanning process through
acpi_bus_get_power() before they have been initialized).

As the first step towards fixing this issue, move the registration
of acpi_power_driver into acpi_scan_init() so that power resource
devices can be initialized by it as soon as they have been found in
the namespace.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 04:48:45 -05:00
Rafael J. Wysocki ade3e7fef7 ACPI / PM: Add function for device power state initialization
Add function acpi_bus_init_power() for getting the initial power
state of an ACPI device and reference counting its power resources
as appropriate.

Make acpi_bus_get_power_flags() use the new function instead of
acpi_bus_get_power() that updates device->power.state without
reference counting the device's power resources.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 04:48:44 -05:00
Lin Ming bba63a296f ACPICA: Implicit notify support
This feature provides an automatic device notification for wake devices
when a wakeup GPE occurs and there is no corresponding GPE method or
handler. Rather than ignoring such a GPE, an implicit AML Notify
operation is performed on the parent device object.
This feature is not part of the ACPI specification and is provided for
Windows compatibility only.

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 04:27:00 -05:00
Lin Ming 3a37898d50 ACPICA: Rename some function and variable names
Some function and variable names are renamed to be consistent with
ACPICA code base.

acpi_raw_enable_gpe -> acpi_ev_add_gpe_reference
acpi_raw_disable_gpe -> acpi_ev_remove_gpe_reference
acpi_gpe_can_wake -> acpi_setup_gpe_for_wake
acpi_gpe_wakeup -> acpi_set_gpe_wake_mask
acpi_update_gpes -> acpi_update_all_gpes
acpi_all_gpes_initialized -> acpi_gbl_all_gpes_initialized
acpi_handler_info -> acpi_gpe_handler_info
...

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 04:24:40 -05:00
Rafael J. Wysocki f2b56bc808 ACPI / PM: Use device wakeup flags for handling ACPI wakeup devices
There are ACPI devices (buttons and the laptop lid) that can wake up
the system from sleep states and have no "physical" companion
devices.  The ACPI subsystem uses two flags, wakeup.state.enabled and
wakeup.flags.always_enabled, for handling those devices, but they
are not accessible through the standard device wakeup infrastructure.
User space can only control them via the /proc/acpi/wakeup interface
that is not really convenient (e.g. the way in which devices are
enabled to wake up the system is not portable between different
systems, because it requires one to know the devices' "names" used in
the system's ACPI tables).

To address this problem, use standard device wakeup flags instead of
the special ACPI flags for handling those devices.  In particular,
use device_set_wakeup_capable() to mark the ACPI wakeup devices
during initialization and use device_set_wakeup_enable() to allow
or disallow them to wake up the system from sleep states.  Rework
the /proc/acpi/wakeup interface to take these changes into account.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-07 01:17:41 -05:00
Rafael J. Wysocki b581a7f9c3 ACPI: Execute _PRW for devices reported as inactive or not present
If a device is reported as inactive or not present by its _STA
control method, acpi_bus_check_add() skips it without evaluating its
_PRW method.  This leads to a problem when the device's _PRW method
points to a GPE, because in that case the GPE may be enabled by
ACPICA during the subsequent acpi_update_gpes() call which, in
turn, may cause a GPE storm to appear.

To avoid this issue, make acpi_bus_check_add() evaluate _PRW for
inactive or not present devices and register the wakeup GPE
information returned by them, so that acpi_update_gpes() does not
enable their GPEs unnecessarily.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-12-17 16:39:11 -05:00
Len Brown 6e04c417ae Merge branch 'gpe-defer' into release 2010-10-25 02:13:09 -04:00
Thomas Renninger 620e112cfe ACPI/PNP: A HID value of an object never changes -> make it const
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-01 19:28:51 -04:00
Thomas Renninger 2b2ae7c7f8 ACPI: Do not export hid/modalias sysfs file for ACPI objects without a HID
Boot and compile tested.
The fact that pnp.ids can now be empty needs testing on some
further machines, though.

This should handle a "modprobe is wrongly called by udev" issue:
https://bugzilla.kernel.org/show_bug.cgi?id=19162

Modaliase files in
/sys/devices/LNXSYSTM:00/
went down from 113 to 71 on my tested system.

This is a sysfs change, but userspace must already be able to handle it.

Also do not fill up pnp.ids list with a "struct hid"
entry. This comment:
     * This generic ID isn't useful for driver binding, but it provides
     * the useful property that "every acpi_device has an ID."
is still half way true:
Best you never touch pnp.ids list directly or make sure it can be empty,
instead use:
char *acpi_device_hid()
which always returns a value ("device" as a dummy if the object
has no hid).

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Zhang Rui <rui.zhang@intel.com>
CC: kay.sievers@vrfy.org
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-01 15:36:39 -04:00
Rafael J. Wysocki a210080195 ACPI / ACPICA: Defer enabling of runtime GPEs (v3)
The current ACPI GPEs initialization code has a problem that it
enables some GPEs pointed to by device _PRW methods, generally
intended for signaling wakeup events (system or device wakeup).
These GPEs are then almost immediately disabled by the ACPI namespace
scanning code with the help of acpi_gpe_can_wake(), but it would be
better not to enable them at all until really necessary.

Modify the initialization of GPEs so that the ones that have
associated _Lxx or _Exx methods and are not pointed to by any _PRW
methods will be enabled after the namespace scan is complete.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-09-24 16:55:47 -04:00
Rafael J. Wysocki 9874647ba1 ACPI / ACPICA: Do not execute _PRW methods during initialization
Currently, during initialization ACPICA walks the entire ACPI
namespace in search of any device objects with assciated _PRW
methods.  All of the _PRW methods found are executed in the process
to extract the GPE information returned by them, so that the GPEs in
question can be marked as "able to wakeup" (more precisely, the
ACPI_GPE_CAN_WAKE flag is set for them).  The only purpose of this
exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
if there are _Lxx/_Exx methods associated with them.  However, it is
both costly and unnecessary, because the host OS has to execute the
_PRW methods anyway to check which devices can wake up the system
from sleep states.  Moreover, it then uses full information
returned by _PRW, including the GPE information, so it can take care
of disabling the GPEs if necessary.

Remove the code that walks the namespace and executes _PRW from
ACPICA and modify comments to reflect that change.  Make
acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
so that they don't cause spurious wakeup events to be signaled.
This not only reduces the complexity of the ACPICA initialization
code, but in some cases it should reduce the kernel boot time as
well.

Unfortunately, for this purpose we need a new ACPICA function,
acpi_gpe_can_wake(), to be called by the host OS in order to disable
the GPEs that can wake up the system and were previously enabled by
acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
should be disabled only once, because the initialization code enables
it only once, but it may be pointed to by _PRW for multiple devices
and that's why the additional function is necessary).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-12 14:17:39 -04:00
Rafael J. Wysocki e8e18c9561 ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()
When we check if a GPE can be used for runtime signaling, we only
search the FADT GPE blocks, which is incorrect, becuase the GPE
may be located elsewhere.  We really should be using the GPE device
information previously returned by _PRW here, so make that happen.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-12 14:17:19 -04:00
Lin Ming 0f849d2cc6 ACPICA: Minimize the differences between linux GPE code and ACPICA code base
We have ported Rafael's major GPE changes
(ACPI: Use GPE reference counting to support shared GPEs) into ACPICA code base.
But the port and Rafael's original patch have some differences, so we made
below patch to make linux GPE code consistent with ACPICA code base.

Most changes are about comments and coding styles.
Other noticeable changes are based on:

Rafael: Reduce code duplication related to GPE lookup
https://patchwork.kernel.org/patch/86237/

Rafael: Always use the same lock for GPE locking
https://patchwork.kernel.org/patch/90471/

A new field gpe_count in struct acpi_gpe_block_info to record the number
of individual GPEs in block.

Rename acpi_ev_save_method_info to acpi_ev_match_gpe_method.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-20 10:43:16 -04:00
Len Brown c25f7cf203 Merge branches 'battery', 'bugzilla-14667', 'bugzilla-15096', 'bugzilla-15480', 'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 'pxm-fix' and 'video-random-key' into release 2010-04-06 17:06:22 -04:00
Bjorn Helgaas b7b30de53a ACPI: use _HID when supplied by root-level devices
Previously, we assumed the only Device object immediately below the root
was the \_SB Scope (which the ACPI CA treats as a Device), so we forced
the HID of all such objects to ACPI_BUS_HID ("LNXSYBUS").

However, there are DSDTs that supply root-level Device objects with _HIDs.
This patch makes us pay attention to those _HIDs and only add the synthetic
ACPI_BUS_HID for root-level objects that do not supply their own _HID.

For example, this DSDT: https://bugzilla.kernel.org/show_bug.cgi?id=15605
contains:

    Scope (_SB) {
	...
    }
    Device (AMW0) {
	Name (_HID, EisaId ("PNP0C14"))
	...
    }

and we should use "PNP0C14" for the AMW0 device, not "LNXSYBUS".

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-03 23:32:07 -04:00
Tejun Heo 5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
Darrick J. Wong 222e82ac9f acpi: Support IBM SMBus CMI devices
On some old IBM workstations and desktop computers, the BIOS presents in the
DSDT an SMBus object that is missing the HID identifier that the i2c-scmi
driver looks for.  Modify the ACPI device scan code to insert the missing HID
if it finds an IBM system with such an object.

Affected machines: IntelliStation Z20/Z30.  Note that the i2c-i801 driver no
longer works on these machines because of ACPI resource conflicts.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-03-24 14:38:37 +01:00
Rafael J. Wysocki b67ea76172 PCI / ACPI / PM: Platform support for PCI PME wake-up
Although the majority of PCI devices can generate PMEs that in
principle may be used to wake up devices suspended at run time,
platform support is generally necessary to convert PMEs into wake-up
events that can be delivered to the kernel.  If ACPI is used for this
purpose, PME signals generated by a PCI device will trigger the ACPI
GPE associated with the device to generate an ACPI wake-up event that
we can set up a handler for, provided that everything is configured
correctly.

Unfortunately, the subset of PCI devices that have GPEs associated
with them is quite limited.  The devices without dedicated GPEs have
to rely on the GPEs associated with other devices (in the majority of
cases their upstream bridges and, possibly, the root bridge) to
generate ACPI wake-up events in response to PME signals from them.

Add ACPI platform support for PCI PME wake-up:
o Add a framework making is possible to use ACPI system notify
  handlers for run-time PM.
o Add new PCI platform callback ->run_wake() to struct
  pci_platform_pm_ops allowing us to enable/disable the platform to
  generate wake-up events for given device.  Implemet this callback
  for the ACPI platform.
o Define ACPI wake-up handlers for PCI devices and PCI root buses and
  make the PCI-ACPI binding code register wake-up notifiers for all
  PCI devices present in the ACPI tables.
o Add function pci_dev_run_wake() which can be used by PCI drivers to
  check if given device is capable of generating wake-up events at
  run time.

Developed in cooperation with Matthew Garrett <mjg@redhat.com>.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-02-22 16:21:02 -08:00
Rafael J. Wysocki f517709d65 ACPI / PM: Add more run-time wake-up fields
Use the run_wake flag to mark all devices for which run-time wake-up
events may be generated by the platform.  Introduce a new wake-up
flag, always_enabled, for marking devices that should be permanently
enabled to generate run-time events.  Also, introduce a reference
counter for run-wake devices and a function that will initialize all
of the run-time wake-up fields for given device.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-02-22 16:20:51 -08:00
Thomas Renninger 7779688fc3 ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was found
Callers (acpi_memhotplug.c, dock.c and others) check for the return
value of acpi_bus_add() and assume a valid device was returned in
case zero was returned.

Thus return -ENODEV if no device was found in acpi_bus_scan and
propagate this through acpi_bus_add and acpi_bus_start.

Also remove a confusing comment in acpiphp_glue.c, acpi_bus_scan
will and cannot invoke if acpi_bus_add returns no valid device.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-31 21:43:32 -05:00
Thomas Renninger d2f6650a95 ACPI: Add NULL pointer check in acpi_bus_start
If acpi_bus_add does not return a device and it's passed
to acpi_bus_start, bad things will happen:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff8128402d>] acpi_bus_start+0x14/0x24
...
[<ffffffffa008977a>] acpiphp_bus_add+0xba/0x130 [acpiphp]
[<ffffffffa008aa72>] enable_device+0x132/0x2ff [acpiphp]
[<ffffffffa0089b68>] acpiphp_enable_slot+0xb8/0x130 [acpiphp]
[<ffffffffa0089df7>] handle_hotplug_event_func+0x87/0x190 [acpiphp]

Next patch would make this NULL pointer check obsolete, but
better having one more than one missing...

Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: stable@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-31 21:43:04 -05:00
Lin Ming 2263576cfc ACPICA: Add post-order callback to acpi_walk_namespace
The existing interface only has a pre-order callback. This change
adds an additional parameter for a post-order callback which will
be more useful for bus scans. ACPICA BZ 779.

Also update the external calls to acpi_walk_namespace.

http://www.acpica.org/bugzilla/show_bug.cgi?id=779

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-24 21:31:10 -05:00
Bjorn Helgaas a83893ae90 ACPI: fix bus scanning memory leaks
Free an acpi_get_object_info() buffer when we're finished.  Skip the
acpi_get_name() altogether -- it was only used for a printk that was
really just for debug anyway.

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

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-02 11:03:12 -04:00
Bjorn Helgaas 57f3674f5e ACPI: simplify building device HID/CID list
Minor code cleanup, no functional change.  Instead of remembering
what HIDs & CIDs to add later, just add them immediately.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25 15:09:49 -04:00
Bjorn Helgaas 6622d8cee7 ACPI: remove acpi_device_uid() and related stuff
Nobody uses acpi_device_uid(), so this patch removes it.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25 15:09:49 -04:00
Bjorn Helgaas 1131b938f0 ACPI: remove acpi_device.flags.hardware_id
Every acpi_device has at least one ID (if there's no _HID or _CID, we
give it a synthetic or default ID).  So there's no longer a need to
check whether an ID exists; we can just use it.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25 15:09:48 -04:00
Bjorn Helgaas b2972f8750 ACPI: remove acpi_device.flags.compatible_ids
We now keep a single list of IDs that includes both the _HID and any
_CIDs.  We no longer need to keep track of whether the device has a _CID.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25 15:09:47 -04:00
Bjorn Helgaas 7f47fa6c2f ACPI: maintain a single list of _HID and _CID IDs
There's no need to treat _HID and _CID differently.  Keeping them in
a single list makes code that uses the IDs a little simpler because it
can just traverse the list rather than checking "do we have a HID?",
"do we have any CIDs?"

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25 15:09:31 -04:00