toshiba_acpi: Add support for bluetooth toggling through rfkill

There's been a patch floating around for toshiba_acpi that exports an ad-hoc /proc interface to toggle the bluetooth adapter in a large number of Toshiba laptops. I'm not sure if it's still relevant for the latest models, but when I was actively using my Tecra M3 (terrible machine), I had to keep reworking the patch everytime I upgraded my kernel, and today I see that mainline still lacks a way to turn on bluetooth on these machines. So I pulled the M3 out of storage and reworked the patch to work through rfkill as Matthew has previously suggested.

This change pulls in the low level Toshiba-specific code from the old patch and sets up an rfkill device and a polled input device to track the state of the hardware kill-switch. One entertaining fact about these Toshibas is that the hardware kill-switch will turn off the bluetooth adapter but never turn it on. Conveniently, this code will turn it back on when rfkill resynchronises the software state.

At some point, someone (possibly me) should replace the remaining /proc entries with standardised interfaces. Particuarly, this applies to the handling of the special Fn-key combinations. Right now you need the fnfx userspace daemon to handle those. As a point of style, should these key combinations eventually appear on the same input device as the kill switch or a separate one? They both need to be polled, so it seems somewhat redundant to have two but maybe there are stylistic reasons to keep kill switches separate.

I've only been able to test on my Tecra M3. Particuarly helpful testing would be on machines without wireless, without bluetooth and without booth.

---
 Kconfig        |    1
 toshiba_acpi.c |  214 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 211 insertions(+), 4 deletions(-)

@@ -262,6 +262,7 @@
 config ACPI_TOSHIBA
 	tristate "Toshiba Laptop Extras"
 	depends on X86
+	select INPUT_POLLDEV
 	select BACKLIGHT_CLASS_DEVICE
 	---help---
 	  This driver adds support for access to certain system settings

[...]

Soft NAK.

Please have a look at rfkill in wireless-testing (it is going in with the merge of the net tree, so it will be in mainline really soon). rfkill has seen some changes, and no little ammount of that work was to make platform drivers like thinkpad-acpi and toshiba-acpi work better with rfkill. The documentation in Documentation/rfkill.txt was expanded and improved as well, and will help you get a better picture of how it should work. The rfkill changes should also be available in wireless-compat, and they are backport-friendly.

Please consider updating your patch to the new style rfkill class. A quick look at your patch shows that it would benefit from the new RFKILL_STATE_HARD_BLOCKED, and maybe to some rework to separate the bluetooth rfkill controller and the input device switch better. Depending on the existence of ACPI GPE events when the switch changes state on Toshibas, you may even be able to get rid of some of the polling...

If you rework/repost your patch, please CC Ivo (the rfkill maintainer) and the linux-wireless mailing list. If you want me to try to help review the patch as well, please also add me to the CC.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Well, if I can find said GPE, I'll certainly use it. A cursory glance through the dis-assembled AML didn't reveal anything obvious. Is there a way to log every single acpi event? I though acpid would receive them but it doesn't appear to.

I'll do this when I next get enough free time. Thanks for the feedback,

--phil

Yes, one of the ACPI debug options plus a magic echo to procfs/sysfs. I don't remember which :-( But it is there, you will just need to search for it, unless someone else replies with the exact one.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh