Fixed a problem with the internal FADT conversion where ACPI 1.0
FADTs that contained invalid non-zero values in reserved fields
could cause later failures because these fields have meaning in
later revisions of the FADT. For incoming ACPI 1.0 FADTs, these
fields are now always zeroed. (Preferred_PM_Profile, PSTATE_CNT,
CST_CNT, IAPC_BOOT_FLAGS.)
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fixed a problem in acpi_ev_delete_gpe_xrupt where the global interrupt
list could be corrupted if the interrupt being removed was at
the head of the list. Reported by Linn Crosetto.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Need to check for special case "acpi_osi=!Linux" before handling the
general case "acpi_osi=!*", or it will have no effect.
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If asus_acpi_init doesn't find any device it knows about, it mistakenly
returns a "success" error code even though it cleans up after itself.  Later
when trying to rmmod asus_acpi, the module_exit routine would try to clean up
one more time and we would end up calling
acpi_bus_unregister_driver(&asus_hotk_driver) twice.  This patch addresses
this first problem by returning -ENODEV when no appropriate device is found.

Then there was also another bug with the code handling the return value of
backlight_device_register.  If this function ever failed, the driver would
cleanup by calling the module_exit routine from module_init, but it would
still return "success".  So any attempt to rmmod this module would result in
asus_acpi_exit being called twice but it's not ready to handle it (I haven't
hit this bug, just found it by code inspection).  This patch fixes that by
inserting a return -ENODEV; at the end of this error handling path.
Signed-off-by: NMaxime Austruy <maxime@tralhalla.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Always disable/enable interrupts in the acpi idle routine,
even in the error path.

This is required as the 2.6.20 change in git commit d331e739...
"Fix interrupt race in idle callback" expects the idle handler
to enable interrupt before returning.

There was a case in acpi idle routine, in which interrupt was not being
enabled before return, which caused the system to hang at bootup, while
enabling C-states on an SMP system.

The signature of the hang was that "processor.nocst"
was required to enable boot.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

In the routine acpi_ut_create_package_object(), if the
ACPI_ALLOCATE_ZEROED() fails then ACPI_FREE(package_desc) is called as
part of the cleanup.  This should instead be
acpi_ut_remove_reference(package_desc) in order to remove the reference
acquired from acpi_ut_create_internal_object() [see the routine
acpi_ut_create_buffer_object() as an example of proper functionality].
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

