Update some of the BIOS/EC version quirks.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Since the rfkill rework in 2.6.31, the driver is always resuming with
the radios disabled.

Change thinkpad-acpi to ask the firmware to resume with the radios in
the last state.  This fixes the Bluetooth and WWAN rfkill switches.

Note that it means we respect the firmware's oddities.  Should the
user toggle the hardware rfkill switch on and off, it might cause the
radios to resume enabled.

UWB is an unknown quantity since it has nowhere the same level of
firmware support (no control over state storage in NVRAM, for
example), and might need further fixing.  Testers welcome.

This change fixes a regression from 2.6.30.
Reported-by: NJerone Young <jerone.young@canonical.com>
Reported-by: NIan Molton <ian.molton@collabora.co.uk>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NIan Molton <ian.molton@collabora.co.uk>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

According to a report, the R50e wants EC-based brightness control,
even if it uses an Intel GPU.  The current driver default was reported
to not work at all.

This bug can be worked around by the "brightness_mode=3" module
parameter.

Change the default of the R50e and R51 2xxx models (which use the same
EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set
for now, as I'd like to get more reports.

This fixes a regression caused by commit
59fe4fe3,
"thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM"

Kernel 2.6.31 also needs this fix.
Reported-by: NFerenc Wagner <wferi@niif.hu>
Tested-by: NFerenc Wagner <wferi@niif.hu>
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 temperature in milidegree instead of degree, as sysfs-api requires
the temperature in milidegree.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Tested-by: NBorislav Petkov <petkovbb@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is a problem in the quirk tables used by tpacpi_is_fw_known() and
tpacpi_check_outdated_fw(), which causes outdated BIOSes that are lacking
the EC firmware ID DMI field to never match.

This breaks module loading on, e.g.  a T23 with outdated BIOS, and the
module will refuse to load unless the "force_load=1" parameter is given.

Fix the quirk tables so that they can also match the outdated BIOSes,
which in turn will both fix the module loading, and also warn the user
that he is using outdated firmware and should upgrade.

This fixes a serious regression, introduced by commit
e675abaf, "thinkpad-acpi: be more strict
when detecting a ThinkPad".

http://bugzilla.kernel.org/show_bug.cgi?id=14597Reported-by: NPaul Kimoto <kimoto@lightlink.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NPaul Kimoto <kimoto@lightlink.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The returned error should be negative
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Switching the camera takes 500ms, checking if it's on is almost free...
The BIOS remembers the setting through reboots, so there's good chance the
camera is already enabled.
Signed-off-by: NLuca Niccoli <lultimouomo@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

rt2860sta is fine with the patch as is, but iwl3945 isn't
(eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means
that we're back to causing the rt2860sta panic

This reverts commit b56ab33d.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

This works around what I think is actually a bug in rt2860sta which is
triggered when the hardware "disappears" from beneath the driver, i.e. when
wireless is toggled off via ACPI. It does so by ensuring that the rfkill
soft-block flag is set before the hardware is disabled.

I do not know whether this patch is required if rt2800pci is in use instead
of rt2860sta; at the time of submission of this patch, I've not been able to
test this.

(Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390)
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently the annotation for function eeepc_enable_camera() is
__init, and refers to a
function eeepc_hotk_add() which is non-init. Use __devinit for both
functions which is
more appropriate and fixes a section mismatch warning.

 We were warned by the following warning:

  LD      drivers/platform/x86/built-in.o
WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section
mismatch in reference from the function eeepc_hotk_add() to the
function .init.text:eeepc_enable_camera()
The function eeepc_hotk_add() references
the function __init eeepc_enable_camera().
This is often because eeepc_hotk_add lacks a __init
annotation or the annotation of eeepc_enable_camera is wrong.
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

A follow-up 2.6.32-rc1's

1e384cb0
"fujitsu-laptop: support led-class as module"

It's a trivial fix for one of the CONFIG_LEDS_CLASS ifdefs
which was somehow missed in the original patch.
Signed-off-by: NJonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: NLen Brown <len.brown@intel.com>

Without this, the hard-blocked state will be reported incorrectly if
the hardware switch is changed while the laptop is suspended.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: NNorbert Preining <preining@logic.at>
Acked-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet)...

After turning off and on again the hard-switch the events were right."

We can fix this by querying the firmware at load time and calling
rfkill_set_hw_state().
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: NNorbert Preining <preining@logic.at>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NMattia Dongili <malattia@linux.it>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes a warning when the module is unloaded on machines without SPIC.

------------[ cut here ]------------
WARNING: at drivers/base/driver.c:261 driver_unregister+0x6e/0x80()
Hardware name: OEM
Unexpected driver unregister!
Modules linked in: sony_laptop(-) rfkill af_packet i915
 drm i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect binfmt_misc
 ipv6 kvm_intel kvm acpi_cpufreq cpufreq_userspace cpufreq_powersave
 cpufreq_stats acpi_pad ac video output battery pci_slot sbs sbshc
 container iptable_filter ip_tables x_tables ext2 fuse
 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss
 snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event
 snd_seq snd_timer snd_seq_device snd fan sg serio_raw sr_mod cdrom
 soundcore button thermal processor thermal_sys floppy snd_page_alloc
 pcspkr intel_agp evdev [last unloaded: asus_atk0110]
Pid: 8136, comm: modprobe Not tainted 2.6.31-rc8debug #50
Call Trace:
[<ffffffff8121ec7e>] ? driver_unregister+0x6e/0x80
[<ffffffff81047577>] warn_slowpath_common+0x87/0xb0
[<ffffffff81047624>] warn_slowpath_fmt+0x64/0x70
[<ffffffff8119a360>] ? kobject_release+0x0/0x1f0
[<ffffffff8119a267>] ? kobject_put+0x27/0x60
[<ffffffff8121d346>] ? bus_put+0x16/0x20
[<ffffffff8121d406>] ? bus_remove_driver+0xb6/0xf0
[<ffffffff8121ec7e>] driver_unregister+0x6e/0x80
[<ffffffff811cab50>] acpi_bus_unregister_driver+0x10/0x12
[<ffffffffa035e86c>] sony_laptop_exit+0x2c/0x2e [sony_laptop]
[<ffffffff8107ddc6>] sys_delete_module+0x176/0x230
[<ffffffff8107186d>] ? trace_hardirqs_on_caller+0x14d/0x1a0
[<ffffffff81350a04>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8100bdab>] system_call_fastpath+0x16/0x1b
---[ end trace f638b6a59b19703e ]---
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

This is unnecessary as OSPM is supposed to call the method already when
the device is discovered.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

The SPIC irq is not really shareable, the IO port cannot be cleared and
always returns some data so there is no real way to understand if the irq
is for us or not. Moreover the _PRS acpi method says the irq is not
shareable.
In addition to this, in some cases, an additional write to the IO port has
to be performed in order to properly decode the event received from the
device. This generates another interrupt which may overlap with the
previous one. In the future this is going to be important for properly
decoding events.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Having separate drivers for SPIC showed to be useless, only type3 has a
slightly different behaviour than the others and there seem to be no real
conflict between them.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix this problem when CONFIG_THINKPAD_ACPI_HOTKEY_POLL is undefined:

  CHECK   drivers/platform/x86/thinkpad_acpi.c
drivers/platform/x86/thinkpad_acpi.c:1968:21: error: not an lvalue
  CC [M]  drivers/platform/x86/thinkpad_acpi.o
drivers/platform/x86/thinkpad_acpi.c: In function 'tpacpi_hotkey_driver_mask_set':
drivers/platform/x86/thinkpad_acpi.c:1968: error: lvalue required as left operand of assignment
Reported-by: NNoah Dain <noahdain@gmail.com>
Reported-by: NAudrius Kazukauskas <audrius@neutrino.lt>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Trigger a status update when the user hits a brightness key, allowing
userspace to present appropriate UI.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Reduce the number of magic numbers in the driver... note that they
were all explained and documented already.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add an internal API to the driver, to allow subdrivers to request and
receive HKEY 0x1000 events.  This API will be used by the backlight
(brightness up/down) and upcoming ALSA mixer (volume up/down/mute)
subdrivers.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Update the HKEY event driver to:

1. Handle better the second-gen firmware, which has no HKEY mask
   support but does report FN+F3, FN+F4 and FN+F12 without the need
   for NVRAM polling.

   a) always make the mask-related attributes available in sysfs;
   b) use DMI quirks to detect the second-gen firmware;
   c) properly report that FN+F3, FN+F4 and FN+F12 are enabled,
      and available even on mask-less second-gen firmware;

