Michael Buesch wrote:
> On Tuesday 27 November 2007 21:02:47 Larry Finger wrote:
> Is the switch properly polled and is the status change properly reported upstream?
> If yes, you might want to check (add printk to rfkill code) if the LED
> is properly triggered.
I know that b43_rfkill_poll() is being called as I can see the ENABLED/DISABLED messages in the log.
I'll have to work my way through the things it calls.
> I'm wondering who causes this deadlock. "registered" should be false if
> we are called back from rfkill_initialize, so it should return early before
> the lock.
The following code has the competing lock:
static int rfkill_toggle_radio(struct rfkill *rfkill,
enum rfkill_state state)
{
int retval;
retval = mutex_lock_interruptible(&rfkill->mutex);
if (retval)
return retval;
if (state != rfkill->state) {
retval = rfkill->toggle_radio(rfkill->data, state);
if (!retval) {
rfkill->state = state;
rfkill_led_trigger(rfkill, state);
}
}
mutex_unlock(&rfkill->mutex);
return retval;
}
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
