Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Larry Finger <Larry.Finger@lwfinger.net>]

Matthew Garrett wrote:
> On Tue, Sep 16, 2008 at 12:08:48PM -0500, Larry Finger wrote:
> 
>> I agree with Michael. From what I know, the only possible reason for
>> having this state would be if user space could somehow affect the
>> state of the hardware switch. As the user's finger is the only such
>> thing, then there is no use for the RFKILL_STATE_HARD_BLOCKED state,
>> particularly when it breaks LED operations.
> 
> RFKILL_STATE_HARD_BLOCKED indicates that the hardware is disabled in a 
> way that userspace can't influence, so sounds like exactly the right 
> state to have here. I still have absolutely no idea what b43 rfkill is 
> supposed to be doing - why on earth is it requesting rfkill-input, and 
> why does it generate keypress events? I /think/ it should e something 
> like the following (untested, I'm not near any of my b43 hardware at the 
> moment). This basically does the following:
> 
> 1) Split the update function in two, so it can be called by either 
> polling or an interrupt driven event on newer hardware (not implemented 
> yet)
> 2) Remove all the input handling
> 3) Change the state updates to use rfkill_force_state, which will 
> generate an event that gets sent up to userland
> 4) Retains the RFKILL_STATE_HARD_BLOCKED code
> 
> When the user flicks a switch or presses a button that physically 
> disables the radio, the state will now automatically change to 
> RFKILL_STATE_HARD_BLOCKED. If they have a key that generates KEY_WLAN 
> but doesn't change the radio state, rfkill-input will trigger a change 
> to RFKILL_STATE_SOFT_BLOCKED.
> 
> Like I said, this is only build-tested - I won't be back at a b43 until 
> next week. If someone could give this a go, that would be great.

It locks up tight with a kernel panic when booting. I have a screen
picture that I will send separately to Matthew.

Larry