Stop using ASUS_HANDLE because most of the time it is not needed.
This macro was introduced to display_get and lcd_switch which are not
part of the interface provided by Asus, and are scheduled for removal.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
The asus-laptop driver implements a number of interfaces like the
backlight class driver. This change makes it easier to examine the
implementation of one interface at at a time, without having to search
through the file to find init() and exit() functions etc.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
(Changelog stolen from Alan's patch for eeepc-laptop, but this patch
does the same thing for asus-laptop)
Callback methods should not refer to a variable like "asus" (formally
"hotk"). Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on. The "asus" variable can then be removed.
In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them. However this makes it harder to review them for
correctness. This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).
This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
asus-laptop now does a lot more than just hotkeys. Replace the "hotk"
names used throughout the driver with some slightly more appropriate
names. The actual strings used in kernel messages and sysfs are left
unchanged.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
We already tell the backlight class our maximum brightness value; it
will validate the user requested values for us.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
These to parameter allow to set the status of wlan and bluetooth
device when the module load. On some models, the device will
always be down on boot, so the default behavior is to always
enable these devices.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Before we mark the wireless device as unplugged, check PCI config space
to see whether the wireless device is really disabled (and vice versa).
This works around newer models which don't want the hotplug code, where
we end up disabling the wired network device.
My old 701 still works correctly with this. I can also simulate an
afflicted model by changing the hardcoded PCI bus/slot number in the
driver, and it seems to work nicely (although it is a bit noisy).
In future this type of hotplug support will be implemented by the PCI
core. The existing blacklist and the new warning message will be
removed at that point.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Clemens Ladisch reports that thinkpad-acpi improperly implements the
ALSA API, and always returns 0 for success for the "put" callbacks
while the API requires it to return "1" when the control value has
been changed in the hardware/firmware.
Rework the volume subdriver to be able to properly implement the ALSA
API. Based on a patch by Clemens Ladisch <clemens@ladisch.de>.
This fix is also needed on 2.6.33.
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.
Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.
This bug could be considered a local DoS I suppose, as it allows any
non-privledged local user to cause some versions of X.org to
hard-crash some ThinkPads.
Reported-by: Jidanni <jidanni@jidanni.org>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Studying the DSDTs of various thinkpads, it looks like bit 3 of the
argument to SBDC and SWAN is not "set radio to last state on resume".
Rather, it seems to be "if this bit is set, enable radio on resume,
otherwise disable it on resume".
So, the proper way to prepare the radios for S3 suspend is: disable
radio and clear bit 3 on the SBDC/SWAN call to to resume with radio
disabled, and enable radio and set bit 3 on the SBDC/SWAN call to
resume with the radio enabled.
Also, for persistent devices, the rfkill core does not restore state,
so we really need to get the firmware to do the right thing.
We don't sync the radio state on suspend, instead we trust the BIOS to
not do anything weird if we never touched the radio state since boot.
Time will tell if that's a wise way of doing things...
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Thadeu Lima de Souza Cascardo reports this:
Brightness notification does not work until the user writes to
hotkey_mask attribute. That's because the polling thread will only run
if hotkey_user_mask is set and someone is reading the input device or
if hotkey_driver_mask is set. In this second case, this condition is
not tested after the mask is changed, because the brightness and
volume drivers are started after the hotkey drivers.
Fix tpacpi_hotkey_driver_mask_set() to call hotkey_poll_setup(), so
that the poller kthread will be started when needed.
Reported-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Tested-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
The driver was not starting the NVRAM polling thread if the input
device was bound immediately after registration.
This fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=15118
Reported-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
We can stop pestering users for confirmation of the brightness_mode
default for firmware TP-76.
While at it, add a few missing comments in that quirk table.
Reported-by: Whoopie <whoopie79@gmx.net>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Event 0x3006 is used to help power management of the ODD in the
UltraBay. The EC generates this event when the ODD eject button is
pressed (even if the bay is powered down).
Normally, Linux doesn't need this as we keep the SATA link powered
up (which wastes power). The EC powers up the bay by itself when the
ODD eject button is pressed, and the SATA PHY reports the hotplug.
However, we could also power that SATA link down (and for that matter,
also power down the Ultrabay) if the ODD is left idle for a while with
no disk inside, and use event 0x3006 to know when we need that SATA link
powered back up.
For now, just stop asking for more information when event 0x3006 is
seen, there is no point in pestering users about it anymore.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Calling the ENAB method on Toshiba laptops results in notifications being
sent when laptop hotkeys are pressed. This patch simply calls that method
and sets up an input device if it's successful.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The Latitude C640 has another variation of dell in its DMI vendor entry.
Add it to the whitelist in order to enjoy the sweet fruits of software
backlight toggling.
Signed-off-by: Erik Andren <erik.andren@gmail.com>
Instead of a MODULE_DEVICE_TABLE for every acpi_driver ids table, we
create a table containing all ids to export to get a module alias for
each one.
This will fix automatic loading of the driver when one of the ACPI
devices is not present (like the accelerometer, which is not present in
some models).
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Right now, we assume that the hardware rfkill switch on Dells toggles all
radio devices. In fact, this can be configured in the BIOS and so right
now we may mark a device as hardware killed even when it isn't. Add code
to query the devices controlled by the switch, and use this when
determining the hardware kill state of a radio.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Calls to communicate with system firmware via a SMI (using dcdbas)
need to use a buffer that has a physical address of 4GB or less.
Currently the dell-laptop driver does not guarantee this, and when the
buffer address is higher than 4GB, the address is truncated to 32 bits
and the SMI handler writes to the wrong memory address.
Signed-off-by: Stuart Hayes <stuart_hayes@dell.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
The Mini family doesn't support smbios 17,11 although it reports it does.
Signed-off-by: Mario Limonciello <superm1@ubuntu.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The "hardware" switch is tied directly to a BIOS interface that will
connect and disconnect the hardware from the bus.
If you use the software interface to request the BIOS to make these
changes, the HW switch will be in an inconsistent state and LEDs may not
reflect the state of the HW.
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
dell-laptop currently fails to clean up its platform device correctly.
Make sure that it's unregistered.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
The rfkill interface on Dells only sends a notification that the switch
has been changed via the keyboard controller. Add a filter so we can
pick these notifications up and update the rfkill state appropriately.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
This drops the support for manually groking the files in sysfs
to turn on and off the WLAN and BT for Compal laptops in favor
of platform rfkill support.
It has been combined into a single patch to not introduce regressions
in the process of simply adding rfkill support
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
The following Dell laptops are known to have been manufacturer by Compal
and are supported by the compal-laptop platform driver
- Mini 9
- Mini 10
- Mini 12
- Mini 10v
- Inspiron 11z
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
Set the backlight to use the current brightness when loaded, rather than
always resetting the backlight to maximum brightness.
Fixes kernel bugzilla #14207
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Reported-by: Denis Mukhin <denis_mukhin@yahoo.com>
Signed-off-by: Len Brown <len.brown@intel.com>
sysfs_remove_group() removed the wrong attribute_group for
thermal_read_mode TPEC_8, ACPI_TMP07 and ACPI_UPDT
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
CC [M] drivers/platform/x86/sony-laptop.o
drivers/platform/x86/sony-laptop.c: In function 'sony_nc_rfkill_setup':
drivers/platform/x86/sony-laptop.c:1162: warning: 'i' may be used uninitialized in this function
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Acked-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>
Some new models need to disable wireless hotplug.
For the moment, we don't know excactly what models need that,
except 1005HA.
Users will be able to use that param as a workaround.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
This is a short term workaround for Eeepc 1005HA.
refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
The EeePC 4G ("701") implements CFVS, but it is not supported by the
pre-installed OS, and the original option to change it in the BIOS
setup screen was removed in later versions. Judging by the lack of
"Super Hybrid Engine" on Asus product pages, this applies to all "701"
models (4G/4G Surf/2G Surf).
So Asus made a deliberate decision not to support it on this model.
We have several reports that using it can cause the system to hang [1].
That said, it does not happen all the time. Some users do not
experience it at all (and apparently wish to continue "right-clocking").
Check for the EeePC 701 using DMI. If met, then disable writes to the
"cpufv" sysfs attribute and log an explanatory message.
Add a "cpufv_disabled" attribute which allow users to override this
policy. Writing to this attribute will log a second message.
The sysfs attribute is more useful than a module option, because it
makes it easier for userspace scripts to provide consistent behaviour
(according to user configuration), regardless of whether the kernel
includes this change.
[1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578>
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>