if acpi_bus_get_device() returns NULL, print nothing
instead of "<NUL" in /proc/acpi/thermal_zone/*/trip_points
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix section error (allyesconfig).  The exit function is called from init,
so functions that are called by the exit function cannot be marked __exit.

WARNING: drivers/built-in.o(.text+0xe5bc6): Section mismatch: reference to .exit.
text: (between 'toshiba_acpi_exit' and 'hci_raw')
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Implemented support to allow Package objects to be passed as
method arguments to the acpi_evaluate_object interface. Previously,
this would return an AE_NOT_IMPLEMENTED exception.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Last of the "Section mismatch" errors from ia64 builds! acpi_map_pxm_to_node()
is defined with attribute __cpuinit, but is called by "normal" kernel functions
acpi_getnode() and acpi_map_cpu2node().

Commit f363d16f moved the data structures on
which this routine operates from __cpuinitdata to regular memory, so this
routine can also move out of init space.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix following section mismatch warnings in acpi

WARNING: drivers/acpi/asus_acpi.o(.init.text+0xb7): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: o-i386/drivers/acpi/toshiba_acpi.o(.init.text+0x13a): Section mismatch: reference to .exit.text: (after 'init_module')

The exit function is used in the init function during an error codition.
As __exit may be discarded during link-time / run-time this is no good.
Do not mark the exit function __exit.

Note: This warning is only seen by my local copy of modpost
      but the change will soon hit upstream.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add __init to:
acpi_initialize_subsystem() (and un-export it)
acpi_os_initialize()

Add __initdata to:
acpi_osl_dmi_table[]
Signed-off-by: NLen Brown <len.brown@intel.com>

_OSI("Linux") is like _OS("Linux"), it is ill-defined and
virtually no BIOS vendors test interaction with it.
As a result, it can do more damage than good because
it causes the BIOS to follow un-tested paths.

Recently, several machines have turned up that erroneously
test this string in a way which causes them to _not_ test other
compatibility strings, including the ZI9 and Toshiba.
So it appears that this bad code has made it into
a BIOS vendor's reference BIOS.

Linux has no choice but to stop advertising compatibility
with _OSI string "Linux" - as there are an unbounded
number of possible incompatibilities going forward.

But some BIOSes have already shipped which do use it
for things like conditionally re-enabling video on resume
from S3.  (Too bad they didn't do that unconditionally)

Add special case code for _OSI(Linux)
Squawk to dmesg if _OSI(Linux) is requested
Add DMI list both to enable and disable _OSI(Linux)
But for now, keep the default enabled via
#define OSI_LINUX_ENABLED.

http://bugzilla.kernel.org/show_bug.cgi?id=7787Signed-off-by: NLen Brown <len.brown@intel.com>

The boot option "acpi_osi=" has always disabled Linux _OSI support,
thus disabling all OS Interface strings which are advertised
by Linux to the BIOS.

Now...
acpi_osi="string" adds the interface string, and
acpi_osi="!string" invalidates the pre-defined interface string

eg. acpi_osi="!Windows 2006"
would disable Linux's claim of Vista compatibility.
Signed-off-by: NLen Brown <len.brown@intel.com>

For users with active thermal trip points, they need
the fan's name, rather than its address, to understand
where to look to observe and control fan state.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

HP and Hitachi machines have been implemented with SSDT's
that use the "OEMx" signatures.  But upon Load, ACPICA is rejecting
these tables because they are not using the "SSDT" signature.

ACPI Error (tbinstal-0134): Table has invalid signature [OEMx], must be SSDT...
Signed-off-by: NLen Brown <len.brown@intel.com>

Strip __cpuinit[data] from Node <-> PXM routines and supporting data
structures.  Also make pxm_to_node_map and node_to_pxm_map local to the
numa acpi module.

This fixes a bug triggered by the following conditions:
- boot on a machine with a SLIT table defined
- kernel is configured w/ CONFIG_HOTPLUG_CPU=n
- cat /sys/devices/system/node/node*/distance
This will cause an oops by calling into a freed memory section.

In particular, on x86_64, __node_distance calls node_to_pxm().
Signed-off-by: NAaron Durbin <adurbin@google.com>
Cc: Len Brown <lenb@kernel.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The ACPI EC that is used in MSI laptops knows some non-standard
commands for changing the screen brighntess and a few other things,
which are used by the msi-laptop.c driver. Unfortunately for these
commands no GPE events for IBF and OBF are triggered. Since nowadays
the EC code uses the ec_intr=1 mode by default, this causes these
operations to timeout, although they don't fail. In result, all
operations that you can do with the msi-laptop.c driver take more or
less 1s to complete, which is awfully slow.

In one of the more recent kernels (2.6.20?) the EC subsystem has been
revamped. With that change the EC timeout has been increased. before
that increase the MSI EC accesses were slow -- but not *that* slow,
hence I took notice of this limitation of the MSI EC hardware only very
recently.

The standard EC operations on the MSI EC as defined in the ACPI spec
support GPE events properly.

The following patch adds a new argument "force_poll" to the
ec_transaction() function (and friends). If set to 1, the function
will poll for IBF/OBF even if ec_intr=1 is enabled. If set to 0 the
current behaviour is used. The msi-laptop driver is modified to make
use of this new flag, so that OBF/IBF is polled for the special MSI EC
transactions -- but only for them.
Signed-off-by: NLennart Poettering <mzxreary@0pointer.de>
Acked-by: NAlexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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

HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.

Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.

In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.

