Skip to contentSkip to conversation

/proc/acpi/ibm/wan stopped appearing

PATCH Applied Jeremy Fitzhardinge 3 participants 7 messages Aug 27, 2008 – Aug 28, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

/proc/acpi/ibm/wan stopped appearing for me at some point recently (bluetooth is still there). I guess this has something to do with the RFKILL changes, but I haven't looked at them in detail. I guess my question is: is this expected, and what's the "proper" way to control the WWAN radio now?

Thanks,
J

#1 lore raw
Quoted 5 lines · Jeremy Fitzhardinge

/proc/acpi/ibm/wan stopped appearing for me at some point recently (bluetooth is still there). I guess this has something to do with the RFKILL changes, but I haven't looked at them in detail. I guess my question is: is this expected, and what's the "proper" way to control the WWAN radio now?

1. It is not expected, I have not removed /proc interface support for anything. Look at the thinkpad-acpi documentation, it is always (and I do mean ALWAYS) up-to-date.

The /proc interface for thinkpad-acpi is not going away for a while yet, unless ACPI itself decides that /proc/acpi must die.

2. The proper way to control ANY radio's rfkill functions is through the rfkill sysfs interface. That includes thinkpad-acpi's bluetooth and WWAN.

IOW, we may have a regression here. Please compile thinkpad-acpi with debug mode enabled, load it with the "debug=0xffff" and "experimental=1" parameters (as far as I remember, WWAN requires "experimental=1" to work, without that it will NOT load, and you will NOT get /proc/acpi/ibm/wan or anything else WWAN related from thinkpad-acpi), and send me the resulting log output from thinkpad-acpi.

Signature · 4 lines
  "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
#2 lore raw
Quoted 3 lines · Henrique de Moraes Holschuh

2. The proper way to control ANY radio's rfkill functions is through the rfkill sysfs interface. That includes thinkpad-acpi's bluetooth and WWAN.

Do you know what UI-level programs make use of these interfaces now?

Quoted 6 lines

IOW, we may have a regression here. Please compile thinkpad-acpi with debug mode enabled, load it with the "debug=0xffff" and "experimental=1" parameters (as far as I remember, WWAN requires "experimental=1" to work, without that it will NOT load, and you will NOT get /proc/acpi/ibm/wan or anything else WWAN related from thinkpad-acpi), and send me the resulting log output from thinkpad-acpi.

Actually, that may be it. I think I used to load it as a module, and modprobe.conf set experimental=1, but I don't have an equivalent on the kernel command line.

I think I'll submit a patch to remove the need for experimental; it's been working fine for me for 3 years now.

J

#3 lore raw
Quoted 6 lines · Jeremy Fitzhardinge
Quoted 3 lines · Henrique de Moraes Holschuh

2. The proper way to control ANY radio's rfkill functions is through the rfkill sysfs interface. That includes thinkpad-acpi's bluetooth and WWAN.

Do you know what UI-level programs make use of these interfaces now?

Anything that does it through HAL when HAL gets updated, I suppose.

I don't really care for the network management GUIs, I have never seen one that worked properly, so I dropped them all for good. The UIs I use are wpa-supplicant's config file, iproute and friends, and Debian's ifupdown crap.

The only UI I trust enough to touch rfkill control on my machines is the kernel itself (rfkill-input is an UI), so I guess you will have to ask someone else about it normal user-level UIs and GUIs for rfkill :( Probably in the linux-wireless ML, instead of here in LKML.

Quoted 10 lines
Quoted 6 lines

IOW, we may have a regression here. Please compile thinkpad-acpi with debug mode enabled, load it with the "debug=0xffff" and "experimental=1" parameters (as far as I remember, WWAN requires "experimental=1" to work, without that it will NOT load, and you will NOT get /proc/acpi/ibm/wan or anything else WWAN related from thinkpad-acpi), and send me the resulting log output from thinkpad-acpi.

Actually, that may be it. I think I used to load it as a module, and modprobe.conf set experimental=1, but I don't have an equivalent on the kernel command line.

thinkpad-acpi.experimental=1 in the kernel command line should do it.

Quoted 2 lines

I think I'll submit a patch to remove the need for experimental; it's been working fine for me for 3 years now.

It is in my TODO list, so you don't need to bother. But if you do, here are my requirements for patches to be accepted, so that you don't waste your time:

1. Do it based on thinkpad-acpi in Linus' mainline, and give the patch a proper title prefix ("ACPI: thinkpad-acpi: "), title and commit message. Sign it off, and CC me.

2. UPDATE THE DOCUMENTATION ALONG WITH THE CODE, in the SAME patch. That means Documentation/laptops/thinkpad-acpi.txt.

Plus the usual "test it first", etc. But it will be an extremely trivial one-liner patch to the code, so I wouldn't worry much about that ;-) It is the doc update that will make up most of the patch.

Signature · 4 lines
  "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
#4 lore raw

PATCH 1/1 ACPI: thinkpad-acpi: wan radio control is not experimental

The WWAN radio control has been working well for over three years, and is no longer experimental.

---
 Documentation/laptops/thinkpad-acpi.txt |   11 +++--------
 drivers/misc/thinkpad_acpi.c            |    1 -
 2 files changed, 3 insertions(+), 9 deletions(-)

===================================================================

Documentation/laptops/thinkpad-acpi.txt +3 -8
@@ -44,7 +44,7 @@
 	- LCD brightness control
 	- Volume control
 	- Fan control and monitoring: fan speed, fan enable/disable
-	- Experimental: WAN enable and disable
+	- WAN enable and disable
 
 A compatibility table by model and feature is maintained on the web
 site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -1375,17 +1375,12 @@
 would be the safest choice, though).
 
 
-EXPERIMENTAL: WAN
------------------
+WAN
+---
 
 procfs: /proc/acpi/ibm/wan
 sysfs device attribute: wwan_enable (deprecated)
 sysfs rfkill class: switch "tpacpi_wwan_sw"
-
-This feature is marked EXPERIMENTAL because the implementation
-directly accesses hardware registers and may not work as expected. USE
-WITH CAUTION! To use this feature, you need to supply the
-experimental=1 parameter when loading the module.
 
 This feature shows the presence and current state of a W-WAN (Sierra
 Wireless EV-DO) device.

===================================================================

drivers/misc/thinkpad_acpi.c +0 -1
@@ -3086,7 +3086,6 @@
 	.read = wan_read,
 	.write = wan_write,
 	.exit = wan_exit,
-	.flags.experimental = 1,
 };
 
 /*************************************************************************
Acked-by on v1 1/1
#5 lore raw

Re: [PATCH] ACPI: thinkpad-acpi: wan radio control is not experimental

Quoted 4 lines · Jeremy Fitzhardinge

The WWAN radio control has been working well for over three years, and is no longer experimental.

I have queued it and since it is an one-liner with zero chance of causing problems, I will ask Andi to merge it for 2.6.27. If he doesn't agree, it will be merged for 2.6.28.

Signature · 4 lines
  "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
Applied
#6 lore raw

Re: [PATCH] ACPI: thinkpad-acpi: wan radio control is not experimental

In reply to Jeremy Fitzhardinge
Quoted 2 lines · Jeremy Fitzhardinge

The WWAN radio control has been working well for over three years, and is no longer experimental.

Queued thanks. I can put it into the next .27 update.

-Andi