Use stricter checks to decide that we're running on a supported ThinkPad.
This should remove some possible false positives, although nobody ever
bothered to report any.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use the quirk infrastructure to warn of outdated firmware and also of
firmware versions that are known to cause problems.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

X40 (firmware 1V) and T41 (firmware 1R) have been confirmed to work
well with the new defaults, so we can stop pestering people to confirm
that fact.

For now, whitelist just these two firmware types.  It is best to have
at least one more firmware type confirmed for Radeon 9xxx and Intel
GMA-2 ThinkPads before removing the confirmation requests entirely.
Reported-by: NRobert de Rooy <robert.de.rooy@gmail.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Return from bt_rfkill_poll() when hci_get_radio_state() fails.

value is invalid in that case and should not be assigned to the rfkill
state.

This also fixes a double unlock bug.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Summary:
Kernel panic arise when stack protection is enabled, since strncat will
add a null terminating byte '\0'; So in functions
like this one (wmi_query_block):
        char wc[4]="WC";
	....
	strncat(method, block->object_id, 2);
        ...
the length of wc should be n+1 (wc[5]) or stack protection
fault will arise. This is not noticeable when stack protection is
disabled,but , isn't good either.
Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y,
	      CONFIG_CC_STACKPROTECTOR=y]

Panic Trace
------------
       .... stack-protector: kernel stack corrupted in : fa7b182c
       2.6.30-rc8-obelisco-generic
       call_trace:
           [<c04a6c40>] ? panic+0x45/0xd9
	   [<c012925d>] ? __stack_chk_fail+0x1c/0x40
	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
	   [<fa7e7000>] ? acer_wmi_init+0x00/0x61a [acer_wmi]
	   [<fa7e7135>] ? acer_wmi_init+0x135/0x61a [acer_wmi]
	   [<c0101159>] ? do_one_initcall+0x50+0x126

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514Signed-off-by: NCostantino Leandro <lcostantino@gmail.com>
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Len Brown <len.brown@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

OOPS on resume when the wireless adaptor is disabled during suspend was
introduced by "eeepc-laptop: read rfkill soft-blocked state on resume".

Unable to handle kernel NULL pointer dereference

Process s2disk
Tainted: G W
IP: klist_put

Call trace:
? klist_del
? device_del
? device_unregister
? pci_stop_dev
? pci_stop_bus
? pci_remove_device
? eeepc_rfkill_hotplug [eeepc_laptop]
? eeepc_hotk_resume [eeepc_laptop]
? acpi_device_resume
? device_resume
? hibernation_snapshot

It appears the PCI device is removed twice.  The eeepc_rfkill_hotplug()
call from the resume handler is racing against the call from the ACPI
notifier callback.  The ACPI notification is triggered by the resume
handler when it refreshes the value of CM_ASL_WLAN.

The fix is to serialize hotplug calls using a workqueue.

http://bugzilla.kernel.org/show_bug.cgi?id=13825Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

HBRV-based default selection of backlight control strategy didn't work
well, at least the X41 defines it but doesn't use it and I don't think
it will stop there.

Switch to a white/blacklist.  All models that have HBRV defined have
been included in the list, and initially all ATI GPUs will get
ECNVRAM, and the Intel GPUs will get UCMS_STEP.

Symptoms of incorrect backlight mode selection are:

1. Non-working backlight control through sysfs;

2. Backlight gets reset to the lowest level at every shutdown, reboot
   and when thinkpad-acpi gets unloaded;

This fixes a regression in 2.6.30, bugzilla #13826
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

The standard ACPI dock driver can handle the hotplug bays and docks of
the ThinkPads just fine (including batteries) as of 2.6.27, and the
code in thinkpad-acpi for the dock and bay subdrivers is currently
broken anyway...

Userspace needs some love to support the two-stage ejection nicely,
but it is simple enough to do through udev rules (you don't even need
HAL) so this wouldn't justify fixing the dock and bay subdrivers,
either.

That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
as support for the weird dock of the model 570, but since such support
has never left the "experimental" stage, it is also not a strong
enough reason to find a way to fix this code.

