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/t... - 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