On Tuesday 16 September 2008 21:18:27 Carlos Corbacho wrote:
quoted text
> 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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/