ACPI GPEs may map to multiple devices.  The current GPE interface
only provides a mechanism for enabling and disabling GPEs, making
it difficult to change the state of GPEs at runtime without extensive
cooperation between devices.

Add an API to allow devices to indicate whether or not they want
their device's GPE to be enabled for both runtime and wakeup events.

Remove the old GPE type handling entirely, which gets rid of various
quirks, like the implicit disabling with GPE type setting. This
requires a small amount of rework in order to ensure that non-wake
GPEs are enabled by default to preserve existing behaviour.

Based on patches from Matthew Garrett <mjg@redhat.com>.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We broke "acpi=ht" in 2.6.32 by disabling MADT parsing
for acpi=disabled.  e5b8fc6a
This also broke systems which invoked acpi=ht via DMI blacklist.

acpi=ht is a really ugly hack,
but restore it for those that still use it.

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

Since the rewrite of the CPU idle governor in 2.6.32, two laptops have
surfaced where the BIOS advertises a C2 power state, but for some reason
this state is not functioning (as verified in both cases by powertop
before the patch in .32).

The old governor had the accidental behavior that if a non-working state
was chosen too many times, it would end up falling back to C1.  The new
governor works differently and this accidental behavior is no longer
there; the result is a high temperature on these two machines.

This patch adds these 2 machines to the DMI table for C state anomalies;
by just not using C2 both these machines are better off (the TSC can be
used instead of the pm timer, giving a performance boost for example).

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14742Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Reported-by: <akwatts@ymail.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit fe06fba2 (ACPI: dock: add struct dock_station * directly
to platform device data) changed dock_add() to use the
platform_device_register_data() API.

We passed that interface a stack variable, which is kmemdup'ed
and assigned to the device's platform_data pointer.

Unfortunately, whatever random garbage is in the stack variable
gets coped during the kmemdup, and that leads to broken behavior.

Explicitly zero out the structure before passing it to the API.

This fixes the T41 docking button issue:
http://bugzilla.kernel.org/show_bug.cgi?id=15000

Cc: stable@kernel.org
Reported-by: NChris Mason <chris.mason@oracle.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NThomas Renninger <trenn@suse.de>
Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NThomas Renninger <trenn@suse.de>
Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

If we evaluate _PDC in the early path, we do not want to evaluate
it again when the processor driver is loaded.

Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Allow platforms not listed in DMI table
to opt-in and evaluate _PDC early.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

no functional change -- cleanup only.

acpi_processor_power_verify_c2() was nearly empty due to a previous patch,
so expand its remains into its one caller and delete it.
Signed-off-by: NLen Brown <len.brown@intel.com>

Do for C3 what the previous patch did for C2.

The C2 patch was in response to a highly visible
and multiply reported C-state/turbo failure,
while this change has no bug report in-hand.

This will enable C3 in Linux on systems where BIOS
overstates C3 latency in _CST.  It will also enable
future systems which may actually have C3 > 1000usec.

Linux has always ignored ACPI BIOS C3 with exit latency > 1000 usec,
and the ACPI spec is clear that is correct FADT-supplied C3.

However, the ACPI spec explicitly states that _CST-supplied C-states
have no latency limits.

So move the 1000usec C3 test out of the code shared
by FADT and _CST code-paths, and into the FADT-specific path.
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec,
and the ACPI spec is clear that is correct FADT-supplied C2.

However, the ACPI spec explicitly states that _CST-supplied C-states
have no latency limits.

So move the 100usec C2 test out of the code shared
by FADT and _CST code-paths, and into the FADT-specific path.

This bug has not been visible until Nehalem, which advertises
a CPU-C2 worst case exit latency on servers of 205usec.
That (incorrect) figure is being used by BIOS writers
on mobile Nehalem systems for the AC configuration.
Thus, Linux ignores C2 leaving just C1, which is
saves less power, and also impacts performance
by preventing the use of turbo mode.

http://bugzilla.kernel.org/show_bug.cgi?id=15064Tested-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

resource->domain_devices can be double kfree()'d in a couple of places.
Fix this by setting num_domain_devices = 0 after the kfree().

