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>

History: This support changes a method to "serialized" on the fly if the
method generates an AE_ALREADY_EXISTS error, indicating the possibility
that it cannot handle reentrancy.

This fix repairs a couple of issues seen in the field, especially on
machines with many cores.

1) Delete method children only upon the exit of the last thread, so
as to not delete objects out from under running threads.

2) Set the "serialized" bit for the method only upon the exit of the
last thread, so as to not cause deadlock when running threads attempt
to exit.

3) Cleanup the use of the AML "MethodFlags" and internal method flags
so that there is no longer any confustion between the two.
Reported-by: NDana Myers <dana.myers@oracle.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Prevents issues if the namespace is changing underneath the
debugger.  Especially temporary nodes, since the debugger displays
these also.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fixes a race condition between method execution and namespace
walks that can possibly fault. Problem was apparently introduced
in version 20100528 as a result of a performance optimization
that reduces the number of namespace walks upon method exit
by using the delete_namespace_subtree function instead of the
delete_namespace_by_owner function used previously. Bug is in
the delete_namespace_subtree function.
Signed-off-by: NDana Myers <dana.myers@oracle.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

We will leak the memory allocated to 'local_gpe_event_info' if
'acpi_ut_acquire_mutex()' fails or if 'acpi_ev_valid_gpe_event()' fails in
drivers/acpi/acpica/evgpe.c::acpi_ev_asynch_execute_gpe_method().
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Modify/add some comments to minimize ACPICA/linux GPE code divergence.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The global event handler is called whenever a general purpose
or fixed ACPI event occurs.

Also update Linux OSL to collect events counter with
global event handler.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Change the local variable in acpi_ev_asynch_execute_gpe_method()
back into a pointer as ACPICA code base does.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The new GPE handler callback has 2 additional parameters, gpe_device and
gpe_number.

typedef
u32 (*acpi_gpe_handler) (acpi_handle gpe_device, u32 gpe_number, void *context);
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Create a new file evxfgpe.c and move GPE specific functions to it.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

GPEs with corresponding _Lxx/_Exx control methods need to be disabled
during initialization in case they have been enabled by the BIOS, so
that they don't fire up until they are enabled by acpi_update_gpes().

References: https://bugzilla.kernel.org/show_bug.cgi?id=25412Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 3138b32d.

as it caused a crash upon battery removal:
https://bugzilla.kernel.org/show_bug.cgi?id=25302Signed-off-by: NLen Brown <len.brown@intel.com>

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: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The saving of the NVS memory area during suspend and restoring it
during resume causes problems to appear on Sony Vaio VGN-NW130D, so
blacklist that machine to avoid those problems.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=23002Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NAdriano <adriano.vilela@yahoo.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Properly const-, __init-, and __read_mostly-annotate this code.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

When CONFIG_CPU_FREQ=n ...

drivers/acpi/processor_thermal.c:159:12: warning: ‘acpi_thermal_cpufreq_increase’ defined but not used
drivers/acpi/processor_thermal.c:163:12: warning: ‘acpi_thermal_cpufreq_decrease’ defined but not used

Remove unused declaration of ‘acpi_thermal_cpufreq_increase’ and
‘acpi_thermal_cpufreq_decrease’
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux()

The function acpi_os_initialize1() references
the function __init set_osi_linux().
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

ERST writing may be used in NMI or Machine Check Exception handler. So
it need to use raw spinlock instead of normal spinlock.  This patch
fixes it.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced another regression that only one _OSI string can be added or
removed.

Now multiple _OSI strings can be added or removed, for example

acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006"
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced a regression that _OSI string setup fails.

There are 2 paths to setup _OSI string.

DMI:
acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
string to osi_setup_string

Boot command line:
acpi_osi_setup -> copy _OSI string to osi_setup_string

Later, acpi_osi_setup_late will be called to handle osi_setup_string.
If _OSI string is "Linux" or "!Linux", then the call path is,

acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
acpi_osi_setup -> copy _OSI string to osi_setup_string

This actually never installs _OSI string(acpi_install_interface not
called), but just copy the _OSI string to osi_setup_string.

This patch fixes the regression.
Reported-and-tested-by: NLukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=15418Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Sometimes the Battery driver doesn't get notifications when it's
plugged/unplugged. And this results in the incorrect Battery
status reported by the power supply sysfs I/F.

Update Battery status first when querying from sysfs.
http://marc.info/?l=linux-acpi&m=128855015826728&w=2

Tested_by: Seblu <seblu@seblu.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

http://marc.info/?l=linux-acpi&m=128855015826728&w=2
https://bugzilla.kernel.org/show_bug.cgi?id=21722

Tested_by: Seblu <seblu@seblu.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

If turning on a power resource fails, do not reference count it,
since it cannot be in use in that case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 3e384ee6 (ACPI / PM: Fix
reference counting of power resources) introduced a regression by
causing fan power resources to be turned on and reference counted
unnecessarily during resume, so on some boxes fans are always on
after resume.

