Re: [PATCH V3] Add iwlwifi wireless drivers

[Ivo van Doorn <ivdoorn@gmail.com>]

On Tuesday 04 September 2007, dragoran wrote:
> On 9/4/07, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > On Tuesday 04 September 2007, dragoran wrote:
> > > On 9/4/07, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > > > On Tuesday 04 September 2007, dragoran wrote:
> > > > > >+static ssize_t show_rf_kill(struct device *d,
> > > > > >+                        struct device_attribute *attr, char *buf)
> > > > > >+{
> > > > > >+    /*
> > > > > >+     * 0 - RF kill not enabled
> > > > > >+     * 1 - SW based RF kill active (sysfs)
> > > > > >+     * 2 - HW based RF kill active
> > > > > >+     * 3 - Both HW and SW based RF kill active
> > > > > >
> > > > > >that as well, along with all the other sysfs bits. Also, how about using
> > > > > >the generic rfkill infrastructure Ivo did?
> > > > >
> > > > > is the generic rfkill interface already stable and merged into the linus tree?
> > > >
> > > > Yes. It currently is only missing users.
> > >
> > > ok thats great ;) is the (userspace) interface defined somewhere? or
> > > should I read the code to understand how it works? (would like to add
> > > support to hal)
> >
> > There isn't a documentation file for it, so best thing to do would be looking at the code.
> > basically hal only needs to check the sysfs files:
> >
> >         name -> Name of device/interface
> >         type -> wlan, bluetooth, irda
> >         state -> Current device state. 0: Off, 1: On
> >         claim -> 0: Kernel handles events, 1: Userspace handles events
> >
> > "name" and "type" are read-only
> > "claim" and "state" are read/writable
> >
> > Note that there is a bug in 2.6.22 which causes the "state" file to be read-only,
> > this has been fixed in 2.6.23-rc.
> 
> ok that isn't complicated what is the claim used for?
> does It has to be set to userspace to be able to toggle the status via software?

By default the kernel will act when the rfkill button is pressed, it will loop
through all registered buttons of the same type and change the state.
Userspace can read the "state" sysfs file to see the current status,
but if a userspace tools wants to take control of taking action when the button is pressed,
or at least doesn't want the kernel to do anything, 1 should be written to "claim" to
tell the kernel that it should back off and ignore all events.

Ivo