Carlos Corbacho wrote: > On Tuesday 16 September 2008 18:08:48 Larry Finger wrote: >> I agree with Michael. From what I know, the only possible reason for >> having [RFKILL_STATE_HARD_BLOCKED] would be if user space could >> somehow affect the state of the hardware switch. > > When I disable the b43 device in my laptop via acer-wmi (which in turn, calls > into the laptops firmware), b43 physically cannot re-enable it (a not > uncommon case on a lot of laptops). In which case, as far as b43 is > concerned, the wireless radio is then in RFKILL_STATE_HARD_BLOCKED, since b43 > is unable to re-enable the radio on the hardware. > > So yes, it is quite possible for b43 to be in RFKILL_STATE_HARD_BLOCKED. I didn't say it was not possible. What I said is that _ONLY_ the operator's finger could change the state, just like in your laptop. Thus it makes absolutely no difference what state RFKILL thinks it is in. The driver knows what state the software wants, and can read but not write the hardware state. There has to be a bug in RFKILL that got exposed when this commit was included. This regression needs to be fixed ASAP, otherwise 2.6.27 will be released with it. If the RFKILL guys want to fix their bug, I'll be happy to test code, but not now. Larry -- 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
