This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.

This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of sequential call of functions
alloc_page() and page_address().
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NMichal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This commit show additional information about rfkill state in debugfs based
on newly released documentation by Dell.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Make sure that all existing SMBIOS calls for wireless control are properly
documented. This commit also add new documentation released by Dell.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Until now module dell-laptop registered rfkill device which used i8042
filter function for receiving HW switch rfkill events (handling special
keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hooks).

So this patch will combine best from both sides. It will use native ACPI
driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
enabling or disabling radio devices. If ACPI driver or device will not be
available fallback to i8042 filter function will be used.

Patch also changes module_init() to late_initcall() to ensure that init
function will be called after initializing dell-rbtn.c driver.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This patch adds the support for the configuration of the keyboard
backlight on supported Dell laptops.

With this patch it is possible to set:
* keyboard backlight level
* timeout after which the backlight will be automatically turned off
* input activity triggers (keyboard, touchpad, mouse) that enable the backlight
* ambient light settings

The settings are exposed via /sys/class/leds/dell::kbd_backlight/

The code is based on the newly released documentation by Dell in the
libsmbios project.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This reverts commit 02b2aaaa.

This interface was determined to be flawed and required too invasive a
fix for the RC cycle. This will be revisited in 3.20.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This patch adds support for configuring keyboard backlight settings on supported
Dell laptops. It exports kernel leds interface and uses Dell SMBIOS tokens or
keyboard class interface.

With this patch it is possible to set:
* keyboard backlight level
* timeout after which will be backlight automatically turned off
* input activity triggers (keyboard, touchpad, mouse) which enable backlight
* ambient light settings

Settings are exported via sysfs:
/sys/class/leds/dell::kbd_backlight/

Code is based on newly released documentation by Dell in libsmbios project.

Thanks to Dan Carpenter who reported bug about unpredictable results in
quirks->kbd_timeouts for loop. His fix adds needs_kbd_timeouts flag to
quirk structure to indicate if kbd_timeouts array is empty or not.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Minor English corrections to comments.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Instead of using a magic constant 0x20 in some drivers to get data only
from the KBC port we should use the constant defined in i8042.h with
the same value. Also, this makes these drivers uniform with what
constant the only other filter function uses in
drivers/input/misc/ideapad_slidebar.c.
Signed-off-by: NGiedrius Statkevičius <giedriuswork@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The dell_quirks[] DMI table is only ever used during initialization.
Mark it as __initconst so its memory can be released afterwards --
roughly 5.7 kB. In turn, the callback function can be marked with
__init, too.

Also the touchpad_led_init() function can be marked __init as it's only
referenced from dell_init() -- an __init function.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Installing the i8042 filter is not useful on machines where rfkill is not
whitelisted, so move the filter installation into dell_setup_rfkill,
after the whitelist check.

This avoids doing a needless and potentially troublesome rfkill query
(dell_send_request(buf, 17, 11)) when the wireless Fn key gets pressed on
non whitelisted laptops.

This patch was written as a result of:
https://bugzilla.redhat.com/show_bug.cgi?id=1045807
It is not yet clear if this is related, but it is a good idea to not register
the i8042 filter in general.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Given that Precision mobile workstations are top of the line Dell products,
I expect the functionality of rfkill there to be as reliable as on Latitudes
so whitelist Precisions.

https://bugzilla.kernel.org/show_bug.cgi?id=65731Reported-by: NCalum Lind <calumlind@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Fix to return error code instead always return 0 from function
dell_send_intensity().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

All my testing has been on laptops with a hw killswitch, so to be on the
safe side disable rfkill functionality on models without a hw killswitch for
now. Once we gather some feedback on laptops without a hw killswitch this
decision maybe reconsidered.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Setting force_rfkill will cause the dell-laptop rfkill code to skip its
whitelist checks, this will allow individual users to override the whitelist,
as well as to gather info from users to improve the checks.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Some time is needed for the BIOS to do its work, but 250ms should be plenty.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Instead when hw-blocked always write 1 to the blocked bit for the radio in
question. This is necessary to properly set all the blocked bits for hw-switch
controlled radios to 1 after power-on and resume.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

This is necessary for 3 reasons:
1) To apply sw_state changes made while hw-blocked
2) To set all the blocked bits for hw-switch controlled radios to 1 when the
   switch gets changed to off, this is necessary on some models to actually
   turn the radio status LEDs off.
