Merge branch 'x2apic' into release

Merge branch 'pnpacpi' into release

Merge branch 'dell-wmi' into release

Merge branch 'constify' into release

Merge branches 'bugzilla-12461' and 'bugzilla-9998' into release

Merge branch 'acpi_enforce_resources' into release

Merge branch 'async-battery' into release

Conflicts:
drivers/acpi/Makefile

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

Merge branch 'acpi-modparam' into release

Conflicts:
drivers/acpi/Makefile

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

Merge branch 'sony-laptop' into release

Merge branch 'thinkpad-acpi' into release

Merge branch 'acer' into release

Merge branch 'video' into release

Conflicts:
drivers/acpi/video.c

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

Merge branch 'psd' into release

Merge branch 'battery' into release

Merge branch 'hp-wmi' into release

Merge branch 'thermal' into release

Merge branch 'pmtimer-overflow' into release

Merge branch 'dynamic-ssdt' into release

Merge branch 'driver-ops-cleanup' into release

Merge branch 'bjorn-cleanups' into release

Merge branch 'bjorn-initcall-cleanup' into release

ACPI: battery: asynchronous init

The battery driver tends to take quite some time to initialize
(100ms-300ms is quite typical).
This patch initializes the batter driver asynchronously, so that other
things in the kernel can initialize in parallel to this 300 msec.

As part of this, the battery driver had to move to the back
of the ACPI init order (hence the Makefile change).
Without this move, the next ACPI driver would just block
on the ACPI/devicee layer semaphores until the battery driver was
done anyway, not gaining any boot time.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

acer-wmi: Update copyright notice & documentation

Explicitly note in the documentation that the Acer Aspire One is not
supported.

Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>

acer-wmi: Cleanup the failure cleanup handling

Cleanup the failure cleanup handling for brightness and email led.

[cc: Split out from another patch]

Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>

acer-wmi: Blacklist Acer Aspire One

