Without this, the hard-blocked state will be reported incorrectly if
the hardware switch is changed while the laptop is suspended.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
Acked-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: John 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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Mattia Dongili <malattia@linux.it>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.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>
rfkill_set_sw_state() will already be called by eeepc_rfkill_hotplug().
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>
Sysfs showed the ehotk input device as a "virtual" device - lies!
The input device is provided by a physical device, the eeepc platform.
This requires that we move the creation of the input device to come
after platform device is created. Input initialization is moved from
ehotk_check() [sic] to a new function called eeepc_input_init(). This
brings the input device into line with the other eeepc-laptop devices.
Also, refuse to load if we fail to register the input device.
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>
1. input and backlight devices were registered after acpi notifications
are enabled. This left a window where eeepc_hotk_notify() might
find these devices in an inconsistent (half-initialized) state.
-> Move all device registration into eeepc_hotk_add(), which is called
before enabling acpi notifications.
2. input and backlight devices were unregistered before acpi
notifications are disabled. This left a window where
eeepc_hotk_notify() might find these devices in an inconsistent
(half-destroyed) state.
-> Move all device unregistration into eeepc_hotk_remove(), which is
called after disabling acpi notifications.
3. The acpi driver was not freed if an error occured further down in
eeepc_laptop_init().
-> The rest of eeepc_laptop_init() has been moved to eeepc_hotk_add(),
so this is no longer a problem.
4. The acpi driver was unregistered before the platform driver. This
left a window where a sysfs access could attempt to read the ehotk
structure after it had been freed by eeepc_hotk_remove().
-> The acpi driver is now unregistered as the last step in
eeepc_laptop_exit(), so this is no longer a problem.
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>
Wifi rfkill state changes can race with pci hotplug cleanup. A simple
fix is to refresh the hotplug state just before deregistering the pci
hotplug slot.
There is also potential for a hotplug notification to fire too early
during setup, while the structures it uses are still being initialised.
(This could only happen if the BIOS performs hotplug itself; a bug
triggered by removing the battery while hibernated). Avoid this by
registering the notifier later. The same refresh mechanism is used
to handle rfkill state changes which can now race with registration.
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>
Commit d0265f0 "eeepc-laptop: fix hot-unplug on resume" used a workqueue
to protect pci hotplug against multiple simultaneous calls during
resume. It seems to work, but a mutex would be more appropriate.
This is in preparation to fix the potential pci hotplug race on unload.
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>
