Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Larry Finger]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/