On Thursday 18 September 2008, Michael Buesch wrote: > On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote: > > Well no actually, when the radio state (software rfkill state in your words) > > No, "radio state" is _not_ "software rfkill state" in my words. > It's an independent state. > The actual physical radio state is a combined state of the two sw and hw state bits. > If either bit blocks the radio, it's physically blocked. We cannot toggle the hw bit > from software. Ah ok. In that case b43 should do: send HW_BLOCK when the hardware rfkill state is set to block send SOFT_BLOCK when the software rfkill state is set to block But it shouldn't (and that change was the start of this discussion) send SOFT_BLOCK when mac80211 disabled the radio. > > it shouldn't be send to rfkill at all. rfkill should only be informed about the hardware > > rfkill state changes. > > So that's fine. We just revert the patch that caused all the trouble and we will > gain _exactly_ that. > > > > Do not change any software state from within the hardware state change handler. > > > This will blow up. > > > > When you use userspace tools this won't happen since the hardware state change handler > > will send an uevent to userspace which might act upon that, and will eventually send an > > instruction back to the hardware, but that goes through a different thread. > > It will semantically blow up. See the initial mail from Larry with the regression report. Ok. 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