Users of ThinkPads with warm-swap bays are urged to request that _EJ3
support be added to the regular ACPI dock driver, if such feature is
indeed useful for them.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently, the ThinkPad-ACPI bay and dock drivers are completely
broken, and cause a NULL pointer derreference in kernel mode (and,
therefore, an OOPS) when they try to issue events (i.e. on dock,
undock, bay ejection, etc).

OTOH, the standard ACPI dock driver can handle the hotplug bays and
docks of the ThinkPads just fine (including batteries) as of 2.6.27.
In fact, it does a much better job of it than thinkpad-acpi ever did.

It is just not worth the hassle to find a way to fix this crap without
breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
deprecated code that sees little testing or use.

As a quick fix suitable for -stable backports, mark the thinkpad-acpi
bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
removed by a later patch.

This fixes bugzilla #13669, and should be applied to 2.6.27 and later.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: NJoerg Platte <jplatte@naasa.net>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Some systems may not support input events, or registering the input
handler may have failed. So check that an input device exists before
trying to set the docking and tablet mode state during resume.

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13865Reported-and-tested-by: NCédric Godin <cedric@belbone.be>
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NMatthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix another polarity error introduced by the rfkill rewrite,
this time in acer_rfkill_set().
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix the third (I think) polarity error I accidentally
introduced in the rfkill rewrite to make wireless work
again on (certain?) HP laptops.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

FYI, there's a post-rc1 build regression with certain configs:

 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb166): undefined reference to `pci_hp_remove_module_link'
 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb19f): undefined reference to `pci_destroy_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb583): undefined reference to `pci_create_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb5b1): undefined reference to `pci_hp_create_module_link'
 make: *** [.tmp_vmlinux1] Error 1

Caused by:

| 2b121bc2 is first bad commit
| commit 2b121bc2
| Date:   Thu Jun 25 13:25:36 2009 +0200
|
|     eeepc-laptop: Register as a pci-hotplug device

which changed the driver to use the PCI hotplug infrastructure, but
didn't do a good job on the Kconfig rules.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJanne Grunau <j@jannau.net>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

CMSG is an ACPI method used to find features available on
an Eee PC. But some features are never repported, even if present.

If the getter of a feature is present, this patch will set
the corresponding bit in cmsg.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