Coverity CID: 13356, 13355, 13354
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Acked-by: NDarrick J. Wong <djwong@us.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 78f16996 (ACPI: processor: call _PDC early) blindly walks
the namespace and calls _PDC on every processor object it finds.

This change may cause issues on platforms that declare dummy
values for SSDTs on non-present processors (disabled in MADT).
When we call _PDC and dynamically attempt to execute the AML
Load() op on these dummy SSDTs, there's no telling what might
happen.

Rather than finding every platform that has bogus SSDTs, restrict
early _PDC calls to platforms that are known to need early
evaluation of _PDC.

This is a minimal, temporary fix (given the context of the
current release cycle). A real solution of checking the MADT for
non-present processors will be written for the next merge window.

References:

	http://bugzilla.kernel.org/show_bug.cgi?id=14710
	http://bugzilla.kernel.org/show_bug.cgi?id=14954Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

When CONFIG_ACPI_SYSFS_POWER=n and CONFIG_ACPI_PROCFS_POWER=n, then
we're warned by the following warning:

drivers/acpi/sbs.c: In function `acpi_battery_remove':
drivers/acpi/sbs.c:825: warning: unused variable `battery'
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The ids field of the struct acpi_driver is constant in <linux/acpi/acpi_bus.h>
so it is worth to make the initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: NLen Brown <len.brown@intel.com>

Alex Chiang introduced acpi_early_processor_set_pdc() in commit:
 ACPI: processor: call _PDC early
 78f16996

But this results in a section mismatch:

WARNING: drivers/acpi/acpi.o(.text+0xa9c1): Section mismatch in reference from the
function acpi_early_processor_set_pdc() to the variable .cpuinit.data:processor_idle_dmi_table
The function acpi_early_processor_set_pdc() references
the variable __cpuinitdata processor_idle_dmi_table.
This is often because acpi_early_processor_set_pdc lacks a __cpuinitdata
annotation or the annotation of processor_idle_dmi_table is wrong.

The only caller of acpi_early_processor_set_pdc() is acpi_bus_init() which
is an "__init" function. So the correct fix here is to mark
acpi_early_processor_set_pdc() "__init" too.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The struct seq_file 'private' member is a void *, the cast is not needed.
Also, remove an extra whitespace line.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

If the BIOS pokes the system-wide OSC bits to see if Linux
supports evaluating _OST after a _PPC change notification,
answer yes.

Also, fix an oversight where we neglected to set the OSC
bit advertising processor aggregator device support
when acpi-pad is compiled as a module.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Merge of poll and irq modes accelerated EC transaction, so
that keyboard starts to suffer again. Add msleep(1) into
transaction path for the storm to allow keyboard controller
to do its job.

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

SBS transactions should happen in Notify work queue, to not create
a dead lock with GPE execution accessing SBS devices.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some buggy BIOS exports multiple ACPI video bus devices for the same
VGA controller, and multiple backlight control methods as well.
This messes up the ACPI video backlight control.

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

With this patch applied, only the FIRST ACPI video bus device
under a PCI device node is bind to ACPI video driver by default.

If the first ACPI video bus device doesn't work well, we can use
video.allow_duplicates=1 to go back to the old behavior.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There are some fixes listed below:
1. When met a bogus BIOS, the return value of cpu number maybe is
   a negative value so that acpi_pad_pur get an unexpected result.
2. the return value of function acpi_pad_idle_cpus is useless.
3. enhance the process of create_power_saving_task/destroy_power_saving_task
4. Add more error checks when evaluating _PUR object.
5. one typo fix
Signed-off-by: NChen Gong <gong.chen@linux.intel.com>
Acked-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Introduce kernel parameter acpi_sleep=sci_force_enable

some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.

We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

backlight_device_register may return an ERR_PTR
value rather than a valid pointer.

Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NLen Brown <len.brown@intel.com>

AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".

In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14Sigend-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.

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

Executing _OSC returns a buffer, which has an acpi object in it.
Don't directly returns the buffer, instead, we return the acpi object's
buffer. This fixes a regression since caller of acpi_run_osc expects
an acpi object's buffer returned.
Tested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

When calling _PDC, we really only need the handle to the processor
to call the method; we don't look at any other parts of the
struct acpi_processor * given to us.

