On Thursday 18 September 2008 15:53:28 Ivo van Doorn wrote: > On Thursday 18 September 2008, Larry Finger wrote: > > Ivo van Doorn wrote: > > > > > 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. -- 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
