summaryrefslogtreecommitdiffstats
path: root/drivers/misc
diff options
context:
space:
mode:
authorHenrique de Moraes Holschuh <hmh@hmh.eng.br>2008-07-21 09:15:50 -0300
committerHenrique de Moraes Holschuh <hmh@hmh.eng.br>2008-07-21 09:15:50 -0300
commit133ec3bd3ae409895eacdce326cdc8d73c249e8a (patch)
tree0e97e3089febe85b478c3b72022f4e058bb709ec /drivers/misc
parent07431ec82bf9dc74b470a1d820b41c92c4d86e6f (diff)
downloadkernel-crypto-133ec3bd3ae409895eacdce326cdc8d73c249e8a.tar.gz
kernel-crypto-133ec3bd3ae409895eacdce326cdc8d73c249e8a.tar.xz
kernel-crypto-133ec3bd3ae409895eacdce326cdc8d73c249e8a.zip
ACPI: thinkpad-acpi: WLSW overrides other rfkill switches
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>
Diffstat (limited to 'drivers/misc')
-rw-r--r--drivers/misc/thinkpad_acpi.c20
1 files changed, 20 insertions, 0 deletions
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 743a4d6098e..202d63e1b39 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -2588,6 +2588,10 @@ static int bluetooth_get_radiosw(void)
if (!tp_features.bluetooth)
return -ENODEV;
+ /* WLSW overrides bluetooth in firmware/hardware, reflect that */
+ if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&status) && !status)
+ return 0;
+
if (!acpi_evalf(hkey_handle, &status, "GBDC", "d"))
return -EIO;
@@ -2601,6 +2605,12 @@ static int bluetooth_set_radiosw(int radio_on)
if (!tp_features.bluetooth)
return -ENODEV;
+ /* WLSW overrides bluetooth in firmware/hardware, but there is no
+ * reason to risk weird behaviour. */
+ if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&status) && !status
+ && radio_on)
+ return -EPERM;
+
if (!acpi_evalf(hkey_handle, &status, "GBDC", "d"))
return -EIO;
if (radio_on)
@@ -2760,6 +2770,10 @@ static int wan_get_radiosw(void)
if (!tp_features.wan)
return -ENODEV;
+ /* WLSW overrides WWAN in firmware/hardware, reflect that */
+ if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&status) && !status)
+ return 0;
+
if (!acpi_evalf(hkey_handle, &status, "GWAN", "d"))
return -EIO;
@@ -2773,6 +2787,12 @@ static int wan_set_radiosw(int radio_on)
if (!tp_features.wan)
return -ENODEV;
+ /* WLSW overrides bluetooth in firmware/hardware, but there is no
+ * reason to risk weird behaviour. */
+ if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&status) && !status
+ && radio_on)
+ return -EPERM;
+
if (!acpi_evalf(hkey_handle, &status, "GWAN", "d"))
return -EIO;
if (radio_on)