On Thursday 18 September 2008, Michael Buesch wrote:

On Thursday 18 September 2008 16:24:52 Ivo van Doorn wrote:

quoted

On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:

quoted

On Thu, 18 Sep 2008, Ivo van Doorn wrote:

quoted

If it is something coming from mac80211, then you do not want
to send a SOFT_BLOCKED event since that will cause all other radios
to be switched off simply because the b43 interface has not been
enabled.

Drivers ARE supposed to be able to set their radio state to their heart's
content, without messing with any other devices.  There are no constraints
to calls to rfkill_force_state(), other than the current issue that it must
not be done from an atomic context.

My main point was that when the radio is not enabled because the user
did something like "iwconfig wlan0 txpower off" then this is not an rfkill
SOFT_BLOCKED event. Since that command has nothing to do with the
entire rfkill layer.

When you consider such commands as rfkill events you get wrong behavior
because it would trigger a SOFT_BLOCK in rfkill which will be send to all
registered drivers who can disable their radio off as well. And that is
definately not what you want...

Well, if that's the definition of the API, we must not force rfkill
state to anything other than HW_BLOCKED or UNBLOCKED.
I dunno how the API is defined...

From rfkill.h:

	RFKILL_STATE_SOFT_BLOCKED = 0,	/* Radio output blocked */
	RFKILL_STATE_UNBLOCKED    = 1,	/* Radio output allowed */
	RFKILL_STATE_HARD_BLOCKED = 2,	/* Output blocked, non-overrideable */

Since b43 has a rfkill mechanism that does switch of the radio when RFKILL is set to BLOCK
after a key press, it should send RFKILL_STATE_HARD_BLOCKED because rfkill cannot override
it.

rt2x00 hardware does not change the radio state when RFKILL is set to BLOCK after a key press,
the state is therefor overridable and it can send RFKILL_STATE_SOFT_BLOCKED to rfkill.

Ivo