aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/dell-laptop.c
Commit message (Collapse)AuthorAge
* backlight: add backlight typeMatthew Garrett2011-03-22
| | | | | | | | | | | | | | | | | | | 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>
* dell-laptop: Toggle the unsupported hardware killswitchKeng-Yu Lin2011-02-21
| | | | | | | | | | | | 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>
* backlight: constify backlight_opsLionel Debroux2010-11-16
| | | | | | | | | | | | backlight_device_register has been expecting a const "ops" argument, and using it as such, since 9905a43b2d563e6f89e4c63c4278ada03f2ebb14. 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>
* dell-laptop: Add debugfs supportKeng-Yu Lin2010-10-21
| | | | | | | | | | 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>
* platform/x86: move rfkill for Dell Mini 1012 to compal-laptopVictor van den Elzen2010-08-16
| | | | | | | | | 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>
* dell-laptop: make dell_laptop_i8042_filter() staticAxel Lin2010-08-03
| | | | | | | 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>
* dell-laptop: Add another Dell laptop family to the DMI whitelistRezwanul Kabir2010-08-03
| | | | | | | 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>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* backlight: Allow properties to be passed at registrationMatthew Garrett2010-03-16
| | | | | | | | | | 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>
* dell-laptop: Fix errors on failure and exit pathsMatthew Garrett2010-03-01
| | | | | | | | 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>
* dell-laptop: Fix build error by making buffer_mutex staticIngo Molnar2010-03-01
| | | | | | | | | | | | | | | 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>
* dell-laptop: Add another Dell laptop to the DMI whitelistErik Andren2010-02-25
| | | | | | | | 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>
* dell-laptop: Pay attention to which devices the hardware switch controlsMatthew Garrett2010-02-25
| | | | | | | | | | 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>
* dell-laptop: Use buffer with 32-bit physical addressStuart Hayes2010-02-25
| | | | | | | | | | | 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>
* dell-laptop: Blacklist machines not supporting dell-laptopMario Limonciello2010-02-25
| | | | | | | 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>
* dell-laptop: Block software state changes when rfkill hard blockedMario Limonciello2010-02-25
| | | | | | | | | | | 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: Fix small memory leakMatthew Garrett2010-02-25
| | | | | | da_tokens was not being freed by dell-laptop on unload. Fix that. Signed-off-by: Matthew Garrett <mjg@redhat.com>
* dell-laptop: Fix platform device unregistrationMatthew Garrett2010-02-25
| | | | | | | 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>
* dell-laptop: Update rfkill state on kill switchMatthew Garrett2010-02-25
| | | | | | | | 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>
* dell-laptop: add __init to init functionsAlan Jenkins2009-12-10
| | | | | | 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>
* dell-laptop: create a platform device as a parent for the rfkill devices etc.Alan Jenkins2009-12-10
| | | | | | | | | | | | | | 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>
* dell-laptop: fix rfkill memory leak on unload and failure pathsAlan Jenkins2009-12-10
| | | | | | | | 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>
* dell-laptop: fix a use-after-free error on the failure pathAlan Jenkins2009-12-09
| | | | | | | | | | 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>
* dell-laptop: Fix rfkill state queriesMatthew Garrett2009-12-09
| | | | | | | | | 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>
* dell-laptop: fix rfkill conversionJohannes Berg2009-06-15
| | | | | | | | | 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>
* rfkill: rewriteJohannes Berg2009-06-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* dmi: Let dmi_walk() users pass private dataJean Delvare2009-03-30
| | | | | | | | | | | 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>
* dell-laptop: move to drivers/platform/x86/ from drivers/misc/Len Brown2009-01-16
Signed-off-by: Len Brown <len.brown@intel.com>