To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel  stack
overflow.

First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.

Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.

http://bugzilla.kernel.org/show_bug.cgi?id=5534
http://bugzilla.kernel.org/show_bug.cgi?id=8385Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit c0d127b5.

These changes to AML locking were made to allow
Notify handlers to be called on the stack
and not deadlock.  However, that scheme turns
out to be flawed and was reverted by the previous commit,
so this commit restores the locking to it previous design.
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 5f7748cf.

While that change fixed the HP
http://bugzilla.kernel.org/show_bug.cgi?id=5534

it broke the ACER:
http://bugzilla.kernel.org/show_bug.cgi?id=8385
which as AML that caused Linux go recursive
and stack fault.

So this commit by itself will restore the ACER
and again break the HP, which we'll fix another way.
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit a8f4af6d.
Thus restoring ACPICA's new acpi_serialize code.

This commit by itself may cause a regression, but
it is reverted in this order so that subsequent
reverts reverts under this one can be made
without conflict.
Signed-off-by: NLen Brown <len.brown@intel.com>

[ With Johannes Berg <johannes@sipsolutions.net> ]

Separate the hibernation (aka suspend to disk code) from the other suspend
code.  In particular:

 * Remove the definitions related to hibernation from include/linux/pm.h
 * Introduce struct hibernation_ops and a new hibernate() function to hibernate
   the system, defined in include/linux/suspend.h
 * Separate suspend code in kernel/power/main.c from hibernation-related code
   in kernel/power/disk.c and kernel/power/user.c (with the help of
   hibernation_ops)
 * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is to fix unnecessary __meminit definition.  These are exported for
kernel modules.

I compiled on ia64/x86-64 with memory hotplug on/off.
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This works around a bug seen in some RTC-related ACPI table entries, and
tweaks related diagnostics to follow the ACPI convention.

The bug prevents misleading boot-time messages: platforms affected by this
bug wrongly report they can support alarms up to one year in the future,
when in fact the longest alarm is just 24 hours.  That will surprise anyone
trying to use those extended alarms.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove /proc/acpi/alarm file when the rtc-cmos "wakealarm" file is available.
Instead, provide hooks that rtc-cmos will use.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Teach PNPACPI how to hook up its devices to their ACPI nodes, so that
pnpdev->dev.archdata points to the parallel acpi device node.  Previously
this only worked for PCI, leaving a notable hole.

Export "acpi_bus_type" so this can work.

Remove some extraneous whitespace.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.

Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is to fix many section mismatches of code related to memory hotplug.
I checked compile with memory hotplug on/off on ia64 and x86-64 box.
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove software_suspend() and all its users since
pm_suspend(PM_SUSPEND_DISK) should be equivalent and there's no point in
having two interfaces for the same thing.

The patch also changes the valid_state function to return 0 (false) for
PM_SUSPEND_DISK when SOFTWARE_SUSPEND is not configured instead of
accepting it and having the whole thing fail later.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Change mark_tsc_unstable() so it takes a string argument, which holds the
reason the TSC was marked unstable.

This is then displayed the first time mark_tsc_unstable is called.

This should help us better debug why the TSC was marked unstable on certain
systems and allow us to make sure we're not being overly paranoid when
throwing out this troublesome clocksource.

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndi Kleen <ak@suse.de>

The scheme where the thermal driver displayed the
cooling mode /proc/acpi/thermal_zone/*/cooling_mode
was flawed in two ways.

First, the success of _SCP doesn't actually mean
that the BIOS moved any trip points.
On many BIOS, _SCP is present, but does nothing.
So displaying what _SCP executed actually
was wrong more times than it was right.

Second, examining the relative position of the
trip points when the thermal_zone is added
is insufficient -- as the BIOS reserves the right
to change the trip points at run-time.

The only reliable way for the user to determine if
the thermal zone is in active, passive, or critical
mode is to examine the relative position of the trip points.
The user can do this without the kernel doing it
for them by looking in /proc/acpi/thermal_zone/*/trip_points