2. Decouple the issuing of hotkey events towards userspace from
   their reception from the firmware.  ALSA mixer and brightness
   event reporting support will need this feature.

3. Clean up the mess in the hotkey driver a great deal.  It is
   still very convoluted, and wants a full refactoring into a
   proper event API interface, but that is not going to happen
   today.

4. Fully reset firmware interface on resume (restore hotkey
   mask and status).

5. Stop losing polled events for no good reason when changing the
   mask and poll frequencies.  We will still lose them when the
   hotkey_source_mask is changed, as well as any that happened
   between driver suspend and driver resume.

The hotkey subdriver now has the notion of user-space-visible hotkey
event mask, as well as of the set of "hotkey" events the driver needs
(because brightness/volume change reports are not just keypress
reports in most ThinkPad models).

With this rewrite, the ABI level is bumped to 0x020500 should
userspace need to know it is dealing with the updated hotkey
subdriver.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

HKEY event 0x5010 is useless to us: old ThinkPads don't issue it.  Newer
ThinkPads won't issue it anymore.  And all ThinkPads issue 0x1010 and
0x1011 events.

Just silently drop it instead of sending it to userspace.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

hotkey_exit() is only called if hotkey_init() finished sucessfully, or
by direct calls inside hotkey_init().  The tp_features.hotkey test is
always true, and just adds to the confusion, remove it.  Also, avoid
calling hotkey_mask_set() when it won't do anything useful.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

