> - Handle the global mutex properly when rfkill_set_{hw,sw}_state() > or > rfkill_set_states() is called from within an rfkill callback. v2 > always tried to lock the global mutex in such a case, which led > to a > deadlock when an rfkill driver called one of the above functions > from its query or set_block callback. This is solved by defining > a > new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the > above > callbacks are invoked and cleared afterwards; the functions > listed > above use this bitfield to tell rfkill_any_led_trigger_event() > whether the global mutex is currently held or not. > RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as > setting > it before invoking the query callback would cause any calls to > rfkill_set_sw_state() made from within that callback to work on > RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change > the > way rfkill_set_block() behaves. I'm not super happy with this conditional locking - can't we instead defer the necessary work to a workqueue, or so, for purposes of the LED? johannes