In the early path, when we walk the namespace, we are given the
handle directly, so just pass it through to acpi_processor_set_pdc()
without stuffing it into a wasteful struct acpi_processor allocated
on the stack each time

This saves 2834 bytes of stack.

Update the interface accordingly.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We have the acpi_object_list * right there in acpi_processor_set_pdc()
so it doesn't seem necessary for an entire helper function just to
free it.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_processor_eval_pdc() really only needs a handle and an
acpi_object_list * to do its work.

No need to pass in a struct acpi_processor *, so let's be more specific
about what we want.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_processor_init_pdc() isn't really doing anything interesting
with the struct acpi_processor * parameter. Its real job is to allocate
the buffer for the _PDC bits.

So rename the function to acpi_processor_alloc_pdc(), and just return
the struct acpi_object_list * it's supposed to allocate.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The x86 and ia64 implementations of the function in $subject are
exactly the same.

Also, since the arch-specific implementations of setting _PDC have
been completely hollowed out, remove the empty shells.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The only thing arch-specific about calling _PDC is what bits get
set in the input obj_list buffer.

There's no need for several levels of indirection to twiddle those
bits. Additionally, since we're just messing around with a buffer,
we can simplify the interface; no need to pass around the entire
struct acpi_processor * just to get at the buffer.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Both x86 and ia64 initialize _PDC with mostly common bit settings.

Factor out the common settings and leave the arch-specific ones alone.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The x86 and ia64 implementations of arch_acpi_processor_init_pdc()
are almost exactly the same. The only difference is in what bits
they set in obj_list buffer.

Combine the boilerplate memory management code, and leave the
arch-specific bit twiddling in separate implementations.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

arch dependent helper function that tells us if we should attempt to
evaluate _PDC on this machine or not.

The x86 implementation assumes that the CPUs in the machine must be
homogeneous, and that you cannot mix CPUs of different vendors.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We discovered that at least one machine (HP Envy), methods in the DSDT
attempt to call external methods defined in a dynamically loaded SSDT.

Unfortunately, the DSDT methods we are trying to call are part of the
EC initialization, which happens very early, and the the dynamic SSDT
is only loaded when a processor _PDC method runs much later.

This results in namespace lookup errors for the (as of yet) undefined
methods.

Since Windows doesn't have any issues with this machine, we take it
as a hint that they must be evaluating _PDC much earlier than we are.

Thus, the proper thing for Linux to do should be to match the Windows
implementation more closely.

Provide a mechanism to call _PDC before we enable the EC. Doing so loads
the dynamic tables, and allows the EC to be enabled correctly.

The ACPI processor driver will still evaluate _PDC in its .add() method
to cover the hotplug case.

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

Cc: ming.m.lin@intel.com
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

MSI strings should be ORed, not ANDed.

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

cc: stable@kernel.org
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix a win7 compability issue on Asus K50IJ.

Here is the _BCM method of this laptop:
                    Method (_BCM, 1, NotSerialized)
                    {
                        If (LGreaterEqual (OSFG, OSVT))
                        {
                            If (LNotEqual (OSFG, OSW7))
                            {
                                Store (One, BCMD)
                                Store (GCBL (Arg0), Local0)
                                Subtract (0x0F, Local0, LBTN)
                                ^^^SBRG.EC0.STBR ()
                                ...
                            }
                            Else
                            {
                                DBGR (0x0B, Zero, Zero, Arg0)
                                Store (Arg0, LBTN)
                                ^^^SBRG.EC0.STBR ()
                                ...
                            }
                        }
                    }
LBTN is used to store the index of the brightness level in the _BCL.
GCBL is a method that convert the percentage value to the index value.
If _OSI(Windows 2009) is not disabled, LBTN is stored a percentage
value which is surely beyond the end of _BCL package.

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

Due to the merge of processor_start() (declared with __cpuinit) into
processor_add(), a section mismatch warning appears:

WARNING: drivers/built-in.o(.text+0x4d59d): Section mismatch in reference
from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()
...

This patch fixes the warning by declaring processor_add() as __cpuinit
and also declares acpi_processor_add_fs() as __cpuinit as it is only
used in acpi_processor_add().
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>