linux/drivers/platform, branch v3.0.81

thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

2013-06-07T19:46:49Z

commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream. In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. Test on V490u ============= == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device Test on B485 ============= This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Signed-off-by: Manoj Iyer Signed-off-by: Matthew Garrett Cc: Shuduo Sang Signed-off-by: Greg Kroah-Hartman

asus-laptop: Do not call HWRS on init

2013-03-28T19:06:14Z

commit cb7da022450cdaaebd33078b6b32fb7dd2aaf6db upstream. Since commit 8871e99f89b7 ('asus-laptop: HRWS/HWRS typo'), module initialisation is very slow on the Asus UL30A. The HWRS method takes about 12 seconds to run, and subsequent initialisation also seems to be delayed. Since we don't really need the result, don't bother calling it on init. Those who are curious can still get the result through the 'infos' device attribute. Update the comment about HWRS in show_infos(). Reported-by: ryan References: http://bugs.debian.org/692436 Signed-off-by: Ben Hutchings Signed-off-by: Corentin Chary Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman

acer-wmi: support for P key on TM8372

2012-12-03T20:59:15Z

commit 67e1d34cd54cbf33f093f1dd53e7bda1124eb972 upstream. BugLink: http://launchpad.net/bugs/865807 There is no entry for P key on TM8372, so when P key is pressed, only "acer_wmi: Unknown key number - 0x29" in dmesg. Signed-off-by: Merlin Schumacher Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

asus-nb-wmi: add some video toggle keys

2012-10-02T16:47:40Z

commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream. There are some new video switch keys that used by newer machines. 0xA0 - SDSP HDMI only 0xA1 - SDSP LCD + HDMI 0xA2 - SDSP CRT + HDMI 0xA3 - SDSP TV + HDMI But in Linux, there is no suitable userspace application to handle this, so, mapping them all to KEY_SWITCHVIDEOMODE. Signed-off-by: AceLan Kao Signed-off-by: Matthew Garrett Cc: Tim Gardner Signed-off-by: Greg Kroah-Hartman

asus-laptop: HRWS/HWRS typo

2012-10-02T16:47:40Z

commit 8871e99f89b7d7b1ea99de550eea2a56273f42ab upstream. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=24222 Signed-off-by: Corentin Chary Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman

intel_ips: blacklist HP ProBook laptops

2012-07-19T15:58:21Z

commit 88ca518b0bb4161e5f20f8a1d9cc477cae294e54 upstream. intel_ips driver spews the warning message "ME failed to update for more than 1s, likely hung" at each second endlessly on HP ProBook laptops with IronLake. As this has never worked, better to blacklist the driver for now. Signed-off-by: Takashi Iwai Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman

sony-laptop: Enable keyboard backlight by default

2012-05-21T16:40:00Z

commit 6fe6ae56a7cebaebc2e6daa11c423e4692f9b592 upstream. When the keyboard backlight support was originally added, the commit said to default it to on with a 10 second timeout. That actually wasn't the case, as the default value is commented out for the kbd_backlight parameter. Because it is a static variable, it gets set to 0 by default without some other form of initialization. However, it seems the function to set the value wasn't actually called immediately, so whatever state the keyboard was in initially would remain. Then commit df410d522410e67660 was introduced during the 2.6.39 timeframe to immediately set whatever value was present (as well as attempt to restore/reset the state on module removal or resume). That seems to have now forced the light off immediately when the module is loaded unless the option kbd_backlight=1 is specified. Let's enable it by default again (for the first time). This should solve https://bugzilla.redhat.com/show_bug.cgi?id=728478 Signed-off-by: Josh Boyer Acked-by: Mattia Dongili Signed-off-by: Matthew Garrett Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

acer-wmi: No wifi rfkill on Sony machines

2012-04-13T15:14:08Z

commit 5719b81988f3c24ff694dc3a37e35b35630a3966 upstream. The wireless rfkill should charged by sony-laptop but not acer-wmi. So, add Sony's SNY5001 acpi device to blacklist in acer-wmi. Tested on Sony Vaio Cc: Carlos Corbacho Cc: Matthew Garrett Cc: Mattia Dongili Cc: Dimitris N Tested-by: Dimitris N Signed-off-by: Lee, Chun-Yi Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman

acer-wmi: No wifi rfkill on Lenovo machines

2012-03-19T15:57:45Z

commit 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a upstream. We have several reports which says acer-wmi is loaded on ideapads and register rfkill for wifi which can not be unblocked. Since ideapad-laptop also register rfkill for wifi and it works reliably, it will be fine acer-wmi is not going to register rfkill for wifi once VPC2004 is found. Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no wifi rfkill capability, there are reports which says acer-wmi also block wireless on Thinkpad E520/E420. Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman

acer-wmi: check wireless capability flag before register rfkill

2012-03-19T15:57:45Z

commit 1709adab0773616da7a8190f2762e599afb0a295 upstream. There will be better to check the wireless capability flag (ACER_CAP_WIRELESS) before register wireless rfkill because maybe the machine doesn't have wifi module or the module removed by user. Tested on Acer Travelmate 8572 Tested on Acer Aspire 4739Z Tested-by: AceLan Kao Cc: Carlos Corbacho Cc: Matthew Garrett Cc: Dmitry Torokhov Cc: Corentin Chary Cc: Thomas Renninger Signed-off-by: Lee, Chun-Yi Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman