aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/eeepc-laptop.c
Commit message (Collapse)AuthorAgeFilesLines
* platform-x86: sync eeepc-laptop and asus-laptopCorentin Chary2010-10-211-7/+9
| | | | | | | | Makes asus-laptop and eeepc-laptop _init/_exit functions looks exactly the same as they do the same thing. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* eeepc-laptop: fix hotplug_disabled module_param permissionsAxel Lin2010-08-031-1/+1
| | | | | | | | | | | | | The hotplug_disabled module parameter is determinated at the module load time. Change the value after the module is loaded does not make sense and has no effect at all, thus set the permissions to 0444 instead of 0644. Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Matthew Garrett <mjg@redhat.com> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* eeepc-laptop: add missing sparse_keymap_freeCorentin Chary2010-04-231-2/+1
| | | | | | | Also remove legacy keymap which was not used since we use sparse_keymap. Signed-off-by: Corentin Chary <corentincj@iksaif.net>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-3/+5
| | | | | | | | | | 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>
* eeepc-laptop: check wireless hotplug eventsAlan Jenkins2010-02-281-0/+18
| | | | | | | | | | | | | | | | | | 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>
* eeepc-laptop: disable wireless hotplug for 1005PEAlan Jenkins2010-02-281-1/+2
| | | | | | | | | | | The wireless hotplug code is not needed on this model, and it disables the wired ethernet card. (Like on the 1005HA and 1201N). References: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/003281.html> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reported-by: Ansgar Burchardt <ansgar@43-1.org> CC: stable@kernel.org
* eeepc-laptop: disable wireless hotplug for 1201NCorentin Chary2010-01-161-1/+1
| | | | | Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
* eeepc-laptop: add hotplug_disable parameterCorentin Chary2010-01-161-0/+10
| | | | | | | | | | 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>
* eeepc-laptop: switch to using sparse keymap libraryDmitry Torokhov2010-01-161-135/+51
| | | | | | | Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
* eeepc-laptop: dmi blacklist to disable pci hotplug codeCorentin Chary2010-01-161-5/+20
| | | | | | | | | 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>
* eeepc-laptop: disable cpu speed control on EeePC 701Alan Jenkins2010-01-161-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'asus' into releaseLen Brown2009-12-151-629/+786
|\ | | | | | | | | | | | | | | Conflicts: Documentation/feature-removal-schedule.txt drivers/platform/x86/eeepc-laptop.c Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: re-add check for eeepc->backlight == NULLAlan Jenkins2009-12-091-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | As Corentin points out, we do not create a backlight device if the ACPI video driver is able to provide equivalent functionality. So we do need to check before we try to update the backlight device. We now ignore brightness events completely if we have not created a backlight device. This is slightly more cautious than the original check. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: fix coding styleCorentin Chary2009-12-091-3/+5
| | | | | | | | | | | | | | | | fix styles problems introduced by commit e86bda235a08b6a8e64c1e8bb9d175f6961554e3 Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: map keys found on newer eeepcCorentin Chary2009-12-091-0/+3
| | | | | | | | | | Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: callbacks should use "driver data" parameter or fieldAlan Jenkins2009-12-091-198/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callback methods should not refer to a variable like "eeepc" (formally "ehotk"). 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 "eeepc" 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 :-). The hwmon sub-device is a special case. It uses ec_{read,write} which are defined to communicate with the (first) EC, so it does not require any driver data. It should still only be instantiated in the context of an ASUS010 device because we don't have a safe way to probe for it. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: revise namesAlan Jenkins2009-12-091-128/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eeepc-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. e.g. EEEPC_HOTK_FILE -> EEEPC_LAPTOP_FILE EEEPC_HOTK_HID -> EEEPC_ACPI_HID eeepc_hotk_notify -> eeepc_acpi_notify struct eeepc_hotk -> struct eeepc_laptop ehotk -> eeepc I'm about to refactor the entire driver to remove the global "ehotk" variable, and I don't wish to add "struct eeepc_hotk *ehotk" to functions which have nothing to do with hotkeys. Also - fix the name of "eepc_get_entry_by_keycode()" - remove the unused definition of NOTIFY_WLAN_ON. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: code movementAlan Jenkins2009-12-091-472/+462
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move e.g. backlight_init() and backlight_exit() together along with the other backlight functions, instead of grouping init() and exit() functions. Move e.g. backlight_ops to follow the functions it refers to, and remove the forward declarations. The code itself should remain unchanged. The eeepc-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: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: move platform device initialisation to a separate functionAlan Jenkins2009-12-091-25/+39
| | | | | | | | | | | | | | | | | | | | | | This moves the sysfs_create_group() call just after the declaration of the platform device attributes. It should make it easier to examine the implementation of the platform device attributes in isolation from the rest of the code. (The next commit will apply this pattern to all of the sub-devices as well). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: move platform driver registration out of eeepc_hotk_add()Alan Jenkins2009-12-091-10/+15
| | | | | | | | | | | | | | | | Strictly speaking we should register the platform driver exactly once, whether there are zero, one, or multiple matching acpi devices. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: refactor notificationsAlan Jenkins2009-12-091-32/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Separate out input_notify(), in a similar way to how notify_brn() is already separated. This will allow all the functions which refer to the input device to be grouped together. This includes a small behaviour change - we now synthesize brightness up/down key events even if the brightness is already at the maximum/minimum value. This is consistent with the new uevent interface. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: simplify how the hwmon device reads values from the ECAlan Jenkins2009-12-091-22/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The hwmon device uses ec_write() to write values to the EC. So for consistency it should use ec_read() to read values. The extra layers of indirection used did not add any value. This may mean we no longer take the ACPI global lock for such reads (if the EC operation region requires the lock and the EC does not). But there is no point locking each one-byte read individually, when write operations do not use the lock at all. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: simplify acpi initializationAlan Jenkins2009-12-091-29/+26
| | | | | | | | | | | | | | | | We don't need to store init_flags after using them. And we don't use the result of INIT, so we don't need to allocate a buffer for it. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: no need to check argument of set_brightness()Alan Jenkins2009-12-091-1/+0
| | | | | | | | | | | | | | | | We already tell the backlight class our maximum brightness value; it will validate the user requested values for us. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: remove redundant NULL checksAlan Jenkins2009-12-091-23/+19
| | | | | | | | | | | | | | | | | | eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL. We check both variables for allocation failure and would bail out before the notifier is registered. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: fix set_acpi() to return non-zero on failureAlan Jenkins2009-12-091-15/+19
| | | | | | | | | | | | | | | | If the control method does not exist, return -ENODEV for consistency with get_acpi() Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: fix potential leak (led_init() failure)Alan Jenkins2009-12-091-1/+3
| | | | | | | | | | | | | | | | If we bail out because we can't create the led class device, we need to ensure the led workqueue is cleaned up. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: fix led initialization orderAlan Jenkins2009-12-091-6/+6
| | | | | | | | | | | | | | | | Create the workqueue thread used by tpd_led_set() *before* we register the led device. (And vice versa for unregistration). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: fix value of pwm1_enable to match documentationAlan Jenkins2009-12-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation/hwmon/sysfs-interface tells us that automatic fan speed control should be represented by a value of 2 or above for pwm1_enable. Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control. Setting "1" for manual control is already consistent with the documentation, so this remains unchanged. Let's preserve the ABI for this specific driver, so that writing "0" will still invoke automatic control. (The documentation says setting "0" should leave the fan at full speed all the time. This mode is not directly supported by our hardware. Full speed is rather noisy on my 701 and the automatic control has never used it. If you really want this e.g. to prolong the life of an EeePC used as a server, you can always use manual mode. hwmon has always been fairly machine-specific, and you're in a tiny minority (or elite :-). I'm sure you're smart enough to notice that the fan doesn't turn on to full speed when you try this mode, either by ear or checking fan_input1. We could even claim to be honouring the spirit of the documentation. "0" really means "safe mode". EeePCs default to automatic mode, ie that is what Asus will actually test. Since we do not provide any way to tamper with the temperature threshold, automatic mode _is_ the safe option). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: set acpi_driver.ownerAlan Jenkins2009-12-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The owner field provides the link between drivers and modules in sysfs, but no ACPI driver was setting it. After setting the owner field, we can see which module provides which driver and vice versa by looking at /sys/bus/acpi/driver/*/module and /sys/module/*/drivers/acpi:*. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: Remove uneccesary acpi_disabled checkAlan Jenkins2009-12-091-2/+0
| | | | | | | | | | | | | | | | acpi_bus_register_driver() already checks acpi_disabled, so acpi bus drivers don't need to. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: Remove redundant NULL checksAlan Jenkins2009-12-091-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The acpi device callbacks add, start, remove, suspend and resume can never be called with a NULL acpi_device. Each callsite in acpi/scan.c has to dereference the device in order to get the ops structure, e.g. struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; if (acpi_drv && acpi_drv->ops.suspend) return acpi_drv->ops.suspend(acpi_dev, state); Remove all checks for acpi_dev == NULL within these callbacks. Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of these checks could fail unless the driver does something strange (which none of them do), the acpi core did something terribly wrong, or we have a memory corruption issue. If this does happen then it's best to dereference the pointer and crash noisily. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: add touchpad ledCorentin Chary2009-12-091-0/+67
| | | | | | | | | | | | | | This led can be found on Eeepc 1005 series. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * eeepc-laptop: disp attribute should be write-onlyAlan Jenkins2009-12-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, reading from the disp attribute fails with "No such device", which is misleading. According to CMSG table on acpi4asus project site, no models have a getter method corresponding to SDSP. Change the file permission to disallow reads. If some joker changes the permission to permit reads, then return -EIO to be consistent with sysfs' behaviour when no show() method is provided. 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>
* | const: constify remaining dev_pm_opsAlexey Dobriyan2009-12-151-1/+1
|/ | | | | | Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* eeepc-laptop: don't enable camera at startup if it's already on.Luca Niccoli2009-11-031-1/+2
| | | | | | | | | | | | | | Switching the camera takes 500ms, checking if it's on is almost free... The BIOS remembers the setting through reboots, so there's good chance the camera is already enabled. Signed-off-by: Luca Niccoli <lultimouomo@gmail.com> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
* Revert "eeepc-laptop: Prevent a panic when disabling RT2860 wireless when ↵Corentin Chary2009-11-031-19/+8
| | | | | | | | | | | | | | associated" rt2860sta is fine with the patch as is, but iwl3945 isn't (eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means that we're back to causing the rt2860sta panic This reverts commit b56ab33d68638e6aafdbfc694025e8354a628f49. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
* eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associatedDarren Salt2009-10-131-8/+19
| | | | | | | | | | | | | | | | This works around what I think is actually a bug in rt2860sta which is triggered when the hardware "disappears" from beneath the driver, i.e. when wireless is toggled off via ACPI. It does so by ensuring that the rfkill soft-block flag is set before the hardware is disabled. I do not know whether this patch is required if rt2800pci is in use instead of rt2860sta; at the time of submission of this patch, I've not been able to test this. (Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390) Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
* eeepc-laptop: Properly annote eeepc_enable_camera().Rakib Mullick2009-10-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Currently the annotation for function eeepc_enable_camera() is __init, and refers to a function eeepc_hotk_add() which is non-init. Use __devinit for both functions which is more appropriate and fixes a section mismatch warning. We were warned by the following warning: LD drivers/platform/x86/built-in.o WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section mismatch in reference from the function eeepc_hotk_add() to the function .init.text:eeepc_enable_camera() The function eeepc_hotk_add() references the function __init eeepc_enable_camera(). This is often because eeepc_hotk_add lacks a __init annotation or the annotation of eeepc_enable_camera is wrong. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlightLinus Torvalds2009-09-261-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight: backlight: new driver for ADP5520/ADP5501 MFD PMICs backlight: extend event support to also support poll() backlight/eeepc-laptop: Update the backlight state when we change brightness backlight/acpi: Update the backlight state when we change brightness backlight: Allow drivers to update the core, and generate events on changes backlight: switch to da903x driver to dev_pm_ops backlight: Add support for the Avionic Design Xanthos backlight device. backlight: spi driver for LMS283GF05 LCD backlight: move hp680-bl's probe function to .devinit.text backlight: Add support for new Apple machines. backlight: mbp_nvidia_bl: add support for MacBookAir 1,1 backlight: Add WM831x backlight driver Trivial conflicts due to '#ifdef CONFIG_PM' differences in drivers/video/backlight/da903x_bl.c
| * backlight/eeepc-laptop: Update the backlight state when we change brightnessMatthew Garrett2009-09-211-1/+1
| | | | | | | | | | | | | | | | Trigger a status update when the user hits a brightness key, allowing userspace to present appropriate UI. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* | eeepc-laptop: allow rfkill hotplug to work on the 900A modelAlan Jenkins2009-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | The 900A provides hotplug notifications on a different ACPI object to other models. Reported-by: Trevor <trevor.chart@gmail.com> 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>
* | eeepc-laptop: fix rfkill memory leak on unloadAlan Jenkins2009-08-291-3/+13
| | | | | | | | | | | | | | | | rfkill_unregister() should always be followed by rfkill_destroy() 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>
* | eeepc-laptop: whitespace for checkpatch.plLen Brown2009-08-281-2/+2
| | | | | | | | | | | | | | | | | | | | checkpatch doesn't like tab+space for a return statement. WARNING: suspect code indent for conditional statements (8, 17) + if (!device) + return -EINVAL; Signed-off-by: Len Brown <len.brown@intel.com>
* | eeepc-laptop: add rfkill support for the Wimax in ASUS Eee PC 1000HGCorentin Chary2009-08-281-0/+13
| | | | | | | | | | Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
* | eeepc-laptop: switch to dev_pm_opsAlan Jenkins2009-08-281-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also involves switching the resume handler from the acpi device to the platform device. Using the more fine grained handlers allows two improvements: 1. We only need to recheck rfkill state after resume from hibernation. 2. The wireless LED workaround accounts for up to 1.1s out of 1.7s resuming devices (when wireless is enabled). We can limit the workaround to thaw(), so that it only delays suspend to disk. The workaround is only likely to help when hibernation is aborted. Suspend to ram cannot be aborted by the user. Device suspend errors may well happen before eeepc-laptop would even be frozen. Suspend errors which happen after that could be pretty funky anyway. 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>
* | eeepc-laptop: correct the description of the hibernation abort bugAlan Jenkins2009-08-281-5/+4
| | | | | | | | | | | | | | | | | | Actually it is only the LED which is affected. The bios bug does not disable the wifi. 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>
* | eeepc-laptop: check the 3G rfkill state on resumeAlan Jenkins2009-08-281-0/+3
| | | | | | | | | | | | | | | | | | All the rfkill devices are treated as "persistent", 3G is no exception. This means their state may change over hibernation. 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>
* | eeepc-laptop: remove redundant rfkill_set_sw_state in resume handlerAlan Jenkins2009-08-281-2/+1
| | | | | | | | | | | | | | | | rfkill_set_sw_state() will already be called by eeepc_rfkill_hotplug(). 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>
generated by cgit v1.1 at 2024-12-26 23:37:19 +0000