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. > 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. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
