On Thursday 18 September 2008, Michael Buesch wrote: > On Thursday 18 September 2008 15:47:42 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. > > If sw is unblocked, but hw is still blocked, you must not announce > unblocked state to rfkill. Well from my perspective: Note that 'sw' is the RADIO state as requested by mac80211 and 'hw' is the RFKILL state as indicated by the hardware radio: block, rfkill: block => BLOCK radio: block, rfkill: unblock => UNBLOCK radio: unblock, rfkill: block => BLOCK radio: unblock, rfkill: unblock => UNBLOCK Ivo -- 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