New contents for /proc/acpi/thermal_zone/*/cooling_mode:

If _SCP available:
"0 - Active; 1 - Passive\n"

If _SCP unavailable:
"<setting not supported>\n"
Signed-off-by: NLen Brown <len.brown@intel.com>

/proc/acpi/thermal_zone/*/trip_points displays
what the kernel reads from the BIOS via ACPI.

If you echo a string of ':' deliminted numbers to this file
then it will change what it displays.

But it shouldn't, since the kernel has no way to communicate
these changes to ACPI thermal zones.  ACPI thermal zone
trip points are read-only.

The kernel does have the opportunity to ask the BIOS to change
the trip points with _SCP - Set Cooling Policy.

Request Active Cooling Mode:
# echo 0 > /proc/acpi/thermal_zone/*/cooling_policy

Request Passive Cooling Mode:
# echo 1 > /proc/acpi/thermal_zone/*/cooling_policy

However, in practice it is quite rare for the BIOS
to support the optional _SCP, and it is even more rare
for the BIOS to export an _SCP that actually changes
the trip points.
Signed-off-by: NLen Brown <len.brown@intel.com>

Almost all users of pm_ops only support mem sleep, don't check in .valid and
don't reject any others in .prepare so users can be confused if they check
/sys/power/state, especially when new states are added (these would then
result in s-t-r although they're supposed to be something different).

This patch implements a generic pm_valid_only_mem function that is then
exported for users and puts it to use in almost all existing pm_ops.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: NPavel Machek <pavel@ucw.cz>
Cc: linux-pm@lists.linux-foundation.org
Cc: Len Brown <lenb@kernel.org>
Acked-by: NRussell King <rmk@arm.linux.org.uk>
Cc: Greg KH <greg@kroah.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Linux-2.6.21 stopped booting on a P4/HT because Linux
wrote the FADT.CST_CNT value to the SMI_CMD.
Apparently this stumbled over some SMM instability,
such as confusing SMM when invoking it from cpu1.

Linux did this because even though the r2 FADT reserves
the CST_CNT field, this BIOS set that field and Linux
used it.

Turns out that up through 2.6.20 we explicitly cleared
cst_control for r2 FADTs.  So here we go back to doing that,
plus also clear some additional fields that are reserved
until FADT r3.

http://bugzilla.kernel.org/show_bug.cgi?id=8346Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Remove deprecated /proc/acpi/processor/performance write support

Writing to /proc/acpi/processor/xy/performance interferes with sysfs
cpufreq interface. Also removes buggy cpufreq_set_policy exported symbol.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NDave Jones <davej@redhat.com>

This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device.  Example:

	Device	S-state	  Status   Sysfs node
	PCI0	  S4	 disabled  no-bus:pci0000:00
	PS2M	  S4	 disabled  pnp:00:05
	PS2K	  S4	 disabled  pnp:00:06
	UAR1	  S4	 disabled  pnp:00:08
	USB1	  S3	 disabled  pci:0000:00:03.0
	USB2	  S3	 disabled  pci:0000:00:03.1
	USB3	  S3	 disabled
	USB4	  S3	 disabled  pci:0000:00:03.3
	S139	  S4	 disabled
	LAN	  S4	 disabled  pci:0000:00:04.0
	MDM	  S4	 disabled
	AUD	  S4	 disabled  pci:0000:00:02.7
	SLPB	  S4	*enabled

Eventually this file should be removed, but until then it's almost the only
way we have to tell how the relevant ACPI tables are broken (and cope).  In
that example, two devices don't actually exist (USB3, S139), one can't issue
wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and AUD are
the same PCI device, but it's the _modem_ that does wake-on-ring).

In particular, we need to be sure driver model nodes are properly hooked
up before we can get rid of this ACPI-only interface for wakeup events.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: <bbpetkov@yahoo.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Be explicit about what "device->status = 0x0F" really means.

syntax only.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>