backlight_device_register returns ERR_PTR() in case of problems, and
the current code would leave that ERR_PTR in ibm_backlight_device.

The current code paths won't touch it in that situation, but that could
change.  Make sure to set ibm_backlight_device to NULL in the error
path.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Added BIOS versions:
Acer: AOA110-v0.3307, AOA150-v0.3301, AOA150-v0.3307
Packard Bell: AOA150-v0.3105
Signed-off-by: NPeter Feuerer <peter@piie.net>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Borislav Petkov <petkovbb@googlemail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NPeter Feuerer <peter@piie.net>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

- Apply Borislav Petkov's patch (convert the fancmd[] array to a real
  struct thus disambiguating command handling and making code more
  readable.)

- Add BIOS product to BIOS table as AOA110 and AOA150 have different
  register values

- Add force_product parameter to allow forcing different product

- fix linker warning caused by "acerhdf_drv" not being named
  "acerhdf_driver"
Signed-off-by: NPeter Feuerer <peter@piie.net>
Cc: Andreas Mohr <andi@lisas.de>
Acked-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

rfkill_unregister() should always be followed by rfkill_destroy()
In this case, rfkill_destroy was called two times on wifi_rfkill and
never on bluetooth_rfkill.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This adds Topstar Laptop Extras ACPI driver. It enables hotkeys
functionality with Topstar N01 netbook. Besides hotkeys there are
other functions exposed by its ACPI firmware, but for now only
hotkeys reporting on Topstar N01 is supported. Topstar is a chinese
manufacturer, its website can be currently reached at
http://www.topstardigital.cn/Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Reviewed-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

rfkill_unregister() should always be followed by rfkill_destroy()
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Report KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN input events when the
ThinkPad is in "passive brightness control" mode (because either we or
ACPI video touched _BCL), and ACPI video is not processing these
events by itself.

This happens only on Lenovo ThinkPads with ACPI video support, when
operating with the ACPI video driver in acpi_backlight=vendor mode.

Issuing these events is the right thing to do, and will work around
bugzilla #13368, if userspace is properly configured and actively
handles these events.

For other ThinkPads, and when ACPI video is handling brightness
changes, thinkpad-acpi will continue NOT sending KEY_BRIGHTNESS*
events by default.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Init hotkey_source_mask late, so that we can make use of
hotkey_reserved_mask to avoid polling any of the reserved
hotkeys by default.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

echo "reset" > /proc/acpi/ibm/hotkey should do something non-useless,
so instead of setting it to Fn+F2, Fn+F3, Fn+F5, set it to
hotkey_recommended_mask.

It is not like it will survive for much longer, anyway.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some analysis of the ACPI DSDTs shows that the HKEY pre-enabled mask
is always 0x80c (FN+F3,FN+F4 and FN+F12), which are the hotkeys that
the second gen of HKEY firmware supported (the first gen didn't report
any hotkeys, the second reported these tree hotkeys but had no mask
support, and the third added mask support).

So, this is probably some sort of backwards compatibility with older
versions of the IBM ThinkVantage suite.  We have no use for that, and
I know of exactly ZERO users of that attribute, anyway.  Start the
process of getting rid of it.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix some locking, avoid exiting the kthread before kthread_stop() is
called on it, and clean up the hotkey poll routines a little bit.

Also, restore bits in the firmware mask after hotkey_source_mask is
changed.  Without this, we leave events disabled...
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

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>

The serio ports on i8042 are not completely isolated; while we provide
enough locking to ensure proper serialization when accessing control
and data registers AUX and KBD ports can still have an effect on each
other on PS/2 protocol level. The most prominent effect is that
issuing a command for the device connected to one port may cause
abort of the command currently executing by the device connected to
another port.

Since i8042 nor serio subsystem are not aware of the details of the
PS/2 protocol (length of the commands and their replies and so on) the
locking should be done on libps2 level by adding special handling when
we see that we are dealing with serio port on i8042.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>