The Aspire One's ACPI-WMI interface is a placeholder that does nothing,
and the invalid results that we get from it are now causing userspace
problems as acer-wmi always returns that the rfkill is enabled (i.e. the
radio is off, when it isn't). As it's hardware controlled, acer-wmi
isn't needed on the Aspire One either.

Thanks to Andy Whitcroft at Canonical for tracking down Ubuntu's userspace
issues to this.

Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Reported-by: Andy Whitcroft <apw@canonical.com>
Cc: stable@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>

video: build fix

acpi_video_device_write_state() and friends now return ssize_t,
while the constify patch assumed it was still int.

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

thinkpad-acpi: rework brightness support

Refactor and redesign the brightness control backend...

In order to fix bugzilla #11750...

Add a new brightness control mode: support direct NVRAM checkpointing
of the backlight level (i.e. store directly to NVRAM without the need
for UCMS calls), and use that together with the EC-based control.
Disallow UCMS+EC, thus avoiding races with the SMM firmware.

Switch the models that define HBRV (EC Brightness Value) in the DSDT
to the new mode.  These are: T40-T43, R50-R52, R50e, R51e, X31-X41.

Change the default for all other IBM ThinkPads to UCMS-only.  The
Lenovo models already default to UCMS-only.

Reported-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: enhanced debugging messages for the fan subdriver

Enhance debugging messages for the fan subdriver.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: enhanced debugging messages for the hotkey subdriver

Enhance debugging messages for the hotkey subdriver.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: enhanced debugging messages for rfkill subdrivers

Enhance debugging messages for all rfkill subdrivers in thinkpad-acpi.

Also, log a warning if the deprecated sysfs attributes are in use.
These attributes are going to be removed sometime in 2010.

There is an user-visible side-effect: we now coalesce attempts to
enable/disable bluetooth or WWAN in the procfs interface, instead of
hammering the firmware with multiple requests.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: restrict access to some firmware LEDs

Some of the ThinkPad LEDs indicate critical conditions that can cause
data loss or cause hardware damage when ignored (e.g. force-ejecting
a powered up bay; ignoring a failing battery, or empty battery; force-
undocking with the dock buses still active, etc).

On almost all ThinkPads, LED access is write-only, and the firmware
usually does fire-and-forget signaling on them, so you effectively
lose whatever message the firmware was trying to convey to the user
when you override the LED state, without any chance to restore it.

Restrict access to all LEDs that can convey important alarms, or that
could mislead the user into incorrectly operating the hardware.  This
will make the Lenovo engineers less unhappy about the whole issue.

Allow users that really want it to still control all LEDs, it is the
unaware user that we have to worry about.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: remove HKEY disable functionality

The HKEY disable functionality basically cripples the entire event
model of the ThinkPad firmware and of the thinkpad-acpi driver.
Remove this functionality from the driver.  HKEY must be enabled at
all times while thinkpad-acpi is loaded, and disabled otherwise.

For sysfs, according to the sysfs ABI and the thinkpad-acpi sysfs
rules of engagement, we will just remove the attributes.  This will be
done in two stages: disable their function now, after two kernel
releases, remove the attributes.

For procfs, we call WARN().  If nothing triggers it, I will simply
remove the enable/disable commands entirely in the future along with
the sysfs attributes.

I don't expect much, if any fallout from this.  There really isn't any
reason to mess with hotkey_enable or with the enable/disable commands
to /proc/acpi/ibm/hotkey, and this has been true for years...

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: add new debug helpers and warn of deprecated atts

Add a debug helper that discloses the TGID of the userspace task
attempting to access the driver.  This is highly useful when dealing
with bug reports, since often the user has no idea that some userspace
application is accessing thinkpad-acpi...

Also add a helper to log warnings about sysfs attributes that are
deprecated.

Use the new helpers to issue deprecation warnings for bluetooth_enable
and wwan_enabled, that have been deprecated for a while, now.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: add missing log levels

Add missing log levels in a standalone commit, to avoid dependencies in
future unrelated changes, just because they wanted to use one of the
missing log levels.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: cleanup debug helpers

Fix the vdbg_printk macro definition to be sane when
CONFIG_THINKPAD_ACPI_DEBUG is undefined, and move the mess into a file
section of its own.

This doesn't change anything in the current code, but future code will
need the proper behaviour.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: documentation cleanup

Some cleanups to the documentation of the driver.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: drop ibm-acpi alias

The driver was renamed two years ago, on 2.6.21.  Drop the old
compatibility alias, we have given everybody quite enough time
to update their configs to the new name.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

thinkpad-acpi: update copyright notices

It is that time of the year again...

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: constify VFTs (2/2)

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: constify VFTs (1/2)

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Len Brown <len.brown@intel.com>

dell-wmi: new driver for hotkey control

Add a WMI driver for Dell laptops. Currently it does nothing but send a
generic input event when a button with a picture of a battery on it is
pressed, but maybe other uses will appear over time.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

Enable PNPACPI _PSx Support, v3

(This is an update to the patch presented earlier in
http://lkml.org/lkml/2008/12/8/284, with new error handling.)

This patch sets the power of PnP ACPI devices to D0 when they
are activated and to D3 when they are disabled.  The latter is
in correspondence with the ACPI 3.0 specification, whereas the
former is added in order to be able to power up a device after
it has been previously disabled (or when booting up a system).
(As a consequence, the patch makes the PnP ACPI code more ACPI
compliant.)

Section 6.2.2 of the ACPI Specification (at least versions 1.0b
and 3.0a) states: "Prior to running this control method [_DIS],
the OS[PM] will have already put the device in the D3 state."
Unfortunately, there is no clear statement as to when to put
a device in the D0 state. :-( Therefore, the patch executes the
method calls as _PS3/_DIS and _SRS/_PS0. What is clear: "If the
device is disabled, _SRS enables the device at the specified
resources." (From the ACPI 3.0a Specification.)

The patch fixes a problem with some IBM ThinkPads (at least the
600E and the 600X) where the serial ports have a dedicated
power source that needs to be brought up before the serial port
can be used.  Without this patch, the serial port is enabled
but has no power. (In the past, the tpctl utility had to be
utilized to turn on the power, but support for this feature
stopped with version 5.9 as it did not support the more recent
kernel versions.)

The error handlers that handle any errors that can occur during
the power up/power down phases return the error codes to the
caller directly.  Comments welcome! :-)

No regressions were observed on hardware that does not require
this patch.

The patch is applied against 2.6.27.x.

Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: update x2apic comments

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

x86, ACPI: add support for x2apic ACPI extensions

All logical processors with APIC ID values of 255 and greater will have their
APIC reported through Processor X2APIC structure (type-9 entry type) and all
logical processors with APIC ID less than 255 will have their APIC reported
through legacy Processor Local APIC (type-0 entry type) only. This is the
same case even for NMI structure reporting.

The Processor X2APIC Affinity structure provides the association between the
X2APIC ID of a logical processor and the proximity domain to which the logical
processor belongs.

For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
objects in the ACPI namespace.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: fix event reporting for new style events

In short Fn key events are always reported through acpi.
The input layer gets all the old style events and only those new style
events that, after being decoded, are mapped to an locally represented
events.
rfkill only update the rfkill device status.

Signed-off-by: Matthias Welwarsky <matze@welwarsky.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop should depend on RFKILL

Fixes this build error when RFKILL is not set:

drivers/platform/x86/sony-laptop.c:1050: undefined reference to `rfkill_unregister'
and so on..

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: new style events typo fixes

Signed-off-by: Matthias Welwarsky <matze@welwarsky.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Fix some typos in log messages (Unabe/Unable)

Signed-off-by: Alessio Igor Bogani <abogani@texware.it>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: Remove R40e c-state blacklist

The recent ACPICA patch
(ACPICA: FADT: Favor 32-bit register addresses for compatibility)
makes machine to use the right FADT HW addresses
and C-states now work fine.

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

Signed-off-by: Thomas Renninger <trenn@suse.de>
Tested-by: Mark Doughty <me@markdoughty.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: simplify processor lines in Makefile

Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: acpi_enforce_resource=strict by default

Enforce strict resource checking - disallowing access by native
drivers to IO ports and memory regions claimed by ACPI firmware.

The patch is mainly aimed to block native hwmon drivers from touching
monitoring chips that ACPI thinks it own.

If this causes a regression, boot with "acpi_enforce_resources=lax"
which was the previous default.

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

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: simplify module_param namespace

Impact: cleanup

Rather than overriding MODULE_PARAM_PREFIX, build via acpi.o so
KBUILD_MODNAME is set to "acpi".

This is the logical way to do it, even though acpi cannot be a module
due to these config options being bool.  Those parts of ACPI which can
be modular are not built into the acpi "module".

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: EC: Always parse EC device

If ECDT info is not valid, we have last chance to configure
EC driver properly at this point, don't miss it.

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

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: EC: Separate delays for MSI hardware

MSI notebooks require very strict delays, while all others
are happy with msleep().

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

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: fix CONFIG_ACPI=n build

drivers/gpu/drm/i915/i915_drv.c:102: error: too many arguments to
function ‘intel_opregion_init’

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

ACPI video: add a warning message if _BQC is not found

ACPI backlight control w/o _BQC support is kinda firmware bug.
Add a warning if _BQC is not implemented.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: battery: add power_{now,avg} properties to power_class

ACPI has smart batteries, which work in units of energy and measure
rate of (dis)charge as power, thus it is not appropriate to export it
as a current_now. Current_now will still be exported to allow
for userland applications to match.

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: Populate DIDL before registering ACPI video device on Intel

Intel graphics hardware that implements the ACPI IGD OpRegion spec
requires that the list of display devices be populated before any ACPI
video methods are called. Detect when this is the case and defer
registration until the opregion code calls it. Fixes crashes on HP
laptops.

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

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: support buggy BIOSes with _BCQ implemented

Some buggy BIOSes implements _BCQ instead of _BQC.
Male ACPI video driver support these buggy BIOS.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: support _BQC/_BCL/_BCM methods that use index values

The input/output of _BQC/_BCL/_BCM control methods should be represented
by a number between 0 and 100, and can be thought of as a percentage.
But some buggy _BQC/_BCL/_BCM methods use the index values instead.
http://bugzilla.kernel.org/show_bug.cgi?id=12302
http://bugzilla.kernel.org/show_bug.cgi?id=12249
http://bugzilla.kernel.org/show_bug.cgi?id=12037

Add the functionality to support such kind of BIOSes in ACPI video driver.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: support reversed _BCL method in  ACPI video driver

The brightness levels returned by _BCL package are in a reversed order
on some laptops.
http://bugzilla.kernel.org/show_bug.cgi?id=12037
http://bugzilla.kernel.org/show_bug.cgi?id=12302
http://bugzilla.kernel.org/show_bug.cgi?id=12235

sort the _BCL packge in case it's reversed.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: support _BCL packages that don't export brightness levels when machine is on AC/Battery

Many buggy BIOSes don't export the brightness levels when machine
is on AC/Battery in the _BCL method.

Reformat the _BCL package for these laptops:
now the elements in device->brightness->levels[] are like:
levels[0]: brightness level when on AC power.
levels[1]: brightness level when on Battery power.
levels[2]: supported brightness level 1.
levels[3]: supported brightness level 2.
...
levels[n]: supported brightness level n-1.
levels[n + 1]: supported brightness level n.
So if there are n supported brightness levels on this laptop,
we will have n+2 entries in device->brightnes->levels[].

level[0] and level[1] are invalid on the laptops that don't
export the brightness levels on AC/Battery.
Fortunately, we never use these two values at all, even for the
valid ones.

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

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: check the return value of acpi_video_device_lcd_set_level

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI video: check the return value of acpi_video_device_lcd_get_level_current

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: Avoid wiping out pr->performance during preregistering

When cpufreq driver call acpi_processor_preregister_performance() , function
will clean up pr->performance even if there is possibly already registered
other cpufreq driver. The patch fix this potential problem. It also remove
double checks in P domain basic validity code and move these checks to function
where _PSD data is captured.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: remove unused acpi_bus_ops flags

In acpi_bus_ops, only the acpi_op_add and acpi_op_start flags are used,
so remove all the rest.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: remove unused acpi_device_ops .shutdown method

No drivers use the .shutdown method, so remove it.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: remove unused acpi_device_ops .lock and .scan methods

No drivers use the .lock and .scan methods, and the Linux/ACPI
code doesn't even provide a way to invoke them, so remove them.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

thermal: support forcing support for passive cooling

Due to poor thermal design or Linux driving hardware outside its thermal
envelope, some systems will reach critical temperature and shut down
under high load. This patch adds support for forcing a polling-based
passive trip point if the firmware doesn't provide one. The assumption
is made that the processor is the most practical means to reduce the
dynamic heat generation, so hitting the passive thermal limit will cause
the CPU to be throttled until the temperature stabalises around the
defined value.

UI is provided via a "passive" sysfs entry in the thermal zone
directory. It accepts a decimal value in millidegrees celsius, or "0" to
disable the functionality. Default behaviour is for this functionality
to be disabled.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: update thermal for bus_id removal

> drivers/acpi/thermal.c: In function 'thermal_notify':
> drivers/acpi/thermal.c:768: error: 'struct device' has no member named 'bus_id'
>
> Caused by commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e ("ACPI: move
> thermal trip handling to generic thermal layer") interacting with commit
> d4a078fca590911cdf87a8eaffee1b6e643c2558 ("driver core: get rid of struct
> device's bus_id string array").
>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: cpufreq: use new bit register access function

> arch/x86/kernel/cpu/cpufreq/longhaul.c: In function 'longhaul_setstate':
> arch/x86/kernel/cpu/cpufreq/longhaul.c:308: error: implicit declaration of function 'acpi_set_register'

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Compile-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: tidy up makefile

This patch removes the suggestion that ec.o link order is important,
because it doesn't matter since acpi_ec_init() is no longer an initcall.
And it puts together most of the core modules that are not configurable.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_wakeup_device_init() directly.
Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7).

acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which
is populated when ACPI devices are enumerated by acpi_init() ->
acpi_scan_init().  Using late_initcall is certainly enough to make
sure acpi_wakeup_device_list is populated, but it is more than
necessary.  We can just as easily call acpi_wakeup_device_init()
directly from acpi_init(), which avoids the initcall magic.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_sleep_proc_init() directly.
Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7),
apparently to make sure that the /proc hierarchy already exists:

    2003/02/13 12:38:03-06:00 mochel
    acpi sleep: demote sleep proc file creation.

    - Make acpi_sleep_proc_init() a late_initcall(), and not called from
      acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at
      least there when we create the dang file.

This should no longer be an issue because acpi_bus_init() (called early
in acpi_init()) creates acpi_root_dir (/proc/acpi).

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call init_acpi_device_notify() explicitly rather than as initcall

This patch makes acpi_init() call init_acpi_device_notify() directly.
Previously, init_acpi_device_notify() was an arch_initcall (sequence 3),
so it was called before acpi_init() (a subsys_initcall at sequence 4).

init_acpi_device_notify() sets the platform_notify and
platform_notify_remove function pointers.  These pointers
are not used until acpi_init() enumerates ACPI devices in
this path:

    acpi_init()
    acpi_scan_init()
acpi_bus_scan()
    acpi_add_single_object()
acpi_device_register()
    device_add()
<use platform_notify>

So it is sufficient to have acpi_init() call init_acpi_device_notify()
directly before it enumerates devices.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_debug_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_debug_init() directly.
Previously, both were subsys_initcalls.  acpi_debug_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_system_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_system_init() directly.
Previously, both were subsys_initcalls.  acpi_system_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_power_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_power_init() directly.
Previously, both were subsys_initcalls.  acpi_power_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_ec_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_ec_init() directly.
Previously, both were subsys_initcalls.  acpi_ec_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: call acpi_scan_init() explicitly rather than as initcall

This patch makes acpi_init() call acpi_scan_init() directly.

Previously, both acpi_init() and acpi_scan_init() were subsys_initcalls,
and acpi_init() was called first based on the link order from the
makefile (bus.o before scan.o).

acpi_scan_init() registers the ACPI bus type, creates the root device,
and enumerates fixed-feature and namespace devices.  All of this must
be done after acpi_init(), and it's better to call acpi_scan_init()
explicitly rather than rely on the link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPI: skip DMI power state check when ACPI disabled

This patch makes acpi_init() exit early when ACPI is disabled.
This skips a DMI check that affects ACPI power management.   The
DMI check prints a notice that is misleading when ACPI is disabled.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Kill the BKL

Signed-off-by: Alessio Igor Bogani <abogani@texware.it>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: update copyright

Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Make sony_pic_set_wwanpower not take mutexes

For consistency with __sony_pic_set_bluetoothpower, this is also needed
later to allow setting the wwanpower attribute from the resume path and
only lock the mutex once.

Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Add FW specific hotkey events

Signed-off-by: Anton Veretenenko <anton@veretenenko.ru>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: notify the hardware of a state change in wwanpower

Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: detect the ICH9 chipset as Type3

Signed-off-by: ISHIKAWA Mutsumi <ishikawa@hanzubon.jp>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Eliminate BKL in ioctls

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: VGN-A317M hotkey support

This laptop has 5 SPIC managed buttons above the keyboard:
sound + and - as well as brightness, zoom and S1.
Possibly the entire VGN-A serie behaves the same.

Signed-off-by: Harald Jenny <harald@a-little-linux-box.at>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: merge Type4 into Type3

Creating Type4 was a mistake in the first place. Some users report that
also Type3 vaios require the same extra hotkey handling which the Type4
for was menat to guard from.
Merging down Type4 into Type3 will just remove a useless distinction.

Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Add support for extended hotkeys

Recent Sony SR-series machines have an additional set of buttons accessed
via the 0x127 method rather than the 0x100 method. Add support for these.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Add rfkill support on new models

Newer Vaios provide a full featured rfkill implementation via their
platform methods. Add support for enumerating the available devices and
providing rfkill access to them. Support for the physical kill switch is
added, with the devices moving into the HARD_BLOCKED state when toggled.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Add support for extra keyboard events

The current sony-laptop code assumes that the keyboard event method is
always located at slot 2 in the platform code. Remove this assumption and
add support for some additional hotkeys.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Enable EC on newer hardware

The latest Vaios can execute certain codepaths in two ways - either using
system management mode or using pure ACPI methods. The latter is only used
if the OS has called the ECON method. Ensure that this is done where the
method is available.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

sony-laptop: Add support for new Sony platform API

Newer Sony Vaios provide a new API for accessing platform functionality. It
consists of a set of standardised methods for enabling events and performing
queries. These are each identified by a unique handle. This patch adds
support for calling functions based on their handle and ports the existing
code for these machines over to it.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPICA: Update version to 20090320

Version 20090320.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPICA: Fix index value in package warning message

For predefined method validation. Index value in warning message
could be off by one.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPICA: FADT: Favor 32-bit FACS and DSDT addresses

If both the 32-bit and 64-bit addresses are non-null, use the
32-bit address. Provides Windows compatibility.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPICA: FADT: Favor 32-bit register addresses for compatibility

Use the 32-bit register addresses whenever they are non-zero. This
means that the 32-bit addresses are favored over the 64-bit
(GAS) addresses. The 64-bit addresses are only used if the 32-bit
addresses are zero. This change provides compatibility with all
versions of Windows. The worst case that this solves is when both
the 32-bit and 64-bit addresses are non-zero, but only the 32-bit
addresses are actually valid. This appears to happen in some
BIOSes because in this case, Windows uses the 32-bit addresses.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

ACPICA: Fix PCI configuration space port address range

Microsoft website uses 0xCF8-0xD00. Should be 0xCF8-0xCFF (Two
32-bit registers.)

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>