Commit graph

28 commits

Author SHA1 Message Date
Matthew Garrett
bb7ca747f8 backlight: add backlight type
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: Matthew 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 17:43:59 -07:00
Keng-Yu Lin
a3d77411e8 dell-laptop: Toggle the unsupported hardware killswitch
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: Keng-Yu Lin <keng-yu.lin@canonical.com>
Tested-by: Alessio Igor Bogani <abogani@texware.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-02-21 17:06:21 -05:00
Lionel Debroux
acc2472ed3 backlight: constify backlight_ops
backlight_device_register has been expecting a const "ops" argument, and using
it as such, since 9905a43b2d. Let's make the
remaining backlight_ops instances const.

Inspired by hunks of the grsecurity patch, updated for newer kernels.

Signed-off-by: Lionel Debroux <lionel_debroux@yahoo.fr>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-11-16 14:14:02 +01:00
Keng-Yu Lin
037accfa14 dell-laptop: Add debugfs support
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: Keng-Yu Lin <keng-yu.lin@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-10-21 09:36:49 -04:00
Victor van den Elzen
c3f755e384 platform/x86: move rfkill for Dell Mini 1012 to compal-laptop
Like others in the Mini series, the Dell Mini 1012 does not support
the smbios hook required by dell-laptop.

Signed-off-by: Victor van den Elzen <victor.vde@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-08-16 11:55:00 -04:00
Axel Lin
4519169b8f dell-laptop: make dell_laptop_i8042_filter() static
Make dell_laptop_i8042_filter() static as it's used only in dell-laptop.c

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-08-03 09:49:11 -04:00
Rezwanul Kabir
410d44c74c dell-laptop: Add another Dell laptop family to the DMI whitelist
This is to support Precision M4500 and others.

Signed-off-by: Rezwanul Kabir <Rezwanul_Kabir@dell.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-08-03 09:48:49 -04:00
Tejun Heo
5a0e3ad6af 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: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
Matthew Garrett
a19a6ee6ca backlight: Allow properties to be passed at registration
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: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-16 19:47:54 +00:00
Matthew Garrett
92e00e47b6 dell-laptop: Fix errors on failure and exit paths
Make sure that work is cancelled after removing the i8042 filter, and
unregister the platform device rather than deleting it.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2010-03-01 09:46:43 -05:00
Ingo Molnar
94d8f785dd dell-laptop: Fix build error by making buffer_mutex static
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:

  116ee77: 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: Ingo Molnar <mingo@elte.hu>
2010-03-01 09:43:52 -05:00
Erik Andren
cb6a7937f4 dell-laptop: Add another Dell laptop to the DMI whitelist
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>
2010-02-25 11:50:53 -05:00
Matthew Garrett
c6760ac426 dell-laptop: Pay attention to which devices the hardware switch controls
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>
2010-02-25 11:50:50 -05:00
Stuart Hayes
116ee77b28 dell-laptop: Use buffer with 32-bit physical address
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>
2010-02-25 11:50:49 -05:00
Mario Limonciello
e5fefd0c8c dell-laptop: Blacklist machines not supporting dell-laptop
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>
2010-02-25 11:50:48 -05:00
Mario Limonciello
ec1722a214 dell-laptop: Block software state changes when rfkill hard blocked
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>
2010-02-25 11:50:46 -05:00
Matthew Garrett
e551260b23 dell-laptop: Fix small memory leak
da_tokens was not being freed by dell-laptop on unload. Fix that.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-02-25 11:50:44 -05:00
Matthew Garrett
facd61d7b7 dell-laptop: Fix platform device unregistration
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>
2010-02-25 11:50:43 -05:00
Matthew Garrett
814cb8adbe dell-laptop: Update rfkill state on kill switch
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>
2010-02-25 11:50:42 -05:00
Alan Jenkins
4788df4cf4 dell-laptop: add __init to init functions
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-10 00:02:31 -05:00
Alan Jenkins
ada3248a5d dell-laptop: create a platform device as a parent for the rfkill devices etc.
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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-10 00:01:47 -05:00
Alan Jenkins
4311bb230e dell-laptop: fix rfkill memory leak on unload and failure paths
rfkill_unregister() should always be followed by rfkill_destroy().

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-10 00:01:03 -05:00
Alan Jenkins
71e9dc73cb dell-laptop: fix a use-after-free error on the failure path
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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 23:59:19 -05:00
Matthew Garrett
e1fbf346c7 dell-laptop: Fix rfkill state queries
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: Matthew Garrett <mjg@redhat.com>
Tested-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 23:56:40 -05:00
Johannes Berg
624f0de44a dell-laptop: fix rfkill conversion
A polarity error snuck into the rfkill rewrite's dell-laptop
conversion, fix it.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-15 15:05:58 -04:00
Johannes Berg
19d337dff9 rfkill: rewrite
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: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03 14:06:13 -04:00
Jean Delvare
e7a19c5624 dmi: Let dmi_walk() users pass private data
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: Jean Delvare <khali@linux-fr.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Roland Dreier <rolandd@cisco.com>
2009-03-30 21:46:44 +02:00
Len Brown
cad73120ab dell-laptop: move to drivers/platform/x86/ from drivers/misc/
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-16 14:32:18 -05:00
Renamed from drivers/misc/dell-laptop.c (Browse further)