summaryrefslogtreecommitdiffstats
path: root/drivers/misc/thinkpad_acpi.c
Commit message (Collapse)AuthorAgeFilesLines
* create drivers/platform/x86/ from drivers/misc/Len Brown2008-12-191-6949/+0
| | | | | | | | | | | | | | | | | | Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: fix fan sleep/resume pathHenrique de Moraes Holschuh2008-11-261-12/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a regression from v2.6.27, caused by commit 5814f737e1cd2cfa2893badd62189acae3e1e1fd, "ACPI: thinkpad-acpi: attempt to preserve fan state on resume". It is possible for fan_suspend() to fail to properly initialize fan_control_desired_level as required by fan_resume(), resulting on the fan always being set to level 7 on resume if the user didn't touch the fan controller. In order to get fan sleep/resume handling to work right: 1. Fix the fan_suspend handling of the T43 firmware quirk. If it is still undefined, we didn't touch the fan yet and that means we have no business doing it on resume. 2. Store the fan level on its own variable to avoid any possible issues with hijacking fan_control_desired_level (which isn't supposed to have anything other than 0-7 in it, anyway). 3. Change the fan_resume code to me more straightforward to understand (although we DO optimize the boolean logic there, otherwise it looks disgusting). 4. Add comments to help understand what the code is supposed to be doing. 5. Change fan_set_level to be less strict about how auto and full-speed modes are requested. http://bugzilla.kernel.org/show_bug.cgi?id=11982 Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Reported-by: Tino Keitel <tino.keitel@tikei.de> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad_acpi: fingers off backlight if video.ko is serving this functionalityThomas Renninger2008-11-081-10/+19
| | | | | | | | Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'thinkpad' into testLen Brown2008-10-221-2/+61
|\
| * ACPI: thinkpad-acpi: Remove firmware backlight delays for Intel ACPI IGD ↵Henrique de Moraes Holschuh2008-10-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpRegion Based on analysis and a patch from Matthew Garrett <mjg59@srcf.ucam.org>. Instruct the ThinkPad ACPI firmware to remove delays on the processing of backlight brightness changes. This method is present on ThinkPad Vista-compatible BIOSes with standard ACPI backlight level control. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Yves-Alexis Perez <corsac@debian.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: thinkpad-acpi: Remove duplicate linePascal Terjan2008-10-221-1/+0
| | | | | | | | | | | | Signed-off-by: Pascal Terjan <pterjan@mandriva.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: thinkpad-acpi: trivial fix of error messageMariusz Kozlowski2008-10-221-1/+2
| | | | | | | | | | | | | | | | | | Trivial fix makes the error message match the code before it (ibm->driver vs ibm->acpi-driver) better. Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: thinkpad-acpi: attempt to preserve fan state on resumeHenrique de Moraes Holschuh2008-10-221-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attempt to preserve fan state across sleep and hibernation if the fan control mode is enabled. For safety reasons, only the PWM OFF (fan at 100%) or maximum closed-loop level (level 7) are preserved. If the fan state was set to anything else, it will not be restored. Also, should the fan be at PWM OFF mode at resume, it will be left at that state (but this is extremely unlikely, no ThinkPad firmware was ever reported to do this). For reference, the known states used for fan control upon resume by the firmware are either "auto" or "level 7" depending on whether the laptop wakes due to normal conditions or a thermal emergency. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=11331 Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: catch calls of acpi_driver_data on pointer of wrong typePavel Machek2008-10-101-1/+1
|/ | | | | | | | | | | Catch attempts to use of acpi_driver_data on pointers of wrong type. akpm: rewritten to use proper C typechecking and remove the "function"-used-as-lvalue thing. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: wan radio control is not experimentalJeremy Fitzhardinge2008-08-281-1/+0
| | | | | | | | The WWAN radio control has been working well for over three years, and is no longer experimental. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* ACPI: thinkpad-acpi: don't misdetect in get_thinkpad_model_data() on -ENOMEMHenrique de Moraes Holschuh2008-07-211-14/+33
| | | | | | | | | | | Explicitly check for memory allocation failures, and return status to indicate that we could not collect data due to errors. This lets the driver have a far more predictable failure mode on ENOMEM in that codepath: it will refuse to load. This is far better than trying to proceed with missing data which is used to detect quirks, etc. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* ACPI: thinkpad-acpi: bump up version to 0.21Henrique de Moraes Holschuh2008-07-211-1/+1
| | | | | | rfkill support deserves a new version checkpoint... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* ACPI: thinkpad-acpi: add bluetooth and WWAN rfkill supportHenrique de Moraes Holschuh2008-07-211-26/+182
| | | | | | | | | | | | | | | Add a read/write rfkill interface to the bluetooth radio switch on the bluetooth submodule, and one for the wireless wan radio switch to the wan submodule. Since rfkill does care for when a switch changes state, use WLSW notifications to also check if the WWAN or Bluetooth switches did not change state (due to them being slaves of WLSW in firmware/hardware, but that reality not being always properly exported by the thinkpad firmware). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: John W. Linville <linville@tuxdriver.com>
* ACPI: thinkpad-acpi: WLSW overrides other rfkill switchesHenrique de Moraes Holschuh2008-07-211-0/+20
| | | | | | | | | | | | | | | | On ThinkPads where the WLSW switch exists, the firmware or the hardware ANDs the WLSW state with the device-specific switches (WWAN, Bluetooth). It is downright impossible to enable WWAN or Bluetooth when WLSW is blocking the radios. This reality does not necessarily carry over to the WWAN and Bluetooth firmware interfaces, though... so the state thinkpad-acpi was reporting could be incorrect. Tie the three switches in the driver so that we keep their state sane. When WLSL is off, force the other switches to off as well. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* ACPI: thinkpad-acpi: prepare for bluetooth and wwan rfkill supportHenrique de Moraes Holschuh2008-07-211-80/+74
| | | | | | | | Get rid of some forward definitions by moving code around, this will make the rfkill conversion of wwan and bluetooth a bit cleaner. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* ACPI: thinkpad-acpi: consolidate wlsw notification functionHenrique de Moraes Holschuh2008-07-211-20/+19
| | | | | | | | | Rename tpacpi_input_send_radiosw() to tpacpi_send_radiosw_update(), and make it a central point to issue "radio switch changed state" notifications by consolidating also the poll() notification in the same function. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* ACPI: thinkpad-acpi: minor refactor on radio switch initHenrique de Moraes Holschuh2008-07-211-23/+26
| | | | | | | | | Change the code of hotkey_init, wan_init and bluetooth_init a bit to make it much easier to add some Kconfig-selected debugging code later. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: fix LED handling on older ThinkPadsHenrique de Moraes Holschuh2008-06-111-27/+28
| | | | | | | | | | | | | | | | | | | | | | | | The less tested codepaths for LED handling, used on ThinkPads 570, 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20 and maybe a few others, would write data to kernel memory it had no business touching, for leds number 3 and above. If one is lucky, that illegal write would cause an OOPS, but chances are it would silently corrupt a byte. The problem was introduced in commit af116101, "ACPI: thinkpad-acpi: add sysfs led class support to thinkpad leds (v3.2)". Fix the bug by refactoring the entire code to be far more obvious on what it wants to do. Also do some defensive "constification". Issue reported by Karol Lewandowski <lmctlx@gmail.com> (he's an lucky guy and got an OOPS instead of silent corruption :-) ). Root cause of the OOPS identified by Adrian Bunk <bunk@kernel.org>. Thanks, Adrian! Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Tested-by: Karol Lewandowski <lmctlx@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad-acpi: fix initialization error pathsHenrique de Moraes Holschuh2008-06-111-207/+230
| | | | | | | | | | | | Rework some subdriver init and exit handlers, in order to fix some initialization error paths that were missing, or broken. Hitting those bugs should be extremely rare in the real world, but should that happen, thinkpad-acpi would fail to dealocate some resources and a reboot might well be needed to be able to load the driver again. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad-acpi: SW_RADIO to SW_RFKILL_ALL renameHenrique de Moraes Holschuh2008-06-111-2/+2
| | | | | | | | | Rename SW_RADIO to SW_RFKILL_ALL in thinkpad-acpi code and docs, following 5adad0133907790c50283bf03271d920d6897043 "Input: rename SW_RADIO to SW_RFKILL_ALL". Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* acpi: fix sparse const errorsHarvey Harrison2008-05-301-5/+5
| | | | | | | | | | | | | | | | | In this case we want a constant pointer to constant chars: drivers/misc/thinkpad_acpi.c:3824:19: error: Just how const do you want this type to be? Like the error says. drivers/misc/thinkpad_acpi.c:3863:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3864:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3865:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3866:19: error: Just how const do you want this type to be? Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
*---. Merge branches 'release', 'acpica', 'bugzilla-10224', 'bugzilla-9772', ↵Len Brown2008-04-301-193/+572
|\ \ \ | | | | | | | | | | | | 'bugzilla-9916', 'ec', 'eeepc', 'idle', 'misc', 'pm-legacy', 'sysfs-links-2.6.26', 'thermal', 'thinkpad' and 'video' into release
| | | * ACPI: thinkpad-acpi: bump up version to 0.20Henrique de Moraes Holschuh2008-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Full LED sysfs support, and the rest of the assorted minor fixes and enhancements are a good reason to checkpoint a new version... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: use a private workqueueHenrique de Moraes Holschuh2008-04-291-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch all task workers to a private thinkpad-acpi workqueue. This way, we don't risk causing trouble for other tasks scheduled to the default work queue, as our workers end up needing to access the ACPI EC, run ACPI AML code, trigger SMI traps... and none of those are exactly known to be fast, simple operations. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: fluff really minor fixHenrique de Moraes Holschuh2008-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a minor (nano?) thing that bothered me at exactly at the wrong time. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: add sysfs led class support to thinkpad leds (v3.2)Henrique de Moraes Holschuh2008-04-291-1/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a sysfs led class interface to the led subdriver. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: add sysfs led class support for thinklight (v3.1)Henrique de Moraes Holschuh2008-04-291-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a sysfs led class interface to the thinklight (light subdriver). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: prepare light and LED for sysfs supportHenrique de Moraes Holschuh2008-04-291-55/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do some preparatory work to add sysfs support to the thinklight and thinkpad leds driver. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: claim tpacpi as an official short handle (v1.1)Henrique de Moraes Holschuh2008-04-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, a lot of stuff in the kernel has size limitations, so "thinkpad-acpi" ends up eating up too much real estate. We were using "tpacpi" in symbols already, but this shorthand was not visible to userland. Document that the driver will use tpacpi as a short hand where necessary, and use it to name the kernel thread for NVRAM polling (now named "ktpacpi_nvramd"). Also, register a module alias with the shorthand. One can refer to the module using the shorthand name. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: fix brightness dimming control bugHenrique de Moraes Holschuh2008-04-291-15/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ibm-acpi and thinkpad-acpi did not know about bit 5 of the EC backlight level control register (EC 0x31), so it was always forced to zero on any writes. This would disable the BIOS option to *not* use a dimmer backlight level scale while on battery, and who knows what else (there are two other control bits of unknown function). Bit 5 controls the "reduce backlight levels when on battery" optional functionality (active low). Bits 6 and 7 are better left alone as well, instead of being forced to zero. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: rate-limit CMOS/EC unsynced error messagesHenrique de Moraes Holschuh2008-04-291-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If userspace applications mess with the CMOS NVRAM, or something causes both the ACPI firmware and thinkpad-acpi to try to change the brightness at the same time, it is possible to have the CMOS and EC registers for the current brightness go out of sync. Should that happen, thinkpad-acpi could be really obnoxious when using a brightness_mode of 3 (both EC and CMOS). Instead of complaining a massive number of times, make sure to complain only once until EC and CMOS are back in sync. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Joerg Platte <lists@naasa.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: enhance box identification output (v2)Henrique de Moraes Holschuh2008-04-291-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During initialization, thinkpad-acpi outputs some messages to make sure releavant box identification information is easily available in-line with the rest of the driver messages. Enhance those messages to output the alfanumeric model number as well. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: warn once about weird hotkey masksHenrique de Moraes Holschuh2008-04-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thinkpad-acpi knows for a while now how to best program the hotkeys by default, and always enable them by default. Unfortunately, this information has not filtered down everywhere it needs to, yet. Notably, old ibm-acpi documentation and most "thinkpad setup guides" will have wrong information on this area. Warn the local admin once whenever any of the following patterns are met: 1. Attempts to set hotkey mask to 0xffff (artifact from docs and config for the old ibm-acpi driver and behaviour). This mask makes no real-world sense; 2. Attempts to set hotkey mask to 0xffffffff, which means the user is trying to just have "everything work" without even reading the documentation, or that we need to get a bug report, because there is a new thinkpad out there with new exciting hot keys :-) 3. Attempts to set hotkey mask to 0xffffff, which is almost never the correct way to set up volume and brightness event reporting (and with the current state-of-the-art, it is known to never be right way to do it). The driver will perform any and all requested operations, though, regardless of any warnings. I hope these warnings can be removed one or two years from now. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: thinkpad-acpi: BIOS backlight mode helper (v2.1)Henrique de Moraes Holschuh2008-04-291-105/+133
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lenovo ThinkPads with generic ACPI backlight level control can be easily set to react to keyboard brightness key presses in a more predictable way than what they do when in "DOS / bootloader" mode after Linux brings up the ACPI interface. The switch to the ACPI backlight mode in the firmware is designed to be safe to use only as an one way trapdoor. One is not to force the firmware to switch back to "DOS/bootloader" mode except by rebooting. The mode switch itself is performed by calling any of the ACPI _BCL methods at least once. When in ACPI mode, the backlight firmware just issues (standard) events for the brightness up/down hot key presses along with the non-standard HKEY events which thinkpad-acpi traps, and doesn't touch the hardware. thinkpad-acpi will: 1. Place the ThinkPad firmware in ACPI backlight control mode if one is available 2. Suppress HKEY backlight change notifications by default to avoid double-reporting when ACPI video is loaded when the ThinkPad is in ACPI backlight control mode 3. Urge the user to load the ACPI video driver The user is free to use either the ACPI video driver to get the brightness key events, or to override the thinkpad-acpi default hotkey mask to get them from thinkpad-acpi as well (this will result in duplicate events if ACPI video is loaded, so let's hope distros won't screw this up). Provided userspace is sane, all should work (and *keep* working), which is more that can be said about the non-ACPI mode of the new Lenovo ThinkPad BIOSes when coupled to current userspace and X.org drivers. Full guidelines for backlight hot key reporting and use of the thinkpad-acpi backlight interface have been added to the documentation. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| * | thinkpad_acpi: fix possible NULL pointer dereference if kstrdup failedCyrill Gorcunov2008-04-291-1/+1
|/ / | | | | | | | | | | | | Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: thinkpad-acpi: fix hotkey_get_tablet_modeHenrique de Moraes Holschuh2008-03-041-1/+2
|/ | | | | | | | | | | | | | | | I used the wrong return convention on hotkey_get_tablet_mode(), breaking a lot of stuff. Bad Henrique! Fix it to return the status in the parameter-by-reference, and IO status on the function return value. Duh. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Zdenek Kabelac <zdenek.kabelac@gmail.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI: thinkpad-acpi: add tablet-mode reportingHenrique de Moraes Holschuh2008-02-161-11/+68
| | | | | | | | | | | | | | | A quick study of the 0x5009/0x500A HKEY event on the X61t DSDT revealed the existence of the EC HTAB register (EC 0x0f, bit 7), and a compare with the X41t DSDT shows that HKEY.MHKG can be used to verify if the ThinkPad is tablet-capable (MHKG present), and in tablet mode (bit 3 of MHKG return is set). Add an attribute to report this information, "hotkey_tablet_mode". This attribute has poll()/select() support, and can be used along with EV_SW SW_TABLET_MODE to hook userspace to tablet events. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: minor hotkey_radio_sw fixesHenrique de Moraes Holschuh2008-02-161-4/+4
| | | | | | | Fixes some minor points in the radio switch code and docs. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: issue input events for tablet swivel eventsHenrique de Moraes Holschuh2008-02-161-2/+20
| | | | | | | | | Issue EV_SW SW_TABLET_MODE events for HKEY events 0x5009 and 0x500A on the X41t/X60t/X61t. As usual, we suppress the HKEY events on the netlink interface to avoid sending duplicate events to userspace. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: make the video output feature optionalHenrique de Moraes Holschuh2008-02-161-7/+13
| | | | | | | | | | The video output port control feature is not very useful on many ThinkPads (especially when a X server is running), and lately userspace is getting better and better at it, so it makes sense to allow users to stripe out the thinkpad-acpi video feature from their kernels and save at least 2KB. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: synchronize input device switchesHenrique de Moraes Holschuh2008-02-161-0/+1
| | | | | | | | Issue EV_SW events at module init time to synchronize the input device with the current state of the switch, otherwise we might lose the first event. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: always track input device open/closeHenrique de Moraes Holschuh2008-02-161-5/+8
| | | | | | | | | The open() and close() hooks for the input device are useful even when hotkey NVRAM polling support is not in use, so it is better to always have them around. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: trivial fix to module_desc typoHenrique de Moraes Holschuh2008-02-161-1/+1
| | | | | | | Thanks to Damjan <gdamjan@mail.net.mk> for noticing this one. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad_acpi: staticAdrian Bunk2008-02-141-2/+2
| | | | | | Signed-off-by: Adrian Bunk <bunk@kernel.org> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: second TP_EC_FAN_FULLSPEED should be TP_EC_FAN_AUTORoel Kluin2008-02-071-1/+1
| | | | | | | | | fix bug in safety net for TPEC fan control mode eaa7571b2d1a08873e4bdd8e6db3431df61cd9ad Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: bump up version to 0.19Henrique de Moraes Holschuh2008-02-011-1/+1
| | | | | | | | The major code reorganization and cleanups, and new HKEY events, plus poll()/select() support are good reasons to checkpoint a new version... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: update copyright dates to 2008Henrique de Moraes Holschuh2008-02-011-1/+1
| | | | | | | Update the copyright headers to include 2008. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: add poll() support to some sysfs attributesHenrique de Moraes Holschuh2008-02-011-4/+32
| | | | | | | | | | | | | Implement poll()/select() support through sysfs_notify() for some key attributes which userspace might want to poll() or select() on. In order to let userspace know poll()/select() support is available for an attribute, the thinkpad-acpi sysfs interface version is also bumped up. Further changes that add poll()/select() capabilities to any pre-existing attributes will also increment the sysfs interface version. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: silence _sta warningHenrique de Moraes Holschuh2008-02-011-0/+2
| | | | | | | | | | | | | When both CONFIG_THINKPAD_ACPI_DOCK and CONFIG_THINKPAD_ACPI_BAY are undefined, _sta is not used and that causes a gcc warning. Fix it (and I think this is a regression, I am pretty sure I fixed this once before, sorry about that). Issue reported by: Pritt Laes. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Pritt Laes <plaes@plaes.org> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: thinkpad-acpi: add X61t HKEY eventsHenrique de Moraes Holschuh2008-02-011-3/+6
| | | | | | | | | | Tomas Carnecky reports that events 0x5009 and 0x500a are swivel events, and that 0x500b/0x500c are tablet pen storage bay events. Document these events, and avoid nasty messages when they happen. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
OpenPOWER on IntegriCloud