On Thursday 18 September 2008 15:53:28 Ivo van Doorn wrote:

On Thursday 18 September 2008, Larry Finger wrote:

quoted

Ivo van Doorn wrote:

quoted

Is dev->phy.radio_on set when mac80211 has send an instruction
to the driver to enable the radio (start() or config() callback)
or does it represent the key state in the hardware?

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.

Off course when it represents the key state in the hardware then the
code would be fine...

The state comes from mac80211 and is set in the config() callback.

What state should be sent at the point when the hardware block is
removed? It seems to me that forcing an UNBLOCKED state gives the
wrong result. Perhaps RFKILL does need to have 4 states so that an
RFKILL_STATE_HW_UNBLOCKED state can be transmitted.

When the key is pressed to unblock the device, then simply send state
RFKILL_STATE_UNBLOCKED to rfkill. That will generate a trigger to the
driver to enable the radio,

The radio is enabled in _hardware_. There doesn't need to be any trigger.
It's already on. In fact, such a trigger (done through rfkill->toggle callback)
would deadlock wl->mutex with the current patch.

and at that time you can check if mac80211 
wants the radio on or not (aka you check dev->phy.radio_on or the mac80211
config structure).

No!
Software and hardware rfkill states are completely different and _independent_
states on the b43 hardware. You set the software state from the mac80211 callback
no matter what hardware state the device is in. You just have to announce the
state correctly to the rfkill subsystem if mac80211 changed the software
state.

Do not change any software state from within the hardware state change handler.
This will blow up.

-- 
Greetings Michael.