Search Linux Wireless

Re: Question on rfkill double block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Henrique de Moraes Holschuh wrote:
On Sun, 06 Jul 2008, Tomas Winkler wrote:
From my experience from other OS the states of SW and HW RF KILL
switches should be independent and visible to user space
otherwise it's very hard to make something coherent out of it. It
should be visible to user himself so he/she knows what switch actually
press. And also to let say unmanned application, most important in
preserving SW switch state across reboots and resume/suspend events.
Radio state is just simple AND function of all the switches in the
game anything else just leads to confusion.
Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
off, the last one is better to eliminate but still we have TRIPLE
BLOCKING

I am not convinced it is the best way to go, but I thought on it, and that
fourth state will at least help on sleep-to-ram resume, so you guys will get
four states.
But I can't give you a bitmap.  Sorry, there is a stablished sysfs ABI in
mainline that says this:

00 - BLOCK ("off")
01 - UNBLOCK ("on")

I hate it, but I can't change it.  We can *extend* it, but that's it.

Perhaps it's time to throw out the userspace interface and start over, or at least replace it and emulate the old one, too.

I'm not even kidding. I have an iwl4965, and I've tried 2.6.25.10's built-in driver and wireless-compat from a couple days ago. The rfkill switch *works* but the userspace interface does nothing. (2.6.25.10's module at least causes network-manager to notice that the interface went down and gets a ton of "Requesting MAC access during RFKILL wakes up NIC." Wireless-compat's driver just confuses network-manager.) The rfkill module seems to have no effect, and 'find /sys -name *rfkill*' shows nothing (other than the rfkill class and module). Rfkill doesn't work on my ath5k system either (no rfkill file). This is Ubuntu Hardy, which has nm 0.6, but I once tried nm 0.7 from svn and I don't recall it working any better.

Not to mention the fact that I have both an rfkill switch and an rfkill button. Pressing the button turns WLAN off (same RFKILL messages spammed to dmesg) and Bluetooth *on*. Maybe it's thinkpad_acpi's fault, but I don't really see how it's supposed to work right.

So it seems to me that the status quo is:
- If there's a sysfs file called rfkill, it has such and such semantics, and you probably can't change it by writing to it.
 - There probably isn't an rfkill file.
- Userspace, at least on my laptops, doesn't currently use the rfkill ABI in any meaningful manner. - Software rfkill control can easily do the wrong thing and there's no obvious way to make it do the right thing from userspace, .config, or sysfs.

Maybe the new semantics should be something sensible with a read-only file called "rfkill" that's backwards-compatible and shows the overall state. Then we could do gnarly things like making *every* mac80211 driver have software rfkill control, add inotify or something to the rfkill file, and generally have good and easily comprehensible control over all radios. Hardware switches (and momentary swtiches and buttons and whatnot) could all be exposed directly to userspace. Who knows -- there could even be files like "hard_rf_enable" (read-only, only there if there's a readable switch, like on iwl4965) and "soft_rf_enable" (read-write, unconditionally present), and a mechanism for userspace to control the software part (i.e. userspace could tell rfkill-input to stop doing anything and take control itself).

I'd suggest that nothing visible to userspace on the rfkill side go into 2.6.27 until it can be done right and it's clear what this whole mechanism is supposed to do. I might even be talked into writing some patches, because it would be kind of nice for all this stuff to work right on my laptops.

If I'm missing something I need to make rfkill suddenly work on my machine, please give me some hints, too :)

--Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux