Reduce the number of magic numbers in the driver... note that they
were all explained and documented already.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Peter Feuerer <peter@piie.net>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len 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: Peter Feuerer <peter@piie.net>
Cc: Andreas Mohr <andi@lisas.de>
Acked-by: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len 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: Corentin Chary <corentincj@iksaif.net>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len 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: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
rfkill_unregister() should always be followed by rfkill_destroy()
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len 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: Robert de Rooy <robert.de.rooy@gmail.com>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Signed-off-by: Len 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: Dmitry 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: Frans Pop <elendil@planet.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The 900A provides hotplug notifications on a different ACPI object to
other models.
Reported-by: Trevor <trevor.chart@gmail.com>
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
rfkill_unregister() should always be followed by rfkill_destroy()
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Len 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: Len 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: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Set the right maximum brightness which is one, because
they can only be on or off.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len 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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
All the rfkill devices are treated as "persistent", 3G is no exception.
This means their state may change over hibernation.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