If there is there is no getter defined, get_acpi()
will return -ENODEV.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Refactor rfkill code, because we'll add another
rfkill for wwan3g later.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the unusual printk(EEEPC_<level> uses to
the more standard pr_fmt and pr_<level>(.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Tested-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the unusual printk(ASUS_<level> uses to
the more standard pr_fmt and pr_<level>(.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Limit cpufv input to acceptables values.
Add an available_cpufv file to show available
presets.
Change cpufv ouput format from %d to %#x, it won't
break compatibility with existing userspace tools, but
it provide a more human readable output.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

In the default Eee PC distribution, there is a modified
asus_acpi driver. eeepc-laptop is a cleaned version of this
driver. Sync ASL enum and getter/setters with asus_acpi.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

asus-laptop have been merged in the kernel two years ago,
it is now stable and used by most distribution instead of
the old asus_acpi driver.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The bug tracker have moved from sourceforge to
http://dev.iksaif.net . The homepage of the project
is now http://acpi4asus.sf.net with links to the new
bug tracker. No change for the mailing list.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Makes asus-laptop platform device the parent device of
backlight and led classes.

With this patch, leds and backlight are also available in
/sys/devices/platform/asus-laptop/ like thinkpad_acpi.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

If we leave the camera disabled by default, userspace programs (e.g.
Skype, Cheese) leave the user out in the cold saying that the machine
"has no camera." Therefore, it's better to enable camera by default and
let people who really don't want it just disable the thing.

To reduce power usage you should enable USB autosuspend:
echo -n auto > /sys/bus/usb/drivers/uvcvideo/*:*/../power/level
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Acerhdf is a driver for Acer Aspire One netbooks. It allows
to access the temperature sensor and to control the fan.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Signed-off-by: NAndreas Mohr <andi@lisas.de>
Signed-off-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

"rfkill: rewrite" incorrectly reversed
the meaning of 'state' in acer_rfkill_update() when it changed
rfkill_force_state() to rfkill_set_sw_state().  Fix it.
Signed-off-by: NTroy Moure <twmoure@szypr.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will respect state changes over hibernation, e.g. if the user
disables the wireless in the BIOS setup screen.

It reveals an issue where ACPI silently kills the wireless on
suspend.  Normally, the BIOS restores the correct state from
non-volatile storage on boot.  But when hibernation is aborted,
the wireless would remain killed.  Fortunately we can work around
this in the resume handler by simply writing back the same value we
read from NVS.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The setting of the "persistent" flag is also made more explicit using
a new rfkill_init_sw_state() function, instead of special-casing
rfkill_set_sw_state() when it is called before registration.

Suspend is a bit of a corner case so we try to get away without adding
another hack to rfkill-input - it's going to be removed soon.
If the state does change over suspend, users will simply have to prod
rfkill-input twice in order to toggle the state.

Userspace policy agents will be able to implement a more consistent user
experience.  For example, they can avoid the above problem if they
toggle devices individually.  Then there would be no "global state"
to get out of sync.

Currently there are only two rfkill drivers with persistent soft-blocked
state.  thinkpad-acpi already checks the software state on resume.
eeepc-laptop will require modification.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Marcel Holtmann <marcel@holtmann.org>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support reading the tachometer of the auxiliary fan of a X60/X61.

It was found out by sheer luck, that bit 0 of EC register 0x31
(formely HBRV) selects which fan is active for tachometer readings
through EC 0x84/0x085: 0 for fan1, 1 for fan2.

Many thanks to Christoph Kl??nter, to Whoopie, and to weasel, who
helped confirm that behaviour.

Fan control through EC HFSP applies to both fans equally, regardless
of the state of bit 0 of EC 0x31.  That matches the way the DSDT uses
HFSP.

In order to better support the secondary fan, export a second
tachometer over hwmon, and add defensive measures to make sure we are
reading the correct tachometer.

Support for the second fan is whitelist-based, as I have not found
anything obvious to look for in the DSDT to detect the presence of
the second fan.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Forcing thinkpad-acpi to do EC-based brightness control (HBRV) on a
X61 has very... interesting effects, instead of doing nothing (since
it doesn't have EC-based backlight control), it causes "weirdness" in
the fan tachometer readings, for example.

This means the EC register that used to be HBRV has been reused by
Lenovo for something else, but they didn't remove it from the DSDT.

Make sure the documentation reflects this data, and forbid the user
from forcing the driver to access HBRV on Lenovo ThinkPads.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch adds a .notify() method.  The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.

This driver relies on seeing system notify events, not device-specific
ones (because it used ACPI_SYSTEM_NOTIFY).  We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events, then
just ignore any device events we get.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: Corentin Chary <corentincj@iksaif.net>
CC: acpi4asus-user@lists.sourceforge.net
CC: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch adds a .notify() method.  The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.

This driver relies on seeing system notify events, not device-specific
ones (because it used ACPI_SYSTEM_NOTIFY).  We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events, then
just ignore any device events we get.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: Corentin Chary <corentincj@iksaif.net>
CC: Karol Kozimor <sziwan@users.sourceforge.net>
CC: acpi4asus-user@lists.sourceforge.net
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch adds a .notify() method.  The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.

This driver apparently relies on seeing ALL notify events, not just
device-specific ones (because it used ACPI_ALL_NOTIFY).  We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: Corentin Chary <corentincj@iksaif.net>
CC: acpi4asus-user@lists.sourceforge.net
Signed-off-by: NLen Brown <len.brown@intel.com>

HP tablets send a WMI event when a tablet state change occurs, but use the
same method as is used for reporting docking and undocking. The same query
is used to obtain the state of the hardware. Bit 0 indicates the docking
state, while bit 2 indicates the tablet state. This patch breaks these out
and sends separate input events for tablet and dock state changes. An
additional sysfs file is added to report the tablet state.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There's no point in generating kernel messages if we didn't receive a
parsable keyboard event - only do so if there appeared to be a scancode.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>