- 07 7月, 2011 2 次提交
-
-
Handle events 0x4010 and 0x4011 so that we do not pester users about them. These events report when the thinkpad is docked/undocked to a native hotplug dock (i.e. one that does not need ACPI handling, nor is represented in the ACPI device tree). Such docks are based on USB 2.0/3.0, and also work as port replicators. We really want a proper dock class to report these, or at least new input EV_SW events. Since it is not clear which one to use yet, keep reporting them as vendor-specific ThinkPad events. WARNING: As defined by the thinkpad-acpi sysfs ABI rules of engagement, the vendor-specific events will be REMOVED as soon as generic events are made available (duplicate events are a big problem), with an appropriate update to the thinkpad-acpi sysfs/event ABI versioning. Userspace is already prepared to provide easy backwards compatibility for such changes when convenient to the distro (see acpi-fakekey). * Event 0x4010: docking to hotplug dock/port replicator * Event 0x4011: undocking from hotplug dock/port replicator Typical usecase would be to trigger display reconfiguration. Reports mention T410, T510, and series 3 docks/port replicators. Special thanks to Robert de Rooy for his extensive report and analysis of the situation. http://www.thinkwiki.org/wiki/ThinkPad_Port_Replicator_Series_3 http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Series_3 http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3 http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3_for_Mobile_Workstations http://lenovoblogs.com/insidethebox/?p=290Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: NClaudius Hubig <claudiushubig@chubig.net> Reported-by: NDoctor Bill <docbill@gmail.com> Reported-by: NKorte Noack <gbk.noack@gmx.de> Reported-by: NRobert de Rooy <robert.de.rooy@gmail.com> Reported-by: NSebastian Will <swill@csail.mit.edu> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
Handle some user interface events from the newer Lenovo models. We are likely to do something smart with these events in the future, for now, hide the ones we are already certain about from the user and userspace both. * Events 0x6000 and 0x6005 are key-related. 0x6005 is not properly identified yet. Ignore these events, and do not report them. * Event 0x6040 has not been properly identified yet, and we don't know if it is important (looks like it isn't, but still...). Keep reporting it. * Change the message the driver outputs on unknown 0x6xxx events, as all recent events are not related to thermal alarms. Degrade log level from ALERT to WARNING. Thanks to all users who reported these events or asked about them in a number of mailing lists. Your help is highly appreciated, even if I did took a lot of time to act on them. For that I apologise. I will list those that identified the reasons for the events as "reported-by", and I apologise in advance if I leave anyone out: it was not done on purpose, I made the mistake of not properly tagging all event report emails separately, and might have missed some. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Reported-by: NMarkus Malkusch <markus@malkusch.de> Reported-by: NPeter Giles <g1l3sp@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 28 5月, 2011 2 次提交
-
-
由 Joe Perches 提交于
Add pr_fmt. Removed local TPACPI_<level> #defines, convert to pr_<level>. Neaten dbg_<foo> macros. Added a few missing newlines to logging messages. Added static inline str_supported for !CONFIG_THINKPAD_ACPI_DEBUG vdbg_printk defect reported by Sedat Dilek <sedat.dilek@googlemail.com>. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Joe Perches 提交于
Move TPACPI_HANDLE declaration into #ifdef block and neaten it a bit. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 09 5月, 2011 1 次提交
-
-
由 Manoj Iyer 提交于
The newer Lenovo ThinkPads have HKEY HID of LEN0068 instead of IBM0068. Added new HID so that thinkpad_acpi module will auto load on these newer Lenovo ThinkPads. Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org Signed-off-by: NManoj Iyer <manoj.iyer@canonical.com> Signed-off-by: NAndy Lutomirski <luto@mit.edu> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 12 4月, 2011 1 次提交
-
-
由 Keith Packard 提交于
The new BIOS has a slightly different EC version string. From a1541710300b083a1a9acff2890d721d15ede62b Mon Sep 17 00:00:00 2001 From: Keith Packard <keithp@keithp.com> Date: Sun, 13 Mar 2011 23:46:22 -0700 Subject: [PATCH] thinkpad-acpi: Some BIOS versions don't end in WW, remove check My X201s BIOS version string is 6QET46V1 (1.16 ). The EC version string is 6QHT28WW-1.09. The driver was requiring that both of these have 'WW' in positions 6 and 7. I don't know what the significance of having 'V1' there instead is, but removing the test makes the driver load on my machine. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 28 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 23 3月, 2011 1 次提交
-
-
由 Matthew Garrett 提交于
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>
-
- 22 2月, 2011 1 次提交
-
-
由 Seth Forshee 提交于
Some thinkpad hotkeys report key codes like KEY_FN_F8 when something like KEY_VOLUMEDOWN is desired. Always provide the scan codes in addition to the key codes to assist with debugging these issues. Also send the scan code before the key code to match what other drivers do, as some userspace utilities expect this ordering. Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 08 1月, 2011 2 次提交
-
-
由 Jesper Juhl 提交于
ACPI Thinkpad: We must always call va_end() after va_start() but do not do so in thinkpad_acpi.c::acpi_evalf() Hi, In drivers/platform/x86/thinkpad_acpi.c::acpi_evalf() we don't always call va_end() after va_start(). This patch corrects that. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 25 11月, 2010 1 次提交
-
-
由 Julia Lawall 提交于
Delete successive assignments to the same location. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression i; @@ *i = ...; i = ...; // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 16 11月, 2010 1 次提交
-
-
由 Lionel Debroux 提交于
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>
-
- 02 11月, 2010 1 次提交
-
-
由 Uwe Kleine-König 提交于
"gadget", "through", "command", "maintain", "maintain", "controller", "address", "between", "initiali[zs]e", "instead", "function", "select", "already", "equal", "access", "management", "hierarchy", "registration", "interest", "relative", "memory", "offset", "already", Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 24 9月, 2010 1 次提交
-
-
Change the code so that it will use the correct size for keymap entries. Do it in a way that makes it harder to screw it up in the future. Reported-by: NJaime Velasco Juan <jsagarribay@gmail.com> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 16 8月, 2010 5 次提交
-
-
由 Jens Taprogge 提交于
On the T410s and most likely other current models, Fn-F6 is labeled as Camera/Headphone key. Report key presses as KEY_CAMERA. Signed-off-by: NJens Taprogge <jens.taprogge@taprogge.org> Acked-by: NJerone Young <jerone.young@canonical.com> Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
Use the quirks engine to select model-specific keymaps, which makes it much easier to extend should we need it. Keycodes are based on the tables at http://www.thinkwiki.org/wiki/Default_meanings_of_special_keys. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
Use a safer coding style for the hotkey keymap. This does not fix any problems, as the current code is correct. But it might help avoid mistakes in the future. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
acpi_video_backlight_support() already tells us if ACPI is handling backlight control through the generic ACPI handle. It is better to just trust it. While at it, adjust down a printk priority, and test earlier for brightness_enable=0. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
The Linux ACPI core locates the ACPI video devices for us and marks them with ACPI_VIDEO_HID. Use that information to locate the video device instead of a half-baked hunt for _BCL. This uncouples the detection of the number of backlight brightness levels on ThinkPads from the ACPI paths in vid_handle. With this change, the driver should be able to always detect whether the ThinkPad uses a 8-level or 16-level brightness scale even on newer models for which the vid_handle paths have not been updated yet. It will skip deactivated devices in the ACPI device tree, which is a change in behaviour. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 03 8月, 2010 1 次提交
-
-
由 Thomas Renninger 提交于
There is a general interface for that now (provided by other patches in this patch series): /sys/kernel/debug/ec/*/io Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org CC: Henrique de Moraes Holschuh <hmh@hmh.eng.br> CC: ibm-acpi-devel@lists.sourceforge.net Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 17 5月, 2010 13 次提交
-
-
Document this, it is no fun to try to second guess why this sort of stuff is in place years after it was added... Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
1. Remove <handle>_path, as its only user was already removed in a previous commit 2. Move all handle initialization, as well as <handle>_parent and <handle>_paths to __init.* sections. This reduces the driver's runtime footprint nicely. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Don't depend on the contents of led_path to know which LED interface the firmware wants. This removes the only user of *_path for the thinkpad-acpi ACPI handlers, which will simplify future code. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Log more human-friendly errors instead of numeric values when setup_acpi_notify() fails to install a notification handler. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Use acpi_format_exception() in acpi_evalf() instead of logging numeric errors. Also, when ACPICA returns an error, we should not be touching the return object, as it is invalid. In debug mode, acpi_evalf() callers would printk the returned crap (but fortunately, not use it). Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Use the EC HID (PNP0C09) to locate its main node, instead of a static list. Suggested-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg@redhat.com>
-
Disclose the user task doing ALSA access when requested by the debug bitmask. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Handle multiple brightness hotkey presses between two polling cycles. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Extract the backlight level range size detection from the brightness subdriver, and allow the other subdrivers access to that information. This also allows us to relocate some code to a more convenient place. The moved code was largerly unmodified, except for the return type of tpacpi_check_std_acpi_brightness_support(), which now is correctly marked as returning "unsigned int", and and two cosmetic fixes to make checkpatch.pl happy. Fixes for the NVRAM polling mode for the brightness hotkeys will need this. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Move the driver initial greetings out of the first subdriver, as we do a lot of other initialization before that point, and the initial greetings should go as soon as the driver decides that it should load. These greetings are not cosmetic, they make my life easier when users report bugs. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
The hotkey polling code is supposed to generate hotkey messages as close to the way the IBM event-based volume hotkey firmware does as possible, i.e: * Pressing MUTE issues a mute hotkey event, even if already mute; * Pressing Volume up/down issues a volume up/down hotkey event, even if already at maximum or minumum volume; * The act of unmuting issues a volume up/down event, depending on which hotkey was used to unmute. Fix the code to do just that (mute handling was incorrect), and handle multiple hotkey presses between two polling cycles. The new code uses the volume_toggle bit in NVRAM only to detect repeated presses of the mute key and multiple presses of the volume keys trying to go past the end of the volume scale. This will work around a bug in recent Lenovo firmware (e.g. T400), which causes the firmware to not update the volume_toggle bit in certain situations. Reported-by: NYang Zhe <yangzhe1990@gmail.com> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
The X100e needs some quick fixes to work semi-right with this driver. There are much better ways to do this, but we can start with a quick update and do it properly later. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
Lenovo is playing around with its ACPI BIOS, and will end up reusing method names. Their memory is not nearly as long as thinkpad-acpi's... Secure most of the old IBM codepaths against running in a non-IBM box. This would happen on the Lenovo X100e in video_init(), for example. We would misdetect it as an ancient model 570 firmware. Also, refuse to load the driver if we cannot identify the vendor. No ACPI ThinkPad in existence lacks this information, AFAIK. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
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>
-
- 17 3月, 2010 1 次提交
-
-
由 Matthew Garrett 提交于
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>
-
- 28 2月, 2010 1 次提交
-
-
Clemens Ladisch reports that thinkpad-acpi improperly implements the ALSA API, and always returns 0 for success for the "put" callbacks while the API requires it to return "1" when the control value has been changed in the hardware/firmware. Rework the volume subdriver to be able to properly implement the ALSA API. Based on a patch by Clemens Ladisch <clemens@ladisch.de>. This fix is also needed on 2.6.33. Reported-by: NClemens Ladisch <clemens@ladisch.de> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
-
- 26 2月, 2010 3 次提交
-
-
Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. Until the day I somehow find out a model or BIOS cut date to not provide this feature to ThinkPads that can do video switching through X RandR, change permissions so that only processes with CAP_SYS_ADMIN can access any sort of video output control state. This bug could be considered a local DoS I suppose, as it allows any non-privledged local user to cause some versions of X.org to hard-crash some ThinkPads. Reported-by: NJidanni <jidanni@jidanni.org> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
-
Studying the DSDTs of various thinkpads, it looks like bit 3 of the argument to SBDC and SWAN is not "set radio to last state on resume". Rather, it seems to be "if this bit is set, enable radio on resume, otherwise disable it on resume". So, the proper way to prepare the radios for S3 suspend is: disable radio and clear bit 3 on the SBDC/SWAN call to to resume with radio disabled, and enable radio and set bit 3 on the SBDC/SWAN call to resume with the radio enabled. Also, for persistent devices, the rfkill core does not restore state, so we really need to get the firmware to do the right thing. We don't sync the radio state on suspend, instead we trust the BIOS to not do anything weird if we never touched the radio state since boot. Time will tell if that's a wise way of doing things... Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
-
Thadeu Lima de Souza Cascardo reports this: Brightness notification does not work until the user writes to hotkey_mask attribute. That's because the polling thread will only run if hotkey_user_mask is set and someone is reading the input device or if hotkey_driver_mask is set. In this second case, this condition is not tested after the mask is changed, because the brightness and volume drivers are started after the hotkey drivers. Fix tpacpi_hotkey_driver_mask_set() to call hotkey_poll_setup(), so that the poller kthread will be started when needed. Reported-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Tested-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@kernel.org
-