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>

Use MODULE_DEVCE_TABLE instead of rolling MODULE_ALIAS by hand.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NMarcos Paulo de Souza <marcos.mage@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Fix build warnings:
  drivers/platform/x86/dell-laptop.c:592:13: warning: function declaration isn't a prototype
  drivers/platform/x86/dell-laptop.c:599:13: warning: function declaration isn't a prototype
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch supports Dell laptop with Synaptics and Alps touchpad chip
that with LED to indicate the functionality of touchpad is disabled or
enabled.

The command for touchpad LED is 0x97, and the data 1 means turn on the
touchpad LED, 2 means turn it off.

BTW, I add dell_quirks to white list those machines that supports this
behavior, so that the code won't affect those who don't have a touchpad LED
machine.

We can easily to turn it on/off by
   echo 1 > /sys/class/leds/dell-laptop::touchpad/brightness
   echo 0 > /sys/class/leds/dell-laptop::touchpad/brightness
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

DEFINE_MUTEX() will automatically initialize buffer_mutex,
no need to call mutex_init() in dell_init().
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Using buffer->output[1] without mutex_lock()
Signed-off-by: NJose Alonso <joalonsof@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This reverts commit a3d77411,

as it causes a mess in the wireless rfkill status on some models.
It is probably a bad idea to toggle the rfkill for all dell models
without the respect to the claim that it is hardware-controlled.

Cc: stable@kernel.org
Signed-off-by: NKeng-Yu Lin <kengyu@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add pr_fmt.
Remove hard coded prefixes and use pr_<level>.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

There may be multiple ways of controlling the backlight on a given
machine.  Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is found on Dell Inspiron 1018 that the firmware reports that the hardware
killswitch is not supported. This makes the rfkill key not functional.

This patch forces the driver to toggle the firmware rfkill status in the case
that the hardware killswitch is indicated as unsupported by the firmware.
Signed-off-by: NKeng-Yu Lin <keng-yu.lin@canonical.com>
Tested-by: NAlessio Igor Bogani <abogani@texware.it>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

backlight_device_register has been expecting a const "ops" argument, and using
it as such, since 9905a43b. Let's make the
remaining backlight_ops instances const.

Inspired by hunks of the grsecurity patch, updated for newer kernels.
Signed-off-by: NLionel Debroux <lionel_debroux@yahoo.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Export the status of RF killswitch through debugfs.

The killswitch status is obtained by the SMI to BIOS. Exporting this status
through debugfs can help identify the issue with the misbehaving firmware.
Signed-off-by: NKeng-Yu Lin <keng-yu.lin@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Like others in the Mini series, the Dell Mini 1012 does not support
the smbios hook required by dell-laptop.
Signed-off-by: NVictor van den Elzen <victor.vde@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Make dell_laptop_i8042_filter() static as it's used only in dell-laptop.c
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This is to support Precision M4500 and others.
Signed-off-by: NRezwanul Kabir <Rezwanul_Kabir@dell.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Values such as max_brightness should be set before backlights are
registered, but the current API doesn't allow that. Add a parameter to
backlight_device_register and update drivers to ensure that they
set this correctly.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Make sure that work is cancelled after removing the i8042 filter, and
unregister the platform device rather than deleting it.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The following build bug (x86, allyesconfig):

  arch/x86/oprofile/built-in.o:(.data+0x250): multiple definition of `buffer_mutex'

Was triggered in -tip testing, caused by this upstream commit:

  116ee77b: dell-laptop: Use buffer with 32-bit physical address

There's multiple buffer_mutex's in the kernel. Make this new one
static.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

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: NErik Andren <erik.andren@gmail.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: NMatthew 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: NStuart Hayes <stuart_hayes@dell.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>

The Mini family doesn't support smbios 17,11 although it reports it does.
Signed-off-by: NMario Limonciello <superm1@ubuntu.com>
Signed-off-by: NTim 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: NMario Limonciello <Mario_Limonciello@Dell.com>

da_tokens was not being freed by dell-laptop on unload. Fix that.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

dell-laptop currently fails to clean up its platform device correctly.
Make sure that it's unregistered.
Signed-off-by: NMatthew 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: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

dell-laptop may not need to export any sysfs files, but it should still
create a platform device as a parent for the rfkill and backlight
devices.  Otherwise sysfs will display these as "virtual" devices,
with no connection to either physical hardware or the dell-laptop
module.

Apparently this is useful for hardware detection.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NMatthew Garrett <mjg@redhat.com>
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>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

dell_setup_rfkill() already cleans up the rfkill devices on failure.
So if it returns an error, we should not try to unregister the rfkill
devices.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The current code in dell-laptop is confused about the hardware rfkill
state. Fix it up such that it's always reported correctly.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Tested-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

A polarity error snuck into the rfkill rewrite's dell-laptop
conversion, fix it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

At the moment, dmi_walk() lacks flexibility, users can't pass data to
the callback function. Add a pointer for private data to make this
function more flexible.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Roland Dreier <rolandd@cisco.com>

Signed-off-by: NLen Brown <len.brown@intel.com>