linux-stable.git/drivers/platform, branch linux-2.6.30.y

thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM

2009-10-05T15:28:07+00:00

HBRV-based default selection of backlight control strategy didn't work
well, at least the X41 defines it but doesn't use it and I don't think
it will stop there.  Switch to a blacklist, and make sure only Radeon-
based models get ECNVRAM.

Symptoms of incorrect backlight mode selection are:

1. Non-working backlight control through sysfs;

2. Backlight gets reset to the lowest level at every shutdown, reboot
   and when thinkpad-acpi gets unloaded;

This fixes a regression in 2.6.30, bugzilla #13826.  This fix is
already present on 2.6.31.

This is a minimal patch for 2.6.30-stable, based on mainline
commits: 050df107c408a3df048524b3783a5fc6d4dccfdb,
	 7d95a3d564901e88ed42810f054e579874151999,
	 59fe4fe34d7afdf63208124f313be9056feaa2f4,
	 6da25bf51689a5cc60370d30275dbb9e6852e0cb

Signed-off-by: Henrique de Moraes Holschuh 
Reported-by: Tobias Diedrich 
Reported-by: Robert de Rooy 
Signed-off-by: Greg Kroah-Hartman

wmi: fix kernel panic when stack protection enabled.

2009-09-09T03:33:25+00:00

commit f3d83e2415445e5b157bef404d38674e9e8de169 upstream.

Summary:
Kernel panic arise when stack protection is enabled, since strncat will
add a null terminating byte '\0'; So in functions
like this one (wmi_query_block):
        char wc[4]="WC";
	....
	strncat(method, block->object_id, 2);
        ...
the length of wc should be n+1 (wc[5]) or stack protection
fault will arise. This is not noticeable when stack protection is
disabled,but , isn't good either.
Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y,
	      CONFIG_CC_STACKPROTECTOR=y]

Panic Trace
------------
       .... stack-protector: kernel stack corrupted in : fa7b182c
       2.6.30-rc8-obelisco-generic
       call_trace:
           [] ? panic+0x45/0xd9
	   [] ? __stack_chk_fail+0x1c/0x40
	   [] ? wmi_query_block+0x15a/0x162 [wmi]
	   [] ? wmi_query_block+0x15a/0x162 [wmi]
	   [] ? acer_wmi_init+0x00/0x61a [acer_wmi]
	   [] ? acer_wmi_init+0x135/0x61a [acer_wmi]
	   [] ? do_one_initcall+0x50+0x126

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514

Signed-off-by: Costantino Leandro 
Signed-off-by: Carlos Corbacho 
Cc: Len Brown 
Cc: Bjorn Helgaas 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

thinkpad-acpi: disable broken bay and dock subdrivers

2009-08-16T21:18:33+00:00

commit 550e7fd8afb7664ae7cedb398c407694e2bf7d3c upstream.

Currently, the ThinkPad-ACPI bay and dock drivers are completely
broken, and cause a NULL pointer derreference in kernel mode (and,
therefore, an OOPS) when they try to issue events (i.e. on dock,
undock, bay ejection, etc).

OTOH, the standard ACPI dock driver can handle the hotplug bays and
docks of the ThinkPads just fine (including batteries) as of 2.6.27.
In fact, it does a much better job of it than thinkpad-acpi ever did.

It is just not worth the hassle to find a way to fix this crap without
breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
deprecated code that sees little testing or use.

As a quick fix suitable for -stable backports, mark the thinkpad-acpi
bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
removed by a later patch.

This fixes bugzilla #13669, and should be applied to 2.6.27 and later.

Signed-off-by: Henrique de Moraes Holschuh 
Reported-by: Joerg Platte 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

eeepc-laptop: unregister_rfkill_notifier on failure

2009-05-14T15:28:27+00:00

If there is a failure during eeepc_hotk_add() we need
to remove the acpi_notify_handler.

Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

asus-laptop: fix input keycode

2009-05-14T15:27:46+00:00

KEY_STOP is now KEY_STOPCD
 It's the correct key to stop a media
BTN_EXTRA is now KEY_SCREENLOCK:
 The laptop manual tells us that this key is for screenlock
KEY_TV is now KEY_PROG1
 So it can be reported to X server

Ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361505

Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

eeepc-laptop: support for super hybrid engine (SHE)

2009-05-14T15:23:40+00:00

The older eeepc-acpi driver allowed to control the SHE performance
preset through a ACPI function for just this purpose. SHE underclocks
and undervolts the FSB and undervolts the CPU (at preset 2,
"powersave"), or slightly overclocks the CPU (at preset 0,
"performance"). Preset 1 is the default setting with default clocks and
voltage.

The new eeepc-laptop driver doesn't support it anymore.
The attached patch adds support for it to eeepc-laptop. It's very
straight-forward and almost trivial.

Signed-off-by: Grigori Goronzy 
Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

eeepc-laptop: Work around rfkill firmware bug

2009-05-14T15:21:36+00:00

1) Buggy firmware can change the RFKILL state by itself. This is easily
   detected.  The RFKILL API states that in such cases, we should call
   rfkill_force_state() to notify the core.

   I have reported the bug to Asus. I believe this is the right thing
   to do for robustness, even if this particular firmware bug is fixed.

2) The same bug causes the wireless toggle key to be reported as 0x11
   instead of 0x10.  0x11 is otherwise unused, so it should be safe to
   add this as a new keycode.

The bug is triggered by removing the laptop battery while hibernated.

On resume, the wireless toggle key causes the firmware to toggle the
wireless state itself.  (Also, the key is reported as 0x11 when the
current wireless state is OFF).

This is very poor behaviour because the OS can't predict whether the
firmware is controlling the RFKILL state.

Without this workaround, the bug means users have to press the wireless
toggle key twice to enable, due to the OS/firmware conflict.  (Assuming
rfkill-input or equivalent is being used).  The workaround avoids this.

I believe that acpid scripts which toggle the value of the sysfs state file
when the toggle key is pressed will be rendered ineffective by the bug,
regardless of this workaround.  If they simply toggle the state, when the
firmware has already toggled it, then you will never see a state change.

Tested on "EEEPC 4G" only.

Signed-off-by: Alan Jenkins 
Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

eeepc-laptop: report brightness control events via the input layer

2009-05-14T15:19:32+00:00

This maps the brightness control events to one of two keys, either
KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed.

Some mapping has to be done due to the fact that the BIOS reports them as
 + ; the selection is done according to
the sign of the change in brightness (if this is 0, no keypress is reported).

(Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html)

Signed-off-by: Darren Salt 
Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

eeepc-laptop: fix wlan rfkill state change during init

2009-05-14T15:14:42+00:00

When an rfkill device is registered, the rfkill core will change its
state to the system default. So we need to prepare for state changes
*before* we register it. That means installing the eeepc-specific ACPI
callback which handles the hotplug of the wireless network adaptor.

This problem doesn't occur during normal operation.  You have to

1) Boot with wireless enabled. eeepc-laptop should load automatically.
2) modprobe -r eeepc-laptop
3) modprobe eeepc-laptop

On boot, the default rfkill state will be set to enabled.
With the current core code, step 2) will disable the wireless.
Therefore in step 3), the wireless will change state during registration,
from disabled to enabled.  But without this fix, the PCI device for the
wireless adaptor will not appear.

Signed-off-by: Alan Jenkins 
Acked-by: Matthew Garrett 
Signed-off-by: Corentin Chary 
Signed-off-by: Len Brown

Merge branch 'sony-laptop' into release

2009-04-24T05:34:52+00:00