All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@myrealbox.com>
To: hmh@hmh.eng.br
Cc: thomasw@gmail.com, zhu.yi@intel.com,
	linux-wireless@vger.kernel.org, dcbw@redhat.com
Subject: Re: Question on rfkill double block
Date: Mon, 07 Jul 2008 00:44:31 -0400	[thread overview]
Message-ID: <48719F2F.5060301@myrealbox.com> (raw)
In-Reply-To: <20080706002037.GD21973@khazad-dum.debian.net>

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


  reply	other threads:[~2008-07-07  4:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02  7:03 Question on rfkill double block Zhu Yi
2008-07-02 17:03 ` Dan Williams
2008-07-04 19:55   ` Henrique de Moraes Holschuh
2008-07-07 17:11     ` Dan Williams
2008-07-07 19:48       ` Fabien Crespel
2008-07-07 20:47       ` Henrique de Moraes Holschuh
2008-07-08  5:12         ` Andy Lutomirski
2008-07-08 15:05           ` Henrique de Moraes Holschuh
2008-07-02 19:32 ` Henrique de Moraes Holschuh
2008-07-05 21:28   ` Tomas Winkler
2008-07-06  0:20     ` Henrique de Moraes Holschuh
2008-07-07  4:44       ` Andy Lutomirski [this message]
2008-07-07 16:56         ` Henrique de Moraes Holschuh
2008-07-07 18:47           ` Andrew Lutomirski
2008-07-07 19:18             ` Andrew Lutomirski
2008-07-07 21:09               ` Andrew Lutomirski
2008-07-07 21:21               ` Henrique de Moraes Holschuh
2008-07-07 20:59             ` Henrique de Moraes Holschuh
2008-07-07 17:02         ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48719F2F.5060301@myrealbox.com \
    --to=luto@myrealbox.com \
    --cc=dcbw@redhat.com \
    --cc=hmh@hmh.eng.br \
    --cc=linux-wireless@vger.kernel.org \
    --cc=thomasw@gmail.com \
    --cc=zhu.yi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.