commit 2a908002c7b1b666616103e9df2419b38d7c6f1f upstream.

If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.

Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.

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

This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.

Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.

The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
  drm/i915: fix up error path leak in i915_cmdbuffer
  drm/i915: fix unpaired i915 device mutex on entervt failure.
  drm/i915: add support for G41 chipset
  drm/i915: Enable ASLE if present
  drm/i915: Unregister ACPI video driver when exiting
  drm/i915: Register ACPI video even when not modesetting
  drm/i915: fix transition to I915_TILING_NONE
  drm/i915: Don't let an oops get triggered from irq_emit without dma init.
  drm/i915: allow tiled front buffers on 965+

Linux-2.6.29 deleted the legacy ACPI idle handler, leaving
the CPU_IDLE handler, which does not track bus master activity.

So delete the unused bm_activity field -- it is confusing to
print an always zero value.

This patch could break programs that parse
/proc/acpi/processor/*/power, since it deletes this
line from that file:

bus master activity:     00000000

http://bugzilla.kernel.org/show_bug.cgi?id=13145
is not fixed by this patch, but provoked this patch.

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

The i915 DRM triggers registration of the ACPI video driver on load. It
should unregister it at unload in order to avoid generating backtraces on
being reloaded.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

Asus boards have an ACPI interface for interacting with the hwmon (fan,
temperatures, voltages) subsystem; this driver exposes the relevant
information via the standard sysfs interface.

There are two different ACPI interfaces:
- an old one (based on RVLT/RFAN/RTMP)
- a new one (GGRP/GITM)
Both may be present but there a few cases (my board, sigh) where the
new interface is just an empty stub; the driver defaults to the old one
when both are present.
The old interface has received a considerable testing, but I'm still
awaiting confirmation from my tester that the new one is working as
expected (hence the debug code is still enabled).

Currently all the attributes are read-only, though a (partial) control
should be possible with a bit more work.

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

unused

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

This patch adds support for ACPI device driver .notify() methods.  If
such a method is present, Linux/ACPI installs a handler for device
notifications (but not for system notifications such as Bus Check,
Device Check, etc).  When a device notification occurs, Linux/ACPI
passes it on to the driver's .notify() method.

In most cases, this removes the need for drivers to install their own
handlers for device-specific notifications.

For fixed hardware devices like some power and sleep buttons, there's
no notification value because there's no control method to execute a
Notify opcode.  When a fixed hardware device generates an event, we
handle it the same as a regular device notification, except we send
a ACPI_FIXED_HARDWARE_EVENT value.  This is outside the normal 0x0-0xff
range used by Notify opcodes.

Several drivers install their own handlers for system Bus Check and
Device Check notifications so they can support hot-plug.  This patch
doesn't affect that usage.

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>

Conflicts:
	arch/x86/kernel/cpu/cpufreq/longhaul.c

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