3) On some models non hw-switch controlled radios will have their block bit
   cleared (potentially undoing a soft-block) on hw-switch toggle, this
   restores the sw-block in this case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

This makes dell-laptop's rfkill code consistent with other drivers which
allow sw_state changes while hw blocked.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

On machines with a hardware switch, the blocking settings can not be changed
through a Fn + wireless-key combo, so there is no reason to read back the
blocking state from the BIOS.

Reading back is not only not necessary it is actually harmful, since on some
machines the blocking state will be cleared to all 0 after a wireless switch
toggle, even for radios not controlled by the hw-switch (yeah firmware bugs).

This causes "magic" changes to the sw_state. This is inconsistent with other
rfkill drivers which preserve the sw_state over a hw kill on / off.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

The query callback should only update the hw_state, see the comment in
net/rfkill/core.c in rfkill_set_block, which is its only caller.

rfkill_set_block will modify the sw_state directly after calling query so
calling set_sw_state is an expensive NOP.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

To ensure we don't enter any hw-switch related code paths on machines without
a hw-switch.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

The rfkill functionality was removed from the dell-laptop driver because it
was causing problems on various non Latitude models, and the blacklist kept
growing and growing. In the thread discussing this Dell mentioned that they
only QA the rfkill acpi interface on Latitudes and indeed there have been
no blacklist entries for Latitudes.

Note that the blacklist contained no Vostros either, and most Vostros have
a hardware switch too, so we could consider supporting Vostros with a
hardware switch too.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Without rfkill functionality in dell-laptop I have the following problems:
-If the hardware radio switch is set to disable the radio, then userspace
 will still think it can use wireless and bluetooth.
-The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill
 functionality

I know the rfkill functionality was removed from the dell-laptop driver because
it caused more problems then it fixed, and the blacklist for it was growing out
of control.

But in the thread discussing this Dell mentioned that they only QA the rfkill
acpi interface on Latitudes and indeed there have been no blacklist entries
for Latitudes. Therefor I would like to bring the rfkill functionality back
only for Latitudes. This patch is a straight-forward revert. The next patch
in this set will drop the blacklist and replace it with a Latitude check.

This reverts commit a6c2390c.

Conflicts:
	drivers/platform/x86/dell-laptop.c
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Fix to return -ENOMEM in the alloc_page() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

If krealloc() returns NULL, it *doesn't* free the original. So any code
of the form 'foo = krealloc(foo, …);' is almost certainly a bug.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

If krealloc() returns NULL, it *doesn't* free the original. So any code
of the form 'foo = krealloc(foo, …);' is almost certainly a bug.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Joey Lee <jlee@novell.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Peter Feuerer <peter@piie.net>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
Cc: Robert Gerlach <khnz@gmx.de>
Cc: Ike Panhc <ike.pan@canonical.com>
Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed the typo introduced from the below commit
5f1e88f4 dell-laptop: Add 6 machines to touchpad led quirk
Reported-by: NCarlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add the following machines into quirk,
Isnpiron 5420, Isnpiron 5520, Isnpiron 5720,
Isnpiron 7420, Isnpiron 7520, Isnpiron 7720
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The interface just doesn't work on some machines, and Dell haven't been
able to tell us either which machines those are or what we should be
doing instead. This would be fine, except it results in userspace ending
up confused and general sadness. So let's just rip it out for now.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add Dell Vostro 3450 quirk to support touchpad LED.

CC: Mariusz Fik <fisiu@opensuse.org>
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with

	error: $variablename causes a section type conflict

because a section containing const variables is marked read only and so
cannot contain non-const variables.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
Cc: platform-driver-x86@vger.kernel.org
Cc: ibm-acpi-devel@lists.sourceforge.net
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add "Vostro 3360", "Vostro 3460", and "Vostro 3560" into quirks,
so that they could have touchpad LED function work.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add Vostro 3350 into quirks so that the touchpad LED works.
Signed-off-by: NAng Way Chuang <wcang79@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add missing DMI_NONE entry to end of the quirks list so
dmi_check_system() won't read past the end of the list.
Signed-off-by: NMartin Nyhus <martin.nyhus@gmx.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Touchpad LED will not turn on after S3, it will make the touchpad status
doesn't consist with the LED.
By adding one flag to let the LED device restore it's status.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks,
so that they could have touchpad LED function work.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>