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>

Gets rid of the following warning:

Platform driver 'hp-wmi' needs updating - please use dev_pm_ops

I tested that the resume handler still works on my HP 2510p notebook.

[rjw: Fixed up the definition of hp_wmi_pm_ops.]
Signed-off-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The 900A provides hotplug notifications on a different ACPI object to
other models.
Reported-by: NTrevor <trevor.chart@gmail.com>
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

rfkill_unregister() should always be followed by rfkill_destroy()
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
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>

Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
however, not all ACPI drivers use/want it -- and they
should not have to #undef PREFIX to define their own.

Add GPL commment to internal.h while we are there.

This does not change any actual console output,
asside from a whitespace fix.
Signed-off-by: NLen Brown <len.brown@intel.com>

checkpatch doesn't like tab+space for a return statement.

WARNING: suspect code indent for conditional statements (8, 17)
+	if (!device)
+		 return -EINVAL;
Signed-off-by: NLen Brown <len.brown@intel.com>

Found on UX50V.
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>

Add support for the Fn+F3/Fn+F4 keys and map them
as KEY_KBDILLUMUP and KEY_KBDILLUMDOWN.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add support for keyboard backlight found in Asus U50VG.

The SMC driver for the Apples does it via LED. To be
consistent with that we create /sys/class/leds/asus::kbd_backlight/
to control the keyboard backlight.

SLKB and GLKB are used to get/set the backlight. On
the U50VG is supports 4 brightness level, but this may
change with other models.

SLKB take a 8 bit integer where the higher bit is used
to toggle the backlight, and the over 7 bits control the
brightness level.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Set the right maximum brightness which is one, because
they can only be on or off.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Map some new hotkeys found on X50R.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add support for getting led brightness directly from
the hardware. Currently we don't need it, but it is needed
to support keyboard backlight/led.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Show HRWS in /sys/platform/devices/asus-laptop/infos.
HRWS is a bitfield used to get information about Hardware
available in the laptop.
Also change sprintf format from 0x%04x to %#x.
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>

This also involves switching the resume handler from the acpi device
to the platform device.  Using the more fine grained handlers allows
two improvements:

1. We only need to recheck rfkill state after resume from hibernation.

2. The wireless LED workaround accounts for up to 1.1s out of 1.7s
resuming devices (when wireless is enabled).  We can limit the
workaround to thaw(), so that it only delays suspend to disk.

The workaround is only likely to help when hibernation is aborted.
Suspend to ram cannot be aborted by the user.  Device suspend errors may
well happen before eeepc-laptop would even be frozen.  Suspend errors
which happen after that could be pretty funky anyway.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Actually it is only the LED which is affected.  The bios bug does not
disable the wifi.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>