Return-path: Received: from mx1.redhat.com ([66.187.233.31]:39467 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbXIGPZs (ORCPT ); Fri, 7 Sep 2007 11:25:48 -0400 Subject: Re: rfkill interface (was Re: [PATCH V3] Add iwlwifi wireless drivers) From: Dan Williams To: Ivo van Doorn Cc: dragoran , linux-wireless@vger.kernel.org, johannes@sipsolutions.net In-Reply-To: <200709061849.36579.IvDoorn@gmail.com> References: <1189039823.13730.4.camel@xo-3E-67-34.localdomain> <200709061849.36579.IvDoorn@gmail.com> Content-Type: text/plain Date: Fri, 07 Sep 2007 11:25:05 -0400 Message-Id: <1189178705.2612.9.camel@xo-3E-67-34.localdomain> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, 2007-09-06 at 18:49 +0200, Ivo van Doorn wrote: > On Thursday 06 September 2007, Dan Williams wrote: > > On Wed, 2007-09-05 at 21:33 +0200, dragoran wrote: > > > On 9/4/07, Ivo van Doorn wrote: > > > > On Tuesday 04 September 2007, dragoran wrote: > > > > > On 9/4/07, Ivo van Doorn wrote: > > > > > > On Tuesday 04 September 2007, dragoran wrote: > > > > > > > On 9/4/07, Ivo van Doorn 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. > > > > > > ok thx for explaining this will talk to the nm and hal people about it > > > and see how they want things to work than I will create patches to > > > implement it. > > > which drivers support it now? rt2x00 and ?? or are they the only ones right now? > > > > Since it's in the kernel, the next step is to get HAL aware of the > > killswitches through sysfs and not through fdi files keyed on > > Dell/Sony/etc. > > > > Ivo: how does one tell whether or not the switch needs to be polled? > > That's something that HAL will need to deal with polling/non-polling > > intelligently. I assume that either the layer or the driver > > implementing the button will know that it needs to be polled and should > > be the thing that sets the value. Ideally just an attribute in sysfs > > like "require-poll" with a value of 1 or 0 or something like that. > > No, because like I explained userspace is not in control of polling, > because there should be no userspace dependency. This means that > if the device requires polling, it should register itself with the input_polldev handler. > This way the radio button will allwats work as expected, without requiring > some version of HAL.. Awesome. Dan