Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Michael Buesch <mb@bu3sch.de>]

On Tuesday 16 September 2008 21:18:27 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.

Sure it is. It's the common case, if there's a button.

But I don't know how to tell the rfkill subsystem about the states and
I do not _want_ to. See, that crap code _always_ blew up for every single
patch we did. I'm tired of this and I am not interested in that anymore.
Please revert that patch and if that makes it work I'm fine with it.

I'm still waiting for the sane rfkill API where we have three functions
rfkill-allocate
rfkill-hw-state-changed
rfkill-free

That's all I need. All that input stuff, which was _the_ way to go some
months ago, but is now deprecated it seems (but I don't know what it it
replaced by) is just so really confusing.

-- 
Greetings Michael.