[coreboot] rfkill equivalent on the X60 - first partial success

[Charles Devereaux]

Hello

As explained before, thinkpad-acpi can't control the non-wifi radio like
bluetooth or wwan, because it expects some ACPI entries that aren't there -
so there is no rfkill control for these, even if some non-working entries
are shown with 'rfkill list'

My initial plan was to add these missing ACPI entries so that thinkpad-acpi
could be used, but I wanted to understand first what was happening. Some
documents mention things like  /proc/acpi/ibm/ecdump, but it was removed
from the kernel several years ago.

I found a very simple and practical workaround involving :
 - ec_access.c from
https://github.com/linux-wpan/linux-wpan-next/blob/master/tools/power/acpi/tools/ec/ec_access.c
 - ec-sys kernel module (compile with option CONFIG_ACPI_EC_DEBUGFS) so
that you have /sys/kernel/debug/ec/ec0/io

To emulate rfkill functionality, just write directly to the ec, for ex to
turn on wwan and wifi:
./ec_access -w 0x3a -v 0x60

For the last code, if you want to do something else, please use the
following table:
00 : nothing
10 : bluetooth
20 : wifi
30 : wifi + bluetooth
40 : wwan
50 : wwan + bluetooth
60 : wifi + wwan
70 : wifi + bluetooth + wwan

This is essentially similar to what coreboot did in src/ec/lenovo/h8/h8.c
at boot-time:
static void h8_bluetooth_enable(int on)
{
    if (on)
        ec_set_bit(0x3a, 4);
    else
        ec_clr_bit(0x3a, 4);
}

 void h8_wlan_enable(int on)
{
    if (on)
        ec_set_bit(0x3a, 5);
    else
        ec_clr_bit(0x3a, 5);
}

static void h8_wwan_enable(int on)
{
    if (on)
        ec_set_bit(0x3a, 6);
    else
        ec_clr_bit(0x3a, 6);
}

However, it works without requiring a reboot or some specific support from
within coreboot (ie cmos.layout etc). It will also toggle the LEDs.

It works great for bluetooth, basically "physically unplugging" the device
so that if you have uhci_hcd as a module, an rmmod/modprobe will no longer
show the device on lsusb.

However, for wwan, it's not that good: it's just like a soft rfkill: with a
huawei modem, you will still see the device plugged, only AT^RFSWITCH? will
tell that it's offline (ie that at+cfun=0)

Based on my understanding, this only toggles pin 20 ("wireless disable") of
the MINI PCIe, while ideally the card should no longer be powered at all or
software accessible. Based on what I've read on forums where window users
talked about wwan problems, in ibm bios there's an option to disable wwan,
so that windows doesn't even detect it - which lets me think a wouldn't
show in lsusb.

In the DSDT I see other commands, so maybe it's necessary to issue further
requests to the EC. I really don't know much about the EC (cf next message)

Meanwhile, if someone has a x60 having a factory-installed wwan (because of
whitelist issues), it'd be nice to see if (and how) the default bios can
fully disable it: if the wwan is not showing in lsusb, it might mean
something better is possible. a dump from ec_access with vs without wwan
would then be quite interesting.

Anyway, I know my solution is hackish (so I don't think it should be posted
on the wiki), but it's a good start to provide limited functionality to a
coreboot user: a proper hardware rfkill for bluetooth and a software rfkill
for wwan, which is better than nothing at all.

I'll try to create a kernel module that would expose a rfkill interface to
control that, so that the rfkill state is restored after a resume.

PS: about the wwan port, it can be used to do very interesting things :-)
Improving ntpd accuracy using a wwan module with GPS works for the NMEA
part! For further accuracy improvements, I just can't get the PPS yet, but
it's already quite interesting :-). Also, early tests with my cheap huawei
card suggest it can produce an audio stream for freeswitch using gsmopen
module)

Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141203/179ca466/attachment.html>