On Mon, 2011-03-21 at 20:27 +0100, OldÅich JedliÄka wrote: > hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill switch > appears when you unblock SW rfkill or by pressing the HW switch. It disappears > when you block the switch again. hci0 is set to "blocked" when it appears, > because the acer-wmi driver have registered acpi-bluetooth rfkill switch > during boot, which was set to "blocked" initially with a call to > rfkill_init_sw_state. So what happens actually is this: > > 1) at boot, BIOS says the bluetooth is disabled, so the not-registered state > of acer-bluetooth rfkill is set to "blocked" (rfkill_init_sw_state, sets the > "persistent" bit). The acer-bluetooth is then registered, which forces the > global bluetooth state to go "blocked". No hci0 exists at this time. > > 2) when you press the button, hci0 appears and the rfkill is set to the global > bluetooth state (in rfkill_sync_work), which is "blocked". > > From my understanding acer-wmi reports the change via acer_rfkill_update work > (executed every second). It just calls rfkill_set_sw_state, but that doesn't > update the global state. I don't know at which time that happens, but > generally I didn't find anything that could eventually enable hci0 state or > global state to "unblocked". Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't been updated yet, hence registering hci0 as blocked. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