Fix the problem by checking if the current device state is different
from the new state before reference counting and turning on power
resources in acpi_power_transition().

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22932 .
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently we have:

  --w--w--w-. 1 root root 0 2010-11-11 14:56 /sys/kernel/debug/acpi/custom_method

which is just crazy. Change this to --w-------.
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Cc: stable@kernel.org (for 2.6.36)
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ACPI table sysfs I/F is broken by commit

78f16996
Author: Alex Chiang <achiang@hp.com>
Date:   Sun Dec 20 12:19:09 2009 -0700
    ACPI: processor: call _PDC early

because dynamic SSDT tables may be loaded in _PDC,
before installing the ACPI table handler.
As a result, the sysfs I/F of these dynamic tables are
located at  /sys/firmware/acpi/tables instead of
/sys/firmware/acpi/tables/dynamic, which is not true.

Invoke acpi_sysfs_init() before acpi_early_processor_set_pdc(),
so that the table handler is installed before any dynamic tables loaded.

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

CC: Dennis Jansen <dennis.jansen@web.de>
CC: Alex Chiang <achiang@hp.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Sony Vaio VPCEB1Z1E is reported to require acpi_sleep=nonvs for
suspend/resume to work on it correctly, so blacklist it.
Reported-by: NEmanuele Bigiarini <pulmro@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch optimizes ACPI MMIO remappings by keeping track of the
remappings on a PAGE_SIZE granularity.

When an ioremap() occurs, the underlying infrastructure works on a 'page'
based granularity.  As such, an ioremap() request for 1 byte for example,
will end up mapping in an entire (PAGE_SIZE) page.  Huang Ying took
advantage of this in commit 15651291 by
checking if subsequent ioremap() requests reside within any of the list's
existing remappings still in place, and if so, incrementing a reference
count on the existing mapping as opposed to performing another ioremap().
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the simple locking introduced earlier for the ACPI MMIO
remappings list to an RCU based locking scheme.
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.

ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT.  If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.

By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped.  This solves BZ 18012.

ACPI "System Event" reference(s):
  ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
  3.8 "System Events", 5.6 "ACPI Event Programming Model".

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

Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add remapping and unmapping interfaces for ACPI registers that are
backed by memory mapped I/O (MMIO).  These interfaces, along with
the MMIO remapping list, enable accesses of such registers from within
interrupt context.

ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure".
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

For memory mapped I/O (MMIO) remappings, add a list to maintain the
remappings and augment the corresponding mapping and unmapping interface
routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
dynamically add to, and delete from, the list.

The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
end up calling ioremap() when accessing MMIO.  This prevents use of these
methods within interrupt context (IRQ and/or NMI), since ioremap() may
block to allocate memory.  Maintaining a list of MMIO remappings enables
accesses to such areas from within interrupt context provided they have
been pre-mapped.
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The size used for I/O remapping MMIO read and write accesses has not
accounted for the basis of ACPI's Generic Address Structure (GAS)
'Register Bit Width' field which is bits, not bytes.  This patch
adjusts the ioremap() 'size' argument accordingly.

ACPI "Generic Register" reference:
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure".
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The function acpi_battery_get_property() is called by the
power supply framework's function power_supply_show_property()
implementing the sysfs interface for power supply devices as the
ACPI battery driver's ->get_property() callback.  Thus it is supposed
to return error code if the value of the given property is unknown.
Unfortunately, however, it returns 0 in those cases and puts a
wrong (negative) value into the intval field of the
union power_supply_propval object provided by
power_supply_show_property().  In consequence, wrong negative
values are read by user space from the battery's sysfs files.

Fix this by making acpi_battery_get_property() return -ENODEV
for properties with unknown values (-ENODEV is returned, because
power_supply_uevent() returns with error for any other error code
returned by power_supply_show_property()).
Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

The reference counting of ACPI power resources is currently broken
for a few reasons.  First, instead of using a simple reference
counter per power resource it uses a list of objects representing
refereces to the given power resource from devices.  This leads to
the second breakage, because it prevents power resources from
being referenced more than once by one device, which is necessary
if the device is configured to signal wakeup.  Namely, when putting
the device into a low power state we first call
acpi_enable_wakeup_device_power() that should reference count power
resources needed for signaling wakeup and then we call
acpi_power_transition() to power off the device.  The latter call
drops references to the device's power resources, possibly including
the ones added by acpi_enable_wakeup_device_power(), so the device
can't signal wakeup as a result.  Apart from this, the locking
in acpi_power_on() and acpi_power_off_device() doesn't prevent
all possible races from happening, which may be problematic for
runtime PM and asynchronous suspend and resume.

Fix the problem by using a counter for power resources reference
counting and putting the evaluation of ACPI _ON and _OFF methods
under the power resource mutex.
Reported-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>