On Fri, 2008-06-27 at 18:35 -0300, Henrique de Moraes Holschuh wrote: > On Fri, 27 Jun 2008, Dan Williams wrote: > > On Mon, 2008-06-23 at 17:46 -0300, Henrique de Moraes Holschuh wrote: > > > The current naming of rfkill_state causes a lot of confusion: not only the > > > "kill" in rfkill suggests negative logic, but also the fact that rfkill cannot > > > turn anything on (it can just force something off or stop forcing something > > > off) is often forgotten. > > > > > > Rename RFKILL_STATE_OFF to RFKILL_STATE_SOFT_BLOCKED (transmitter is blocked > > > and will not operate; state can be changed by a toggle_radio request), and > > > RFKILL_STATE_ON to RFKILL_STATE_UNBLOCKED (transmitter is not blocked, and may > > > operate). > > > > > > Also, add a new third state, RFKILL_STATE_HARD_BLOCKED (transmitter is blocked > > > and will not operate; state cannot be changed through a toggle_radio request), > > > which is used by drivers to indicate a wireless transmiter was blocked by a > > > hardware rfkill line that accepts no overrides. > > > > > > Keep the old names as #defines, but document them as deprecated. This way, > > > drivers can be converted to the new names *and* verified to actually use rfkill > > > correctly one by one. > > > > > > Signed-off-by: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> > > > Cc: Ivo van Doorn <IvDoorn@xxxxxxxxx> > > > > Thanks for doing this! > > > > So with this patch, in the case where ex. hp-wmi advertises a killswitch > > and the wlan driver itself doesn't have one, when NM wants to softkill > > the radio, should NM do a SIOCSIWTXPOW or softblock the hp-wmi > > killswitch? Or would the wlan driver implement an rfkill handler and > > I thought a lot about it, and I personally feel it is better to keep > SIOCSIWTXPOW separate from rfkill. This is a driver layer thing, and rfkill > doesn't care either way, but IMHO it is less confusing for the user if > iwconfig txpower doesn't change the rfkill status of a device. > > This means NM would be trying to set the class/rfkill*/state to > RFKILL_STATE_SOFT_BLOCKED for the devices it wants to block. > > And the way to be able to do it without going insane really is to start > adding rfkill subsystem support to all wireless network drivers, so your > WLAN devices will all have a rfkill class related to them. Right, but that's the part we don't yet have, correct? Can I just start adding rfkill capability with the patchset you just posted to drivers like airo and atmel even though they don't have killswitches themselves? That's the conceptual problem here; cards like airo and atmel don't have killswitches, and since /sys/class/rfkill/rfkillX are _switches_ right now, it gets confusing when a device that isn't a killswitch would start providing rfkillX. Dan > > thus have /sys/class/rfkill/rfkillX as well? My understanding of what > > would happen here got buried in all the mails last time around. If the > > transmitter is not tied to a physical killswitch, but the killswitch is > > provided by another module (laptop specific driver for example), do we > > assume the rfkill state is authoritative or do we check each radio via > > it's own specific method? > > Unless HAL can tell you about it, and you teach HAL the topology for every > laptop model (something I consider Not Doable), you really are supposed to > try to ignore as much as possible the topology of kill switches. > > So, you add topology agnostic UIs to NM that let the user: > 1. Easily try to set the state of all devices of a given type > 2. Try to set the state of a particular device. > 3. Try to set the state of all devices (shortcut to "for all types, do (1) > above). > > hp-wmi's and thinkpad-acpi's softswitches would show up just like any > another device. The user would quickly learn that changing the state of > these devices has an effect of hardblocking others. > > When I get to improving the interface to the global state (i.e. add the > attributes needed to implement rfkill-input in userspace), you will be > able to do more, or to do the above in an easier way. > -- 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
